3节点etcd集群故障时Apache APISIX能否正常获取配置及运行

2个etcd节点故障时APISIX的配置获取情况 #

结论：无法从etcd侧拉取新配置/感知配置变更，已加载的存量配置可正常使用

• 背后核心原因和etcd的Raft一致性协议逻辑有关：3节点etcd集群的法定存活节点数（quorum）要求为2，只有至少2个节点健康在线，集群才能完成leader选举、数据写入、强一致读等核心操作。
• 当2个节点故障后，仅剩的1个etcd节点无法满足多数派共识要求，会直接停止对外提供读写服务，APISIX无法和etcd完成正常交互，自然拉取不到新发布的配置，也无法感知到已有的配置变更。
• 但APISIX本身采用内存全量缓存的配置机制：启动时会把etcd中存储的所有路由、插件、上游等配置全量拉取到工作进程内存中，处理用户请求时直接读本地内存缓存，不需要实时请求etcd。只要APISIX进程不重启，这部分存量缓存的配置可以正常生效，流量转发不会受影响。

所有etcd节点全故障时APISIX的运行情况 #

结论：进程不重启的情况下存量转发能力正常，无法处理配置变更，重启后服务不可用

• APISIX的数据面流量转发完全依赖本地内存缓存的配置，不需要实时和etcd交互。所以etcd集群全挂时，只要APISIX进程保持运行，已经配置好的路由规则、插件逻辑、上游节点信息都可以正常生效，请求转发不会中断。
• 但此时所有配置变更操作都会失效：不管是新增路由、修改插件参数还是调整上游节点列表，都需要先写入etcd才能同步到所有APISIX节点，etcd不可用的情况下这类操作会直接失败，APISIX后台的配置同步进程也会持续重试连接etcd，无法获取任何新配置。
• 如果这个阶段重启APISIX进程，服务会直接启动失败：APISIX的启动流程第一步就是连接etcd拉取全量配置初始化本地内存缓存，etcd集群全故障会导致这一步流程报错，进程无法正常拉起，必须等etcd集群恢复后才能重启成功。

内容的提问来源于stack exchange，提问作者Baoyuan