|
|
# 消息中间件相关的知识
|
|
|
|
|
|
## 技术调研: Kafka RocketMQ RabbitMQ 技术选型
|
|
|
- 其实技术调研说白了，就是对一个技术去找到一些业内常用的开源实现，然后对各种不同的实现都进行一些调研，对比一
|
|
|
下他们的优劣势，看看谁比较符合我们的需求，谁比较适合我们来使用。
|
|
|
|
|
|
### 1. 思考的问题
|
|
|
- 业内常用的MQ有哪些?
|
|
|
- 每一种MQ各自的表现如何?
|
|
|
- 这些MQ在同等机器条件下，能抗多少QPS(每秒抗几千QPS还是几万QPS)?
|
|
|
- 性能有多高(发送一条消息给他要2ms还是20ms)?
|
|
|
- 可用性能不能得到保证(要是MQ部署的机器挂了怎么办)?
|
|
|
- 他们会不会丢失数据?
|
|
|
- 如果需要的话能否让他们进行线性的集群扩容(就是多加几台机器)?
|
|
|
- 消息中间件经常需要使用的一些功能他们都有吗(比如说延迟消息、事务消息、消息堆积、消息回溯、死信队列，等等)?
|
|
|
- 这些MQ在文档是否齐全?社区是否活跃?在行业内是否广泛运用?是用什么语言编写的?
|
|
|
|
|
|
### 2. Kafka、RabbitMQ以及RocketMQ的调研对比
|
|
|
|
|
|
#### 2.1 Kafka的优势和劣势
|
|
|
- 优势
|
|
|
- Kafka的吞吐量几乎是行业里最优秀的，在常规的机器配置下，一台机器 可以达到每秒十几万的QPS，相当的强悍。
|
|
|
- Kafka性能也很高，基本上发送消息给Kafka都是毫秒级的性能。
|
|
|
- 可用性也很高，Kafka是可以支持集群部署的，其中部分机器宕机是可以继续运行的。
|
|
|
- 劣势
|
|
|
- Kafka比较为人诟病的一点，似乎是丢数据方面的问题，因为Kafka收到消息之后会写入一个磁盘缓冲区里，并没有直接落地到物理
|
|
|
磁盘上去，所以要是机器本身故障了，可能会导致磁盘缓冲区里的数据丢失。
|
|
|
- Kafka另外一个比较大的缺点，就是功能非常的单一，主要是支持发送消息给他，然后从里面消费消息，其他就没有什么额外的高
|
|
|
级功能了。所以基于Kafka有限的功能，可能适用的场景并不是很多。
|
|
|
- 业界实践1
|
|
|
- 基本行业里的一个标准，是把Kafka用在用户行为日志的采集和传输上，比 如大数据团队要收集APP上用户的一些行为日志，
|
|
|
这种日志就是用Kafka来收集和传输的。
|
|
|
- 因为那种日志适当丢失数据是没有关系的，而且一般量特别大，要求吞吐量要高，一般就是收发消息，不需要太多的高级功能，
|
|
|
所以 Kafka是非常适合这种场景的。
|
|
|
#### 2.2 RabbitMQ的优势和劣势
|
|
|
- 优势
|
|
|
- 在中国使用的企业很多, 尤其是金融行业, 一线互联网大厂，而且直到现在都有很多中小型公司在使用RabbitMQ
|
|
|
- 可以保证数据不丢失，也能保证高可用性，即集群部署的时候部分机器宕机可以继续运行
|
|
|
- 支持部分高级功 能，比如说死信队列，消息重试之类的
|
|
|
- 缺点
|
|
|
- RabbitMQ的吞吐量是比较低的，一般就是每秒几万的级别，所以如果遇到特别特别高并发的情况下，支撑起来是有点困难的。
|
|
|
- 他进行集群扩展的时候(也就是加机器部署)，还比较麻烦。
|
|
|
- 修改困难，开发语言是erlang，国内很少有精通erlang语言的工程师，因此也没办法去阅读他的源代码，甚至修改他的源代码。
|
|
|
- 业界表现
|
|
|
- 很多BAT等一线互联网大厂都切换到使用更加优秀的RocketMQ了，很多中小型公司觉得 RabbitMQ 可以满足自己的需求还在继续使用中。
|
|
|
- 中小型公司认为 RabbitMQ已经足以满足需求, 不需要部署特别大规模的集群，也没必要去阅读和修改RabbitMQ的源码,迁移复杂。
|
|
|
#### 2.3 RocketMQ的优势和劣势
|
|
|
- RocketMQ是阿里开源的消息中间件，久经沙场，非常的靠谱。他几乎同时解决了Kafka和RabbitMQ的缺陷。
|
|
|
- 优势
|
|
|
- RocketMQ的吞吐量也同样很高，单机可以达到10万QPS以上。
|
|
|
- 可以保证高可用性，性能很高。
|
|
|
- 支持通过配置保证数据绝对不丢失。
|
|
|
- 可以部署大规模的集群。
|
|
|
- 支持各种高级的功能，比如说延迟消息、事务消息、消息回溯、死信队列、消息积压，等等。
|
|
|
- RocketMQ是基于Java开发的，符合国内大多数公司的技术栈，很容易就可以阅读他的源码，甚至是修改他的源码。
|
|
|
- RocketMQ是非常适合用在Java业务系统架构中的，因为他很高的性能表现，还有他的高阶功能的支持，可以让我们解决各种业务问题。
|
|
|
- 劣势
|
|
|
- RocketMQ 的官方文档相对简单一些，但是Kafka和RabbitMQ的官方文档就非常的全面和详细，这可能是RocketMQ目前唯一的缺点。
|
|
|
- PS: RocketMQ 现在已经交给 Apache 基金会在维护, 除了团队没有硬实力的因素，其他暂时无劣势, 建议解决这个问题, 使用。
|
|
|
- 使用考虑
|
|
|
- 如果现在是一个中小型互联网公司，看起来似乎RabbitMQ足以应对需求，但是假设未来成长为一个大公司?
|
|
|
也许也会有每秒几十万的QPS，也许以后也需要对MQ进行源码的二次开发，那此时RabbitMQ还合适吗?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
