【夯实RabbitMQ】为什么使用消息队列？消息队列有什么优点和缺点？
目录
一、系统里为什么要用消息队列这个东西？
公司有个什么业务场景，这个业务场景有个什么技术挑战，如果不用 MQ 可能会很麻烦，但是你现在用了 MQ 之后带给了你很多的好处。
场景有很多，但是比较核心的有 3 个：解耦、异步、削峰。
解耦：看这么个场景。A 系统发送数据到 BCD 三个系统，通过接口调用发送。如果 E 系统也要这个数据呢？那如果 C 系统现在不需要了呢？A 系统负责人几乎崩溃......
公司实际业务场景。如何同步用户信息表。学校会把所有用户信息同步到中台服务器，它是一个数据集成中心，主要会对学校的数据进行清洗。然后数据中台会将数据推送到RabbitMQ服务器中，标准情况下，会有一个消息队列（保证消息的顺序性），就是发送对学生基本信息的增删改消息。
每个产品应用会向RabbitMQ的队列订阅消息，在监听到消息后根据消息得约定好的内容，会对用户信息表做出调整，例如更新与删除用户。这就实现了我们的数据中台服务器与各个应用服务器之间的耦合。
如果不用MQ会出现什么情况呢？中台服务器要知道每个应用服务器的地址还有保存用户信息的相关接口，还要考虑是否调用成功、失败超时等情况，其它应用服务器宕机怎么办。这样中台服务器就与各个应用服务器发生了耦合，代码揉在一起，中台负责人估计心态要蹦了。我们也不想暴露过多的接口，从而让别的系统随随便便调我们系统的接口。
异步：A 系统接收一个请求，需要在自己本地写库，还需要在 BCD 三个系统写库，自己本地写库要 3ms，BCD 三个系统分别写库要 300ms、450ms、200ms。最终请求总延时是 3 + 300 + 450 + 200 = 953ms，接近 1s，用户感觉搞个什么东西，慢死了慢死了。如果使用 MQ，那么 A 系统连续发送 3 条消息到 MQ 队列中，假如耗时 5ms，A 系统从接受一个请求到返回响应给用户，总时长是 3 + 5 = 8ms，对于用户而言，其实感觉上就是点个按钮，8ms 以后就直接返回了，爽！网站做得真好，真快！
实际应用场景：部署日志平台服务器，多个应用使用RabbitMQ向日志平台服务器发送消息，从而把操作记录保存下来。应用只要构造操作日志对象并向RabbitMQ服务器发送消息即可。日志应用平台会监听这些日志消息，因为它需要监控分析各个应用的访问情况等。
如果不用MQ，则需要同步调用日志平台调用的API，耗时比较长。
削峰：一般的 MySQL，扛到每秒 2k 个请求就差不多了，如果每秒请求到 5k 的话，可能就直接把 MySQL 给打死了，导致系统崩溃，用户也就没法再使用系统了。
RabbitMQ可以设置最大消费者数量，并且可以在消息消费成功后，手动确认消息已消费，这可以把没有消费成功的消息重回队列。这样可以把一些请求直接积压到MQ中，从而保护我们的应用服务器或者MYSQL数据库。在RabbitMQ的配置中，可以配置每次从RabbitMQ服务器中获取得消息数量，配置同一时刻消费的数量不要超过自己每秒能处理的最大请求数量就 ok。
二、消息队列有什么优点和缺点？
优点：异步、解耦、削峰
缺点：
系统可用性降低: 这个算是非常致命的一个缺点了。比如某台RabbitMQ服务器挂掉了，那么依赖这台MQ服务器的所有应用都会受到影响。所以就要保证MQ的高可用。
复杂度上升： 引入MQ，那么MQ自身的问题就不能忽略。如何才能保证消息成功被消费，如果宕机了怎么解决，或者是消息丢失了怎么解决。
一致性问题：A 系统处理完了直接返回成功了，人都以为你这个请求就成功了；但是问题是，要是 BCD 三个系统那里，BD 两个系统写库成功了，结果 C 系统写库失败了，咋整？你这数据就不一致了。
目前阶段，技术选型MQ领域基本使用RabbitMQ，因为社区目前最活跃，技术解决方案最多。
三、如何保证RabbitMQ高可用
使用镜像集群模式。在镜像集群模式下，所有创建的队列，无论元数据还是队列里的消息都会存在于多个实例上，就是说，每个 RabbitMQ 节点都有这个 queue 的一个完整镜像，包含 queue 的全部数据的意思。然后每次你写消息到 queue 的时候，都会自动把消息同步到多个实例的 queue 上。
缺点是要同步所有消息与队列信息到其他所有节点上，比较较占网络带宽资源。
阅读更多：从头开始学RabbimtMQ目录贴
