常用的消息中间件有，Kafka、ActiveMQ、RabbitMQ、RocketMQ。
消息中间件选型
| 特性 | ActiveMQ | RabbitMQ | RocketMQ | Kafka |
|---|---|---|---|---|
| 单机吞吐量 | 万级，比 RocketMQ、Kafka 低一个数量级 | 同 ActiveMQ | 10 万级，支撑高吞吐 | 10 万级，高吞吐，一般配合大数据类的系统来进行实时数据计算、日志采集等场景 |
| topic 数量对吞吐量的影响 | topic 可以达到几百/几千的级别，吞吐量会有较小幅度的下降，这是 RocketMQ 的一大优势，在同等机器下，可以支撑大量的 topic | topic 从几十到几百个时候，吞吐量会大幅度下降，在同等机器下，Kafka 尽量保证 topic 数量不要过多，如果要支撑大规模的 topic，需要增加更多的机器资源 | ||
| 时效性 | ms 级 | 微秒级，这是 RabbitMQ 的一大特点，延迟最低 | ms 级 | 延迟在 ms 级以内 |
| 可用性 | 高，基于主从架构实现高可用 | 同 ActiveMQ | 非常高，分布式架构 | 非常高，分布式，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用 |
| 消息可靠性 | 有较低的概率丢失数据 | 基本不丢 | 经过参数优化配置，可以做到 0 丢失 | 同 RocketMQ |
| 功能支持 | MQ 领域的功能极其完备 | 基于 erlang 开发，并发能力很强，性能极好，延时很低 | MQ 功能较为完善，还是分布式的，扩展性好 | 功能较为简单，主要支持简单的 MQ 功能，在大数据领域的实时计算以及日志采集被大规模使用 |
| 社区活跃度 | 不太活跃 | 活跃 推荐 | 阿里出品不太活跃 - apache | 无需多说 推荐 |
使用消息中间件的目的
解耦
通过一个 MQ，Pub/Sub 发布订阅消息模型，系统就跟其它系统彻底解耦了。异步
将系统之间调用关系从同步调用，变成了发送到MQ后的异步调用，提高了访问速度。削峰
通过MQ，将消息消费时间的控制交给了消费者端，使得MQ后端应用的稳定性得以提升。
消息队列的弊端
- 系统可用性降低
消息队列的高可用方式有以下两种：
以Kafka为例，从0.8版本以后，Kafka就可以实现HA了，每个 partition 的数据都会同步到其它机器上，形成自己的多个副本。所有 replica 会选举一个 leader 出来，那么生产和消费都跟这个 leader 打交道，然后其他 replica 就是 follower。写的时候，leader 会负责把数据同步到所有 follower 上去，读的时候就直接读 leader 上的数据即可。
另一种模式是RabbitMQ 的镜像集群模式，在镜像集群模式下，你创建的 queue，无论元数据还是 queue 里的消息都会存在于多个实例上，就是说，每个 RabbitMQ 节点都有这个 queue 的一个完整镜像，包含 queue 的全部数据的意思，这种模式拓展性比较差。
- 系统复杂度提高
用到MQ需要考虑两个问题：
- 如何保证消息不被重复消费
本身MQ在极端情况下并不能保证数据不会被消费两次，以Kafka为例，虽然有offset（新版的 Kafka 已经将 offset 的存储从 Zookeeper 转移至 Kafka brokers，并使用内部位移主题 __consumer_offsets 进行存储。），但是Kafka在提交offset数据到topic时忽然宕机了，这个时候数据也无法保证不被重新消费两次。所以这个本身要开发者保证，比如保证数据的幂等性，在插入数据到数据库前先查询一下，查询到了进行update操作。如果数据是直接写redis，那就无所谓，redis是set本身就是幂等的;或者基于数据库的唯一键来保证重复数据不会重复插入多条，INSERT INTO ...ON DUPLICATE KEY UPDATE；或者生产者发送每条数据的时候，里面加一个全局唯一的 id，类似订单 id 之类的东西，然后你这里消费到了之后，先根据这个 id 去比如 Redis 里查一下。
- 如何保证消息不丢失
RabbitMQ 持久化
Kafka 持久化
- 如何保证顺序性
RabbitMQ:
拆分多个 queue，每个 queue 一个 consumer；或者一个 queue 但是对应一个 consumer，然后这个 consumer 内部用内存队列做排队，然后分发给底层不同的 worker 来处理。
kafka: kafka的topic是无序的，但是一个topic包含多个partition，每个partition内部是有序的。生产者按照一定的规则写到同一个partition，不同的消费者读不同的partition的消息，就能保证生产和消费者消息的顺序。或者写 N 个内存 queue，具有相同 key 的数据都到同一个内存 queue；然后对于 N 个线程，每个线程分别消费一个内存 queue。