4. 闭环中间件架构设计：整体架构分层、核心组件与数据流
缓存一致性闭环中间件的架构设计遵循“分层解耦、闭环反馈”的核心思想。整体架构自上而下划分为 接入层、协调层、执行层 和 存储层，通过三个核心组件——协调器、监听器、执行器——形成完整的数据变更检测与补偿回路。
4.1 整体架构分层
架构采用四层模型，每层职责明确，层间通过标准接口通信，便于独立扩展与故障隔离。
| 层次 | 职责 | 关键组件 | 故障影响范围 |
|---|---|---|---|
| 接入层 | 接收业务请求，解析缓存操作指令，进行协议适配与流量整形 | API 网关、协议适配器、限流模块 | 单点故障影响入口，需多副本部署 |
| 协调层 | 维护一致性状态机，调度补偿任务，管理全局时钟与版本向量 | 协调器、状态管理器、版本时钟 | 核心决策节点，需 Raft 或 Paxos 保证高可用 |
| 执行层 | 执行缓存失效、双写、异步补偿等具体操作，采集执行指标 | 执行器、监听器、指标采集器 | 无状态水平扩展，单节点故障不影响全局 |
| 存储层 | 持久化变更日志、补偿记录、配置元数据 | MySQL、Redis、Kafka、etcd | 依赖存储自身高可用机制 |
设计要点： 协调层是闭环中间件的“大脑”，必须保证其决策的强一致性；执行层是“手脚”，追求高吞吐与低延迟，允许最终一致性。
4.2 核心组件详解
4.2.1 协调器（Coordinator）
协调器是整个闭环的决策中心，负责维护一致性协议的状态机，并驱动补偿流程。其核心职责包括：
- 版本管理： 为每次数据变更分配全局单调递增的版本号，用于检测冲突。
- 状态仲裁： 根据监听器上报的变更事件，判断缓存与数据库的状态是否一致。
- 任务调度： 当检测到不一致时，生成补偿任务并下发至执行器。
- 超时重试： 对未确认的补偿任务进行指数退避重试，最多重试 3 次。
4.2.2 监听器（Listener）
监听器部署在数据源侧，负责捕获数据变更事件并上报给协调器。根据监听方式不同，分为两种模式：
| 模式 | 实现方式 | 延迟 | 适用场景 |
|---|---|---|---|
| Binlog 监听 | 模拟 MySQL Slave 解析 Binlog，提取行变更 | 毫秒级 | 数据库主从架构、对实时性要求高的场景 |
| 消息队列监听 | 业务代码显式发送变更消息到 Kafka/RocketMQ | 秒级 | 异构数据源、已有消息中间件基础设施 |
4.2.3 执行器（Executor）
执行器是补偿动作的实际执行者，接收协调器下发的任务，执行缓存失效、双写修复等操作，并上报执行结果。执行器采用无状态设计，支持水平扩展。
- 缓存失效： 直接删除或设置过期 Key，适用于读多写少场景。
- 双写修复： 将最新数据同时写入缓存和数据库，适用于写后立即读场景。
- 异步补偿： 通过消息队列异步重试，避免阻塞主流程。
4.3 数据流与反馈回路
闭环中间件的数据流遵循“检测 → 决策 → 执行 → 确认”的循环，形成完整的反馈回路。下面通过 SVG 图展示一次典型的数据变更闭环流程。
4.4 核心组件协作流程
为了更清晰地展示三个核心组件之间的协作关系，下面给出组件间的交互时序图。
4.5 架构设计关键原则
- 闭环自愈： 任何一次缓存与数据库的不一致，都必须在一个有限时间窗口内被检测并修复，不允许存在“永久不一致”状态。
- 幂等补偿： 执行器的补偿操作必须支持幂等，避免因重试导致数据重复写入或错误覆盖。
- 故障隔离： 协调器、监听器、执行器各自独立部署，任一组件故障不影响其他组件的正常运行。
- 可观测性： 每个组件必须暴露关键指标（如补偿次数、延迟、失败率），便于监控和故障排查。
常见误区： 将协调器与执行器合并部署，虽然减少了网络开销，但会引入单点故障风险，且难以独立扩缩容。建议始终将决策与执行分离。