消息中间件学习

常用的消息中间件有,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需要考虑两个问题:

  1. 如何保证消息不被重复消费

本身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 里查一下。

  1. 如何保证消息不丢失

RabbitMQ 持久化

RabbitMQ 持久化

Kafka 持久化

Kafka 持久化

  1. 如何保证顺序性

RabbitMQ:
拆分多个 queue,每个 queue 一个 consumer;或者一个 queue 但是对应一个 consumer,然后这个 consumer 内部用内存队列做排队,然后分发给底层不同的 worker 来处理。

kafka: kafka的topic是无序的,但是一个topic包含多个partition,每个partition内部是有序的。生产者按照一定的规则写到同一个partition,不同的消费者读不同的partition的消息,就能保证生产和消费者消息的顺序。或者写 N 个内存 queue,具有相同 key 的数据都到同一个内存 queue;然后对于 N 个线程,每个线程分别消费一个内存 queue。

0%