几种消息中间件的对比

消息队列的本质是将同步处理结果转换成异步处理，一步会带来相应的好处，但也有弊端。
好处：
1、可以在模块、服务、接口等不同粒度上实现解耦
2、订阅/消费模式可以在数据粒度上解耦
3、可提高系统的并发能力，集中力量办大事（同步部分），碎片时间做小时（异步部分）
4、可提高系统可用性，因为缓冲了系统负载
弊端：
1、降低了数据一致性，如要保持强一致性，需要高代价的补偿（如分布式事务，对账）
2、有数据丢失风险，如宕机重启，如果要保障队列可用，需要额外机制保障（如双或容灾）

总体来说，消息队列的使用场景很多，如秒杀、发邮件、发短信、高并发订单等。
不适合的场景如银行转账、电信开户、第三方支付等。关键还是要意识到队里了的优劣点，然后分析场景是否使用。

RabbitMQ

RabbitMQ的几种模式

1、简单模式（simple）不需要指定交换机（1-1）
2、工作队列模式（work）不需要指定交换机（1-N，消费者竞争关系）
3、发布订阅模式（fanout）有交换机，没有路由Key（1-N，多个消费者同事接受消息）
4、路由模式（direct）有交换机，有路由Key，路由Key（1-N，多个消费者，根据路由Key悬着接收消息）
5、主题模式（topic）有交换机，有路由Key，路由Key可以用通配符*或者#
6、RPC模式：通知远程计算机运行功能并等待返回结果，这个过程是阻塞的。

RabbitMQ的几个问题

1、对消息堆积支持不好，在他的设计理念里面，消息大量堆积是不正常的情况，应当尽量去避免
2、性能相对比较差，美妙处理几万到几十万条消息（但是这也足够支撑大多数应用场景）
3、RabbitMQ使用的语言为Erlang，是一种小众语言，学习成本高。

RocketMQ

阿里的项目，别问，问就是阿里牛
RocketMQ对在线业务的响应延时做了很多优化，大多数情况下可以做到毫秒级响应
如果你的应用场景很在意响应延时，那就选这人RocketMQ，性能方面美妙可以出来几十万条消息。

RocketMQ消费原理

几乎所有的消息队列产品都使用一种非常朴素的“请求-确认”机制，确保消息不会再传递过程中由于网络或者服务器故障丢失。具体的做法也非常简单。在生产端，生产者先讲休息发送给服务端，也就是Broker，服务端在收到消息并将消息写入主题或者队列后，会给生产者发送确认的响应。

如果生产者没有收到服务端的确认或者失败的响应，则会重新发送消息；在消费端，消费者在接收到消息并完成自己的消费业务逻辑（比如，将数据保存到数据库中）后，也会给服务端发送消费成功的确认，服务端只有收到消费确认后，才认为一条消息被成功消费，否则它会给消费者重新发送消息，直到收到对应的消费成功确认。

这个确认机制很好地保证了消息传递过程中的可靠性，但是，引入这个机制在消费端带来了一个不小的问题，为了确保消息的有序性， 在某一条消息被成功消费之前，下一条消息是不能被消费的，否者就会出现消息空洞，违背了有序性这个原则。

也就是说，每个主题在任意时刻，之多只能有一个消费者实例在进行消费，那就没法通过水平扩展消费者的数量来提升消费端总体的消费性能，为了解决这个问题，RocketMQ主题下增加了队列的概念

每个主题包含多个队列，通过多个队列来实现多实例并行生产和消费。需要注意的是RocketMQ只在队列上保证消息的有序性，主题层面是无法保证消息的咽哽顺序的。
RocketMQ中，订阅的概念是通过消费组来体现的，每个消费组都消费中体中一份完整的消息，不同消费组之间消费进度彼此不收影响，也就是说，一条喜爱西被消费组1消费过，也会给消费组2消费。
消费组中包含多个消费者，同一个组内的消费者是竞争关系，每个消费者赋值消费消费组内的一部分消息，如果一条消息被消费者1消费了，那同组的其他消费者就不会再收到这条消息。
再topic的消费过程中，由于消息需要被不同的组进行多次消费，所以消费完的小心并不会立即被删除，这就需要RocketMQ为每个消费组在每个队列上维护一个消费位置，这个位置之前的消息都被消费过，之后的消息都没有被消费国，每成功消费一条消息，消费位置就+1，这个消费位置非常重要，在使用队列的时候，消息丢失的原因大多是由于消费位置处理不当导致的。

kafka

kafka于周边生态系统的兼容性是最好的，尤其在大数据和刘计算领域，机会所有的相关开源软件系统都会支持kafka
kafka使用java和Scala语言开发，设计上大佬适应了批量和异步的思想，这种设计使得kafka能做到超高性能
尤其是异步收放的性能，是三者中最好的，但是与RocketMQ没有量级上的差异，大约每秒可以处理几十万条数消息
kafka这种异步批量的设计带来的问题是，它的同步发送消息的响应延时较高，因为当客户端发送一条消息的时候回，kafka并不会立即发送出去，而是要等一会攒一批再发送，再他的broker只，很多地方都会使用这种设计，当你的业务场景中，每秒消息数量没有那么多的时候，kafka反而延时会比较高，所以，kafka不太适合在线业务场景，

kafka的消息模型

RocketMQ中对应的概念，和生产消费过程的确认机制，完全适用于kafka，唯一的区别是，kafka中，队列这个概念名称不一样，kafka中对应名称是“分区（Partition）”，含义和功能没有任何区别。