MQ
RocketMQ [ ‘rɑːkɪt ]
- 灵活可扩展性 RocketMQ 天然支持集群，其核心四组件（Name Server、Broker、Producer、Consumer）每一个都可以在没有单点故障的情况下进行水平扩展。
- 海量消息堆积能力 RocketMQ 采用零拷贝原理实现超大的消息的堆积能力，据说单机已可以支持亿级消息堆积，而且在堆积了这么多消息后依然保持写入低延迟。
- 支持顺序消息 可以保证消息消费者按照消息发送的顺序对消息进行消费。顺序消息分为全局有序和局部有序，一般推荐使用局部有序，即生产者通过将某一类消息按顺序发送至同一个队列来实现。s
- 多种消息过滤方式 消息过滤分为在服务器端过滤和在消费端过滤。服务器端过滤时可以按照消息消费者的要求做过滤，优点是减少不必要消息传输，缺点是增加了消息服务器的负担，实现相对复杂。消费端过滤则完全由具体应用自定义实现，这种方式更加灵活，缺点是很多无用的消息会传输给消息消费者。
- 支持事务消息 RocketMQ 除了支持普通消息，顺序消息之外还支持事务消息，这个特性对于分布式事务来说提供了又一种解决思路。
- 回溯消费 回溯消费是指消费者已经消费成功的消息，由于业务上需求需要重新消费，RocketMQ 支持按照时间回溯消费，时间维度精确到毫秒，可以向前回溯，也可以向后回溯。
- 天生为金融互联网领域而生，对于可靠性要求很高的场景，尤其是电商里面的订单扣款，以及业务削峰，在大量交易涌入时，后端可能无法及时处理的情况。
- 社区活跃一般、目前是支持java及c++，有些系统要迁移需要修改大量代码
rabbitMq [ ‘ræbɪt ]
- 消息队列
- 无序 （消息失败会放回队列）
- 根据消息头路由
- 一个头部（headers）交换器可以基于任意的消息头来路由消息。
- 在消息路由和过滤方面，灵活性好
- 消息存活时间、延迟/预定的消息
- 瞬时、持久故障 – 交付重试和死信交换器（DLX）来处理消息处理故障。
- 高级灵活的路由规则；
- 消息时序控制（控制消息过期或者消息延迟）；
- 高级的容错处理能力，在消费者更有可能处理消息不成功的情景中（瞬时或者持久）；
- 更简单的消费者实现。
kafka
- 发布/订阅模式
- 有序 （后续可以被继续处理）
- 不是中间件的一种实现，相反只是一种分布式流式系统
- Kafka的存储层是使用分区事务日志来实现的
- Kafka是按照预先配置好的时间保留分区中的消息，而不是根据消费者是否消费了这些消息。这种保留机制可以让消费者自由的重读之前的消息。
- Kafka的存储层来实现诸如事件溯源和日志审计功能。
- 消息留存
- 严格的消息顺序；
- 延长消息留存时间，包括过去消息重放的可能；
- 传统解决方案无法满足的高伸缩能力。
