rocketmq-如何解决高可用问题?

228 阅读3分钟

架构

官方架构图

主要分三大块:
1、注册中心集群
2、broker集群
broker节点包含主节点和从节点
3、生产者和消费者
都是客户端

复制数据

主从复制,其实就是把主节点数据复制到从节点。

自动切换

如果主节点挂了,从节点会自动晋升为主节点。

版本区别

1、高版本
4.5和以上,支持自动切换。

2、低版本
4.5以下,不支持自动切换。

自动切换-实现原理

1.主节点挂了

2.选择一个从节点

1)一个从节点

如果只有一个从节点,就选择这个从节点晋升为主节点。一般情况下,一个从节点就够了。

2)多个从节点

如果有多个从节点,就选举,过半以上节点选择了某个从节点,该节点才会晋升为主节点。

小结

高可用的核心

1.有一个备胎节点

2.如果故障,能实现自动切换功能

broker集群-读写数据

主节点

写和读。

从节点

最佳实践是不写也不读,只备胎。

从节点默认是不读,但是也可以设置为可读——但是最好不要这么做,因为徒增复杂度,容易引起数据不一致等问题。

注册中心集群-通信

broker节点注册到注册中心节点,而且是注册到每个注册中心节点。所以broker是和注册中心节点通信,并且是和注册中心的每个节点通信,而注册中心集群节点之间不通信。

broker注册到每个注册中心节点之后,生产者和消费者这两个客户端就可以和注册中心集群的随机一个注册中心节点通信拿到broker集群节点,然后生产者/消费者就可以和broker通信了。


来看下官方文档的描述

  • NameServer:NameServer是一个非常简单的Topic路由注册中心,其角色类似Dubbo中的zookeeper,支持Broker的动态注册与发现。主要包括两个功能:Broker管理,NameServer接受Broker集群的注册信息并且保存下来作为路由信息的基本数据。然后提供心跳检测机制,检查Broker是否还存活;路由信息管理,每个NameServer将保存关于Broker集群的整个路由信息和用于客户端查询的队列信息。然后Producer和Consumer通过NameServer就可以知道整个Broker集群的路由信息,从而进行消息的投递和消费。NameServer通常也是集群的方式部署,各实例间相互不进行信息通讯。Broker是向每一台NameServer注册自己的路由信息,所以每一个NameServer实例上面都保存一份完整的路由信息。当某个NameServer因某种原因下线了,Broker仍然可以向其它NameServer同步其路由信息,Producer和Consumer仍然可以动态感知Broker的路由的信息。
  • NameServer是一个几乎无状态节点,可集群部署,节点之间无任何信息同步。

和zookeeper的区别

那为什么和zk不一样呢?zk集群是有Leader节点的,而且只有leader才可以写。

mq的注册中心集群如何确保数据一致性?待补充

消费数据

如果主节点挂了,

1.高版本

从节点会自动晋升为主节点,然后就可写可读。

2.低版本

从节点不会晋升为主节点。那主节点的没有来得及消费的数据怎么办?消费者会从备胎节点读数据,这正是从节点的作用。

但是,此时,从节点是不能写数据的。所以,相当于主节点集群数量少了一个节点,就像dubbo集群服务一样,少了一个节点,是没有影响的。但是,如果剩下的主节点比较少,比如总共只有2个,然后还挂了一个,这个时候就会存在单点故障。

参考

github.com/apache/rock…