消息中间件介绍 以及Kafka、RabbitMQ、RocketMQ的比较

消息中间件是高并发系统的核心组件之一  消息中间件能解决如下相关问题：

1.    系统解耦  
       当一个系统和外部多个系统之间调用时    系统之间就会阐述耦合   如果采用消息中间件能够解决不同重要程度、不同能力级别系统之间依赖导致一死全死  并且当前系统压根儿不需要去考虑要给谁发送数据，不需要维护这个代码，也不需要考虑人家是否调用成功、失败超时等情况。因为mq本身就具备重试机制    
       你的系统中会不会有这样的场景 就是一个系统调用了多个其他系统，互相之间的调用很复杂，维护起来很麻烦。但是其实这个调用是不需要直接同步调用接口的，如果用 MQ 给它异步化解耦，也是可以的，你就需要去考虑在你的项目里，是不是可以运用这个 MQ 去进行系统的解耦。
      例如： 订单和财务信息就可以使用mq异步处理  使订单和财务系统之间进行解耦  如果财务系统有任何异常就不会影响用户的正常下单
2.    填谷削峰
       当我们系统在摸一个时间短有大量的并发写入请求时  如果我们是直接写入到DB层 例如MYSQL   那可能就会导致数据库直接卡死 导致相关系统崩溃
   例如 我们集中在一个时间段发短信给用户进行推送 或者 在一个短时间内 大批量用户要上传大量商品的场景 如果不使用MQ 每秒达到5k写入请求 就是给数据库 造成很大压力 甚至卡死

       如果使用 MQ，每秒 5k 个请求写入 MQ，A 系统每秒钟最多处理 2k 个请求，因为 MySQL 每秒钟最多处理 2k 个。A 系统从 MQ 中慢慢拉取请求，每秒钟就拉取 2k 个请求，不要超过自己每秒能处理的最大请求数量就 ok，这样下来，哪怕是高峰期的时候，A 系统也绝对不会挂掉。而 MQ 每秒钟 5k 个请求进来，就 2k 个请求出去，结果就导致在中午高峰期（1 个小时），可能有几十万甚至几百万的请求积压在 MQ 中。

   这个短暂的高峰期积压是 ok 的，因为高峰期过了之后，每秒钟就 50 个请求进 MQ，但是 A 系统依然会按照每秒 2k 个请求的速度在处理。所以说，只要高峰期一过，A 系统就会快速将积压的消息给解决掉。
      MQ主要解决瞬时写压力大于应用服务能力导致信息丢失、系统奔溃等问题

       
3.    异步调用

        当一个系统接收一个请求，需要在自己本地写库，还需要在 其他 三个系统写库，自己本地写库要 3ms，其他三个系统分别写库要 300ms、450ms、200ms。最终请求总延时是 3 + 300 + 450 + 200 = 953ms，接近 1s，用户感觉搞个什么东西，慢死了。用户通过浏览器发起请求，等待个 1s，这几乎是不可接受的。 如果我们不要求系统之间同步反馈结果 而且我们也能保证数据的最终一致性 那么我们就可以使用mq来解决这个问题

     
4.    压测测试
       线上有些链路不好压测，可以通过堆积一定量消息再放开来压测  这也是压力测试的一种手段
5.    提升性能
      当存在一对多调用时，可以发一条消息给消息系统，让消息系统通知相关系统  
   例如：当门店的有效状态发生变化时 例如门店关闭  很多门店相关的信息都要做无效处理  例如 门店的上架商品  门店的有效活动  门店的订阅数据等等    如果让含有门店业务的系统一一通知相关的系统 就会给系统代码复杂度 和性能的损耗  但是如果发一条门店关闭的mq出去 让相关的系统订阅该条消息 就会减少系统的复杂度以及提升性能

消息中间件能解决这么多的问题 那么在使用过程中有没有什么缺点呢 或者说我们应该注意什么问题呢？

1. 降低系统的可用性
    当利用mq的种种有点的时候  大家会不会想到这样的一个问题  当mq挂掉了怎么办呢 ？ mq一挂 是不是整个系统就崩溃了呢  所以保证消息中间件的高可用也是很重要的  后续我们会专门开辟文章进行梳理
2. 提高系统的复杂度
    我们使用mq时  我们就要注意很多问题  例如 消息重复消费怎么办？ 消息丢了怎么办 ？ 消息是不是需要有序  ？ 事物消息怎么处理？等等一系列的问题 后续我们再专门降价怎么处理这些问题
3. 需要保证数据的最终一致性
   前面我们也说了有些时候我们需要保值数据饿最终一致性的情况下 才能放心的使用mq的异步调用  否则  当A 通过mq异步调用了B C D 三个系统时 A在处理完数据 发送消息后 直接给请求方返回了成功信息  当如果这是 BCD 其中有任何一个系统进行数据保存失败了  这都是用户不能接受的   后续我们也会针对数据最终一致性的问题进行探讨

 

上面我们讲了MQ的种种好处 和需要注意的问题  下面我们就介绍一下常用的集中mq 和他们各自的优势

特性	RabbitMQ	RocketMQ	Kafka
设计定位	可靠消息传输 类似RocketMQ	非日志的可靠消息传输 例如 商品 促销 订单 消息推送 binlog分发 等	系统之间的数据流管道 实时数据处理 例如日志收集 系统监控 网站活性跟踪
单机吞吐量	万级	10 万级，支撑高吞吐	10 万级，高吞吐，一般配合大数据类的系统来进行实时数据计算、日志采集等场景
topic 数量对吞吐量的影响		topic 可以达到几百/几千的级别，吞吐量会有较小幅度的下降，这是 RocketMQ 的一大优势，在同等机器下，可以支撑大量的 topic	topic 从几十到几百个时候，吞吐量会大幅度下降，在同等机器下，Kafka 尽量保证 topic 数量不要过多，如果要支撑大规模的 topic，需要增加更多的机器资源
时效性	微秒级，这是 RabbitMQ 的一大特点，延迟最低	ms 级	延迟在 ms 级以内
可用性	高，基于主从架构实现高可用 采用镜像模式时 数据量大可能产生性能瓶颈	非常高，分布式架构	非常高，分布式，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用
消息可靠性	基本不丢	经过参数优化配置，可以做到 0 丢失	同 RocketMQ
集群管理		name server	zookeeper
选主方式	最早加入集群的broker	不支持自动选主 通过设置brokername 和brokerid 实现  brokername相同  brokerid为0的为master 其他为slave	从isr中自动选举一个leader  通过zookeeper选举
主从切换	自动切换
数据可靠性
功能支持	基于 erlang 开发，并发能力很强，性能极好，延时很低	MQ 功能较为完善，还是分布式的，扩展性好	功能较为简单，主要支持简单的 MQ 功能，在大数据领域的实时计算以及日志采集被大规模使用

 

转载于:https://my.oschina.net/boomsi/blog/3073094