消息中间件总结

异步、削峰填谷的作用。

一、RabbitMQ 

1、RabbitMQ 消息可靠性传递

ACK确认机制，消费者手动确认和自动确认

2、RabbitMQ  幂等问题：

参考文章

4、简介：

使用Erlang编写的一个开源的消息队列，本身支持很多的协议：AMQP，XMPP, SMTP,STOMP，也正是如此，使的它变的非常重量级，更适合于企业级的开发。同时实现了Broker架构，核心思想是生产者不会将消息直接发送给队列，消息在发送给客户端时先在中心队列排队。对路由(Routing)，负载均衡(Load balance)、数据持久化都有很好的支持。多用于进行企业级的ESB整合。

5、RabbitMQ  性能怎样？

6、RabbitMQ底层实现原理？

7、RabbitMQ 是怎样持久化的 ？

8、 RabbitMQ如何保证多个消费者顺序消费？

参考

9、RabbitMQ有哪些组件及原理 ？

10、 RabbitMQ有几种广播机制 ？

11、RabbitMQ 如何保证消息不丢失

三方不丢失参考

参考

12、RabbitMQ 如何搭建高可用集群

参考

参考1

13、

14、

15、

16

二、RocketMQ

1、简洁

阿里系下开源的一款分布式、队列模型的消息中间件，原名Metaq，3.0版本名称改为RocketMQ，是阿里参照kafka设计思想使用java实现的一套mq。同时将阿里系内部多款mq产品（Notify、metaq）进行整合，只维护核心功能，去除了所有其他运行时依赖，保证核心功能最简化，在此基础上配合阿里上述其他开源产品实现不同场景下mq的架构，目前主要多用于订单交易系统。

具有以下特点：

• 能够保证严格的消息顺序
• 提供针对消息的过滤功能
• 提供丰富的消息拉取模式
• 高效的订阅者水平扩展能力
• 实时的消息订阅机制
• 亿级消息堆积能力

2、RocketMQ如何保证消息不丢失

三方保证

参考

3、

4、

5、

6、

三、Kafka 

1、RocketMQ 与 Kafka 区别

2、简洁：适合大数据量

Apache下的一个子项目，使用scala实现的一个高性能分布式Publish/Subscribe消息队列系统，具有以下特性：

• 快速持久化：通过磁盘顺序读写与零拷贝机制，可以在O(1)的系统开销下进行消息持久化；
• 高吞吐：在一台普通的服务器上既可以达到10W/s的吞吐速率；
• 高堆积：支持topic下消费者较长时间离线，消息堆积量大；
• 完全的分布式系统：Broker、Producer、Consumer都原生自动支持分布式，依赖zookeeper自动实现复杂均衡；
• 支持Hadoop数据并行加载：对于像Hadoop的一样的日志数据和离线分析系统，但又要求实时处理的限制，这是一个可行的解决方案。

3、性能对比：

4、Kafka 如何保证消息 顺序消费 ？

全局有序：

由于Kafka的一个Topic可以分为了多个Partition，Producer发送消息的时候，是分散在不同Partition的。当Producer按顺序发消息给Broker，但进入Kafka之后，这些消息就不一定进到哪个Partition，会导致顺序是乱的。

因此要满足全局有序，需要1个Topic只能对应1个Partition。

而且对应的consumer也要使用单线程或者保证消费顺序的线程模型，否则会出现下图所示，消费端造成的消费乱序。

局部有序：

要满足局部有序，只需要在发消息的时候指定Partition Key，Kafka对其进行Hash计算，根据计算结果决定放入哪个Partition。这样Partition Key相同的消息会放在同一个Partition。此时，Partition的数量仍然可以设置多个，提升Topic的整体吞吐量。

如下图所示，在不增加partition数量的情况下想提高消费速度，可以考虑再次hash唯一标识（例如订单orderId）到不同的线程上，多个消费者线程并发处理消息（依旧可以保证局部有序）。

消息重试对顺序消息的影响

对于一个有着先后顺序的消息A、B，正常情况下应该是A先发送完成后再发送B，但是在异常情况下，在A发送失败的情况下，B发送成功，而A由于重试机制在B发送完成之后重试发送成功了。这时对于本身顺序为AB的消息顺序变成了BA。

针对这种问题，严格的顺序消费还需要max.in.flight.requests.per.connection
参数的支持。

该参数指定了生产者在收到服务器响应之前可以发送多少个消息。它的值越高，就会占用越多的内存，同时也会提升吞吐量。把它设为1就可以保证消息是按照发送的顺序写入服务器的。

此外，对于某些业务场景，设置max.in.flight.requests.per.connection=1会严重降低吞吐量，如果放弃使用这种同步重试机制，则可以考虑在消费端增加失败标记的记录，然后用定时任务轮询去重试这些失败的消息并做好监控报警。

参考

5、数据往哪个区写，怎么设置？

参考1

6、kafka 底层原理？ACK确认、偏移量、如何保证顺序消费？

7、Kafka如何保证消息不丢失

三方不丢失参考

参考

8、

9、