NGINX 向云原生演进，All in OpenNJet
配置同步
上一篇文章介绍了OpenNJet如何实现高可用配置，这一篇文章介绍下高可用模式下实现集群配置同步的功能。OpenNJet有很多动态配置的模块，这些动态的配置可以利用我们HA模块实现在主备节点之间进行同步。
主节点通过动态配置接口（声明式api或者命令式api）动态更新配置，然后backup节点能够及时同步这些配置。主节点宕机，backup节点动态更新配置，再主节点重新起来后，也能够及时同步更新的配置。最终保证主备节点都能够保证彼此配置的最新同步。
测试
配置说明
下面的测试场景，均以一台主节点，一台backup节点进行测试
主节点： 192.168.40.136
broker进程配置如下
C++
#配置主节点监听端口和ip
listener 1883 192.168.40.136
#配置本地socket地址，用于本地worker进程通信
listener 0 /root/bug/njet1.0/data/mosquitto.sock
log_dest file logs/mosquitto.log
log_type debug
log_type information
log_type error
log_type warning
log_type notice
allow_anonymous true
persistence true
autosave_on_changes true
autosave_interval 1
persistence_location /root/bug/njet1.0/data/
backup节点：192.168.40.91
broker进程配置如下：
C++
#配置backup节点监听端口和ip
listener 1883 192.168.40.91
#配置本地socket地址，用于本地worker进程通信
listener 0 /root/bug/njet1.0/data/mosquitto.sock
#配置需要连接的主节点地址信息
connection bridge-backup
address 192.168.40.136:1883
#topic主题过滤掉get相关接口请求
topic /dyn/# both 0
topic /ins/# both 0
log_dest file logs/mosquitto.log
log_type debug
log_type information
log_type error
log_type warning
log_type notice
allow_anonymous true
persistence true
autosave_on_changes true
autosave_interval 1
persistence_location /root/bug/njet1.0/data/
命令式API 消息同步
主节点更新消息，backup节点同步消息
往主节点新增一个location /clb，观察backup节点是否同步新增
往主节点通过动态location接口add一个location
通过其他模块get接口查询，可发现主节点刚才的location已经存在
从backup节点查看，发现也存在该location，同步成功
backup节点更新消息，主节点同步消息
往backup节点新增一个location /clb2，观察主节点是否同步新增
往backup节点通过动态location接口add一个location
通过其他模块get接口查询，可发现backup节点刚才的location已经存在
从主节点查看，发现也存在该location，同步成功
声明式API消息同步
主节点更新消息，backup节点同步消息
通过修改location /clb 下limit conn个数进行验证
主节点修改前：conn数量为100
修改主节点该值为200
观察backup节点的值，发现已经为200，同步成功
backup节点更新消息，主节点同步消息
通过修改location /clb 下limit conn个数进行验证
backup点修改为300
观察主机点，也为300，同步成功
主节点退出， backup节点配置reload后不会消失
stop掉主节点，观察backup节点配置
观察backup节点，仍然是300
将backup节点的值修改为400，然后将backup节点reload，重新get发现值还为400
主节点重新加入，会同步backup节点消息
start主节点，观察主节点配置是否会同步backup节点的动态配置
重新启动主节点、
观察主节点的值，已经为400，说明同步成功
已知问题
在有命令式api 比如location动态删除的消息时，会同步失败
OpenNJet 最早是基于 NGINX1.19 基础 fork 并独立演进，具有高性能、稳定、易扩展的特点，同时也解决了 NGINX 长期存在的难于动态配置、管理功能影响业务等问题。 邮件组 官网
