如何进行消息队列的技术选型

- 大纲

1、为什么使用消息队列

2、消息队列有什么优点和缺点

3、kafka、activemq、rabbitmq、rocketmq都有什么优点和缺点

---

1、为什么使用消息队列

1. 先说一下消息队列的常见使用场景吧，其实场景有很多，但是比较核心的有3个：解耦、异步、削峰

解耦： A系统发送个数据到BCD三个系统，接口调用发送，那如果E系统也要这个数据呢？那如果D系统现在不需要了呢？现在A系统又要发送第二种数据了呢？A系统负责人濒临各种修改代码崩溃中。。。然后又有更加崩溃的事，A系统要时时刻刻考虑BCDE四个系统如果挂了咋办？要不要重发？要不要把消息存起来？

不使用MQ的系统解耦场景图:

使用MQ之后的解耦场景图:

---

异步： A系统接收一个请求，需要在自己本地写库，还需要在BCD三个系统写库，自己本地写库要3ms，BCD三个系统分别写库要300ms、450ms、200ms。最终请求总延时是3 + 300 + 450 + 200 = 953ms，接近1s。系统响应就会很慢

不使用MQ,高延时同步场景图:

使用MQ异步化后的接口性能优化图:

---

削峰： 每天0点到11点，A系统风平浪静，每秒并发请求数量就100个。结果每次一到11点~1点，每秒并发请求数量突然会暴增到1万条。但是系统最大的处理能力就只能是每秒钟处理1000个请求,系统就可能会死

不使用MQ的时候高峰期系统被打死场景图:

使用MQ高峰期系统削峰场景图:

---

2、消息队列有什么优点和缺点

1. 优点上面已经说了，就是在特殊场景下有其对应的好处，解耦、异步、削
2. 缺点呢？显而易见:
3. 系统可用性降低：系统引入的外部依赖越多，越容易挂。如：MQ挂了，整套系统不可用
4. 系统复杂性提高：加了MQ进来，需要考虑怎么保证消息没有重复消费？怎么处理消息丢失的情况？怎么保证消息传递的顺序性？
5. 一致性问题：A系统处理完了直接返回成功了，人都以为你这个请求就成功了；但是问题是，要是BCD三个系统那里，BD两个系统写库成功了，结果C系统写库失败了，这数据就不一致了。

所以消息队列实际是一种非常复杂的架构，引入它有很多好处，但是也得针对它带来的坏处做各种额外的技术方案和架构来规避掉，之后，你会发现，系统复杂度提升了一个数量级，也许是复杂了10倍。但是关键时刻，还是得用的

---

3、kafka、activemq、rabbitmq、rocketmq都有什么优点和缺点

activemq最早企业都用ActiveMQ，但是现在企业确实用的不多了。没经过大规模吞吐量场景的验证，社区也不是很活跃，所以这里不对比

特性	RabbitMQ	RocketMQ	Kafka
单机吞吐量	万级，吞吐量比RocketMQ和Kafka要低了一个数量级	10万级，RocketMQ也是可以支撑高吞吐的一种MQ	10万级别，这是kafka最大的优点，就是吞吐量高。 一般配合大数据类的系统来进行实时数据计算、日志采集等场景
topic数量对吞吐量的影响		topic可以达到几百，几千个的级别，吞吐量会有较小幅度的下降 (这是RocketMQ的一大优势，在同等机器下，可以支撑大量的topic)	topic从几十个到几百个的时候，吞吐量会大幅度下降 (所以在同等机器下，kafka尽量保证topic数量不要过多。 如果要支撑大规模topic，需要增加更多的机器资源)
时效性	微秒级，这是rabbitmq的一大特点，延迟是最低的	ms级	延迟在ms级以内
可用性	高，基于主从架构实现高可用性	非常高，分布式架构	非常高，kafka是分布式的，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用
消息可靠性		经过参数优化配置，可以做到0丢失	经过参数优化配置，消息可以做到0丢失
功能支持	基于erlang开发，所以并发能力很强，性能极其好，延时很低	MQ功能较为完善，还是分布式的，扩展性好	功能较为简单，主要支持简单的MQ功能，在大数据领域的实时计算以及日志采集被大规模使用上的标准

优劣总结：

1. RabbitMQ好处：
2. 0、基本不会丢数据
3. 1、吞吐量到万级，MQ功能比较完善、延时非常低（消息写到mq，到消费停留的时间）
4. 2、开源的管理界面，大量的操作可基于管理界面操作，包括创建queues、集群的监控等
5. 3、官方社区很活跃，几乎一个月发布几个版本。近几年比较企业使用的也比较多
6. ------------------
7. RabbitMQ劣势：
8. 0、吞吐量单机会低一些，因为它做的实现机制比较重
9. 1、erlang语言开发，很难看懂源码，企业很难定制和掌控，基本得依靠开源社区的快速维护和修复bug(不用到比较乱七八糟的功能，这个问题不大)
10. 2、集群动态扩展相对比RocketMq麻烦

---

1. RocketMQ好处：
2. 0、在阿里大规模应用过，日处理消息上百亿之多(阿里品牌保障)
3. 1、可以做到大规模吞吐、性能也非常好、分布式扩展很方便
4. 2、java源码开发，可以定制公司的MQ
5. 3、官方社区算活跃
6. ------------------
7. RocketMQ劣势：
8. 0、文档相对简单一些，接口不是按照JMS规范走的。有些系统要迁移需要修改大量代码
9. 1、阿里出台的技术，得做好这个技术万一被抛弃，官方停止维护得公司自己去维护或者靠社区修复一些bug

---

1. Kafka好处：
2. 0、仅仅提供较少的核心功能，但是提供超高的吞吐量
3. 1、ms级的延迟，极高的可用性以及可靠性，而且分布式可以任意扩展
4. 2、topic数量越少，保证其超高吞吐量
5. 3、大数据领域的实时计算、日志采集等场景，Kafka是业内标准，绝对不会黄
6. ------------------
7. Kafka劣势：
8. 0、topic从几十个到几百个的时候，吞吐量会大幅度下降
9. 1、有可能消息重复消费，那么对数据准确性会造成极其轻微的影响

个人建议：

1. ActiveMQ：不建议使用，没经过大规模吞吐量场景的验证，社区也不是很活跃，防止踩坑
2. Kafka: 如果是大数据领域的实时计算、日志采集等场景，用Kafka是业内标准
3. RabbitMQ:erlang语言开放，是由存大量个人散户，一般是不会黄，社区很活跃
4. RocketMQ:确实很不错，但是得想好社区万一突然黄掉的风险，对自己公司技术实力有绝对自信就推荐用RocketMQ

中小型公司技术挑战不是特别高，用RabbitMQ是不错的选择(吞吐量不错、功能也完备、管理后台方便、开源社区活跃。不一定要自己去看erlang源码，依靠社区快速迭代版本也是可以)

大型公司或者中大型公司，有基础架构研发实力，可以投入一组java的研发MQ源码，并可以进行改造，这种公司选择RocketMQ更合适，因为RocketMQ做的确实比RabbitMQ更好。（吞吐量、分布式等）

大数据领域的实时计算、日志采集等场景，kafka不用考虑