消息中间件（MQ）的技术选型（Kafka、RabbitMQ、Ro
首先对MQ的技术选型需要考虑的因素有哪些
- 业内常用的MQ有哪些呢
- 每一种MQ的表现如何
- 这些MQ在同等机器条件下，能抗多少QPS（每秒扛几千QPS还是几万QPS）
- 性能有多高（发一条消息给它需要2ms还是20ms）
- 可用性能不能得到保证（要是MQ部署的机器挂了该怎么办）
- 它们会不会丢失数据
- 如何需要的时候，能否让它们进行线性的扩容（就是多加几台机器）
- 消息中间件经常需要用的一些功能有么（比如：延迟消息、事务消息、消息堆积、消息回溯、死信队列等）
- 这些MQ的文档是否齐全，社区的活跃度咋样，在行业内是否广泛使用，是采用什么语言开发的。
Kafka、RabbitMQ、RocketMQ的调研比对
（1）Kafkade 优势和劣势
优势：
在性能方面kafka可以说是业界非常优秀的一款中间件，在常规的机器配置下，一台机器可以达到每秒几十万的QPS。并且Kafka的性能也非常高，基本上发给kafka的消息都是毫米级别的，可用性也特别高，kafka是支持集群部署的，并且其中部分机器宕机，还是可以运行的。
劣势：
kafka有可能会丢失数据，因为kafka收到消息之后，会写一个磁盘缓冲区里，并没有直接落地到物理磁盘上去，所以机器故障之后，可能会导致磁盘缓冲区的数据丢失。另外一个缺点就是，kafka的功能比较单一，主要是支持发送消息给它，然后从里面消费消息，其它就没有什么额外的高级功能了，所以基于kafka有限的功能，可能适用的场景并不是很多。
综上所述：一般公司会利用kafka收集一些日志之类的消息，因为日志一般量特别大，即使丢几条数据也没事，并且要求吞吐量也高，一般就是收发消息，不需要太多的功能，所以kafka非常适合这个场景。
（2）RabbitMQ的优势和劣势
优势：
在RocketMQ没有出现之前，好多公司都从ActiveMQ切换到了RabbitMQ，它的优势在于可以保证数据不丢失，也能保证高可用性，即使集群部署部分机器宕机也能运行，然后支持部分高级功能，比如死信队列，消息重试之类的。
缺点：
RabbitMQ的吞吐量比较低，一般就是几万的级别，如果遇到特别高的并发时，支撑起来有点困难。并且进行集群的扩展也是比较麻烦的。还有就是开发语言用的是erlang，国内使用此语言的很少，所以对其深入的研究也是比较麻烦的。
（3）RocketMQ
优点：
RocketMQ几乎同时解决了Kafka和RabbitMQ的缺陷。它的吞吐量也非常高，单机可以达到10万的QPS以上，而且可以保证高可用性，并且可以通过配置达到数据保证不会丢失，可以部署大规模的集群，还支持各种高级功能，比如说延迟消息、事务消息、消息回溯、死信队列、消息积压等。而且RocketMQ是利用java开发的，符合国内的大多数公司的技术栈，很容易进行阅读源码和修改其内容。
缺点：
RocketMQ的官方文档相比较于kafka和RabbitMQ来说的话会相对简单一些，没有人家kafka和RabbitMQ的文档写的详细。
