消息队列对比
主流MQ包括：kafka、ActiveMQ、RabbitMQ和RocketMQ
常见的MQ其实就上面的四种
| 特性 | ActiveMQ | RabbitMQ | RocketMQ | Kafka |
|---|---|---|---|---|
| 单机吞吐量 | 万级，吞吐量比RocketMQ和Kafka要低一个数量级 | 万级，吞吐量比RocketMQ和Kafka要低一个数量级 | 10万级，RocketMQ也是可以支撑高吞吐的一种MQ | 10万级1这是kafka最大的优点，就是吞吐量高。一般配置和数据类的系统进行实时数据计算、日志采集等场景 |
| 时效性 | ms级 | 微妙级，这是RabbitMQ的一大特点，就是延迟最低 | ms级 | 延迟在ms级内 |
| 可用性 | 基于主从架构实现高可用 | 高，基于主从架构实现高可用 | 非常高，分布式架构 | 非常高，kafka是分布式的，一个数据多个副本，少数机器宕机后，不会丢失数据，不会导致不可用 |
| 消息可靠性 | 有较低的概率丢失数据 | 消息不丢失 | 经过参数优化配置，可以做到0丢失 | 经过参数优化配置可以做到0丢失 |
| 核心特点 | MQ领域的功能及其完备 | 基于Erlang开发，所以并发能力强，性能及其好，延时很低 | MQ功能较为完善，还是分布式的，扩展性好 | 功能较为简单，主要支持简单的MQ功能，在大数据领域的实时计算以及日志采集被大规模使用，是实时上的标准。 |
| 非常成熟，功能强大，在业内大量公司以及项目都有应用。 但是偶尔消息丢失的概率，并且现在社区以及国内应用都越来越少，官方社区对ActiveMQ5.X维护越来越少，而且确实主要是基于解耦和异步来用的，较少在大规模吞吐场景中使用 | erlang语言开发的，性能及其好，延时很低。而且开源的版本，就提供的管理界面非常棒，在国内一些互联网公司近几年用RabbitMQ也是比较多一些，特别适用于中小型的公司 缺点显而易见，就是吞吐量会低一些，这是因为它做的实现机制比较中，因为使用erlang开发，目前没有多少公司使用其开发。所以针对源码界别的定制，非常困难，因此公司的掌控非常弱，只能依赖于开源社区的维护。 | 接口简单易用，毕竟在阿里大规模应用过，有阿里平台保障，日处理消息上 百亿之多，可以做到大规模吞吐，性能也非常好，分布式扩展也很方便，社区维护还可以，可靠性和可用性都是OK的，还可以支撑大规模的topic数量，支持复杂MQ业务场景。 | 仅仅提供较少的核心功能，但是提供超高的吞吐量，ms级别的延迟，极高的可用性以及可靠性，分布式可以任意扩展。 同时kafka最好是支撑较少的topic数量即可，保证其超高的吞吐量。 |
为什么Kafka的吞吐量这么高？
- 基于磁盘的顺序读写。磁盘的顺序读写性能高于内存随机读写。kafka的消息不断地追加到本地磁盘的末尾，而不是随机写入
- 利用了系统本身的Page cache。即利用操作系统本身的内存，而不是JVM的内存。这样避免了Object的消耗和CG问题。通过Page Cache，kafka的读写操作基本是基于内存的
- 零拷贝。Page Cache 结合 sendfile 方法，Kafka消费端的性能也大幅提升。这也是为什么有时候消费端在不断消费数据时，我们并没有看到磁盘io比较高，此刻正是操作系统缓存在提供数据。
- 分区分段+索引。topic中的数据暗道一个个的分区存储到不同的broker节点。而分区实际上又是segment分段存储的。因此kafka的message实际上分布式存储在一个个segment中，每次文件操作也是直接操作segment的。同时kafka又为每一个分段的数据文件建立索引。不仅提升数据读取效率，还提高数据处理的并行度
- 批量读写。kafka数据读写是批量的而不是单条的。写入数据时，可以采用批次写入。这样避免网络上频繁传输单个消息带来的延迟和带宽开销
- 批量压缩。在很多情况下，系统的瓶颈不是CPU或磁盘，而是网络IO，对于需要在广域网上的数据中心之间发送消息的数据流水线尤其如此。进行数据压缩会消耗少量的CPU资源,不过对于kafka而言,网络IO更应该需要考虑。
- 采取批量压缩，而不是每条message都压缩
- kafka支持多压缩协议
kafka速度的秘诀在于：它把所有的消息都变成一个批量的文件，并且进行合理的批量压缩，减少网络IO损耗，通过mmap提高I/O速度，写入数据的时候由于单个Partion是末尾添加所以速度最优；读取数据的时候配合sendfile直接暴力输出。，同样也因为如此，kafka的时效性并不高，不过也在ms以内
(https://www.cnblogs.com/18800105616a/p/13863254.html)
