消息队列主要在收发两端来工作,是依靠的业务代码来进行确认收发的,在服务端,我们需要利用持久化和复制的方式,那么本次,我们就说一下消息复制所需要解决的一些问题
来分别拿RocketMQ和Kafka来看这些问题如何解决的
消息复制需要面临什么问题
对于消息队列来说,我们希望能够兼具高性能,高可用,数据一致性等特点
但是消息的高可用必然带来复制,复制必然会导致性能的下降
消息写入的节点越多,可用性和可靠性就越好,但是写入性能降低,是一个天然的矛盾
要保证数据的一致性,需要采用 主-从 复制模式
主-从 模式,先写到主节点上,从节点只负责复制数据,如果出现主从数据不一致的情况,以主节点上的数据为准
高可用,就是主节点宕机的时候,从节点会有一个升为主节点
这样的实现方式,我们可以采用主从的复制模式,或者采用自我选举,让存活的节点通过投票的方式,选出一个新的节点
而大部分的赋值实现,都是讲消息写入部分的副本就算成功,避免时间过于长
现在,没有一种完美的实现方案,能够同时兼顾高性能,高可用,一致性
不同的消息队列选择了不停的赋值实现方式,各有优缺点,接下来,我们看一下RocketMQ和Kafka是如何实现复制的
1.RocketMQ的复制方式
原本的RocketMQ的赋值模式,支持同步复制和异步复制两种,异步复制需要写的副本数是1个,同步复制需要写的副本数是2个
在异步复制中,也是先写入到了本地磁盘,才会返回写入成功,所以即使主节点宕机,消息也不会丢失
而且,对于可用性,RocketMQ支持,多对主从节点去解决可用性
对于一个主题,会有着多个主从节点承担主题消费中的一部分
但是出现了一个问题,虽然多个主从节点承担了每个主题中的一部分
但是如果想要利用hash,将一个用户下的消息发往一个主从节点,如果主从出现了问题,那么是否会出现无法生产的问题?
后来,RocketMQ引入了Dledger,来进行解决这个复制的问题
这个Dledger,就是在写入消息的时候,要求将消息复制到半数以上的节点,然后给客户端返回成功
然后如果主节点出现了问题,因为复制到半数及以上的节点,那么肯定会有一个节点和主节点的数据保持同步,在选举的时候,必然选举成为新的节点,保证了数据的一致性和不丢消息
2.Kakfa的赋值方式
Kafka的复制单位是分区,每个分区的几个副本之间,构成了一个小的复制集群,Broker是这些分区副本的容器.所以并不分主从
分区的副本采用的是一主多从的方式,Kafka写入消息的时候,采用一步复制,但是主节点写完消息后,不会马上返回写入成功,而是等待足够多的节点复制成功后返回
至于需要复制多少个节点,则是由一个配置项 ISR控制的(ISR的数量中,包含了主节点)
Kafka还利用了ZK来保证数据的可用性,如果主节点宕机了,就会丧失心跳,就触发了新的选举流程,保证数据的一致性
Kafka还能配置,ISR的数量不低于多少,就继续提供服务,但是可能导致数据一致性的降低
本章的思考题
我们有5节点的RMQ集群,采用Dledger5副本复制,集群中只有一个主题,连有50个集群
那么Kafka如何配置呢?