前言
看了 《RocketMQ 消息中间件实战派(上册)》前面一点,书中代码太多容易陷入细节。
这里简单描述下 RocketMQ Name Server 无状态表现在什么地方。
对于无状态节点热更新,也提供解决方案。
1. Name Server 无状态特点
-
单节点视角
可以不用持久化 Broker 的路由信息,由 Broker 主动上报作为运行时的数据即可。 -
集群视角
集群中的节点互相不认识 -
对比 zk
RocketMQ 将主从的概念下沉到 Broker 层,包括选举也是发生在 Broker内部。对于 Name Server ,只是登记 Broker 的路由及主从的结果 -
表现
对客户端来说只读,写操作只开放给 broker。
-
好处
name server 可以做高可用,从第一个节点读不到,再从第二个节点读即可。
name server 销毁与创建,不需要跟客户端侧通信。
对于客户端侧,name server 就是一个无状态服务,目标就是从 name server 获得路由地址,谁给这个路由地址并无所谓。
2. Name Server 地址服务
运维新增 Name Server 节点,如何保证客户端能找到新加入的 name server 节点呢?
幸运的是,RocketMQ 提供了配置地址服务(多个选择)。Broker Consumer Producer 都可以读这个地址服务。
遗憾的是,有了地址服务,只是为 Broker Consumer Producer 读取路径。ip的写入还是得手动写。
3. Name Server 手动配置
-
Nacos 配置
《RocketMQ 消息中间件实战派(上册)》中引入了 Nacos 解决热更新问题,从笔者的视角来看有点重。 -
Ngnix 配置
一个简单的方案是对url做反向代理,生产用 ansible 热更新
http {
upstream rocketmq-namesrv {
# 配置多个 NameServer
server 192.168.1.1:9876;
server 192.168.1.2:9876;
server 192.168.1.3:9876;
}
server {
listen 9876; # 监听端口,与 NameServer 保持一致
server_name namesrv.mq.example.com; # 配置一个域名
location / {
proxy_pass http://rocketmq-namesrv;
proxy_set_header Host $host;
}
}
}
配合RocketMQ的长轮询机制,要同步把超时时间调一下
proxy_connect_timeout 10s;
proxy_read_timeout 60s;
proxy send timeout 60s;
后记
总的来说,让 Broker Consumer Producer 感知新 Name Server 有以下步骤
- 手动启动 Name Server 节点,记住机器ip
- 选择 RocketMQ 的 Name Server 地址服务
- 为地址服务手动写入新ip