Gaea中配置如何更新

一、etcd里存的是什么（核心：Namespace JSON配置）

Gaea 分两类配置：

1. Proxy本地启动配置（ini）：etcd地址、日志、监听端口，不放在etcd，很少改
2. 动态租户配置（存在etcd，JSON）：每个业务租户对应一个 namespace ，这是etcd里主体内容

etcd key 前缀一般类似：
/gaea/{cluster_name}/namespace/{ns_name}

JSON里面包含这些信息：

1. 账号权限：该namespace下MySQL账号、密码、白名单、连接限流
2. Slice 后端实例信息：

• 一组MySQL（主库、从库列表、地址端口）
• 读写分离策略：读走从库、主从权重、延迟阈值

3. 分片路由规则（重点）

• 路由模式： kingshard / mycat 两种
• 分库分表字段、分片数量、分片算法（hash/range）
• 表分布：哪张表落在哪个slice

4. SQL黑白名单、超时、事务限制、连接池参数
5. 状态标记：版本号、prepare/commit标记（用于两阶段热更）

补充：etcd还存少量agent心跳、实例健康状态，主体是namespace配置。

二、配置是怎么更新的（两阶段热加载，面试高频）

Gaea不是简单watch到key变更就直接切，是CC控制的2PC式热更新，保证集群所有proxy配置一致性，避免一部分proxy新配置、一部分旧配置（脑路由）

完整流程

1. DBA 在 gaea-web 页面修改配置（改分片、加从库、改路由）
2. web 调用 gaea-cc ，cc 先写入新版本namespace配置到etcd（新version）
3. Prepare阶段（预加载）
   cc 向集群所有gaea-proxy发prepare指令；
   proxy 收到后，从etcd拉取新版本配置，新建一套独立路由、连接池资源，不替换正在跑的旧配置；
   全部proxy prepare成功，才往下走；任意一个失败，直接回滚，业务无影响。
4. Commit阶段（切换生效）
   cc 下发commit信号；
   proxy 原子切换路由指针：新请求走新namespace配置；老会话、老连接继续跑完旧版本，平滑过渡，不踢连接。
5. 旧资源慢慢GC释放，更新完成。

两种监听机制区分开

• ✅ 控制面：cc主动推送prepare/commit（主流程，保证一致性）
• ✅ proxy同时持续watch etcd key：兜底。proxy重启、新proxy上线时，通过watch主动拉取当前最新namespace配置。

❗ 关键点：不是etcd watch事件直接触发切换，watch只负责感知版本、拉数据；真正切换时机由cc统一调度，两阶段提交，保证全集群proxy配置一致。

三、Mermaid时序图

四、一句话总结

etcd 存储每个业务namespace的JSON配置：后端MySQL实例、读写分离、分库分表路由、账号限流；
更新由gaea-cc做两阶段热更，先全部proxy预加载、全部成功再统一commit切换；proxy同时watch etcd，用于新节点启动和故障后自动同步配置，全程不需要重启proxy。