改变与深度了解拓展与回顾数据持久化应用与积累
1. 比如消息队列中的：解耦、异步、削峰。
2. ，每个代码都要持久化，与考虑对方打得需求与更改的场景与应用 。
3.你需要去考虑一下你负责的系统中是否有类似的场景，就是一个系统或者一个模块，调用了多 个系统或者模块，互相之间的调用很复杂，维护起来很麻烦。但是其实这个调用是不需要直接同步调用接 口的，如果用 MQ 给它异步化解耦，也是可以的，你就需要去考虑在你的项目里，是不是可以运用这个 MQ 去进行系统的解耦。在简历中体现出来这块东西，用 MQ 作解。
异步 ：
再来看一个场景，A 系统接收一个请求，需要在自己本地写库，还需要在 BCD 三个系统写库，自己本地写 库要 3ms，BCD 三个系统分别写库要 300ms、450ms、200ms。最终请求总延时是 3 + 300 + 450 + 200 = 953ms， 接近 1s，用户感觉搞个什么东西，慢死了慢死了。用户通过浏览器发起请求，等待个 1s，这几乎是不可 接受的。
削峰
每天 0:00 到 12:00，A 系统风平浪静，每秒并发请求数量就 50 个。结果每次一到 12:00 ~ 13:00 ，每 秒并发请求数量突然会暴增到 5k+ 条。但是系统是直接基于 MySQL 的，大量的请求涌入 MySQL，每秒钟 对 MySQL 执行约 5k 条 SQL。 一般的 MySQL，扛到每秒 2k 个请求就差不多了，如果每秒请求到 5k 的话，可能就直接把 MySQL 给打死 了，导致系统崩溃，用户也就没法再使用系统了。 但是高峰期一过，到了下午的时候，就成了低峰期，可能也就 1w 的用户同时在网站上操作，每秒中的请 求数量可能也就 50 个请求，对整个系统几乎没有任何的压力。
消息队列有什么优缺点 优点上面已经说了，就是在特殊场景下有其对应的好处，解耦、异步、削峰。 缺点有以下几个： 系统可用性降低 系统引入的外部依赖越多，越容易挂掉。本来你就是 A 系统调用 BCD 三个系统的接口就好了，人 ABCD 四个系统好好的，没啥问题，你偏加个 MQ 进来，万一 MQ 挂了咋整，MQ 一挂，整套系统崩 溃的，你不就完了？如何保证消息队列的高可用，可以查看另一篇文章。 系统复杂度提高 硬生生加个 MQ 进来，你怎么保证消息没有重复消费？怎么处理消息丢失的情况？怎么保证消息传 递的顺序性？头大头大，问题一大堆，痛苦不已。 一致性问题 A 系统处理完了直接返回成功了，人都以为你这个请求就成功了；但是问题是，要是 BCD 三个系 统那里，BD 两个系统写库成功了，结果 C 系统写库失败了，咋整？你这数据就不一致了。 所以消息队列实际是一种非常复杂的架构，你引入它有很多好处，但是也得针对它带来的坏处做各种额外 的技术方案和架构来规避掉，做好之后，你会发现，妈呀，系统复杂度提升了一个数量级，也许是复杂了 10 倍。但是关键时刻，用，还是得用的。
