在构建高并发系统（如秒杀抢购或高频量价处理平台）时，单机架构的瓶颈会迅速显现。为了保证系统的高可用与数据一致性，我们需要引入中间件与微服务架构。本文将梳理从底层并发控制到宏观服务治理的核心逻辑。
一、 兵马未动，原子先行：Redis 防超卖的底层逻辑
在高并发场景下，最典型的技术挑战是“读-改-写”带来的并发冲突。
- 并发冲突的根源： 简单的
GET判断库存再SET扣减，在多线程并发下会大概率导致超卖。这是因为多条指令之间缺乏原子性保障。 - Lua 脚本的降维打击： 应对超卖的最佳实践是将扣减逻辑封装为 Lua 脚本。由于 Redis 核心执行引擎是单线程排他的，执行 Lua 脚本时，整个 Redis 会处于伪事务状态，绝对避免了上下文切换和锁竞争，实现了极致的原子性。
- 架构漏斗： 验证逻辑不应全部堆积在 Redis 中。正确的做法是：网关层负责限流与身份校验 -> 业务层负责防重 -> Redis (Lua) 负责核心库存原子扣减 -> 数据库依靠行锁做最终一致性兜底。
二、 异步削峰：RabbitMQ 的受控推送
Redis 挡住了并发洪峰后，后端的数据库依然无法承受瞬间的海量写入。此时需要引入消息队列（MQ）进行异步解耦。
- Push vs Pull： RabbitMQ 默认采用 Push（主动推送）模式，相比于轮询 Pull，其实时性极高且网络开销小。
- 受控消费 (Prefetch Count)： 为了防止 Push 模式下消费者被海量消息“淹死”，必须设置 QoS 的
prefetch_count。这相当于给推送踩下刹车，确保消费者（如订单写入服务）能以自身的最大吞吐量平稳处理数据。
三、 微服务与服务发现：告别硬编码的“动态通讯录”
当系统被拆分为多个微服务并部署在 Docker 容器或多台机器上时，服务间的 IP 和端口是动态变化的。硬编码 IP 地址将导致系统完全丧失弹性伸缩能力。
此时，我们需要服务发现 (Service Discovery) 机制。它由三个角色构成：
- 注册中心： 存储所有可用服务的地址清单。
- 服务提供者 (Provider)： 启动时主动登记自己的地址。
- 服务消费者 (Consumer)： 调用前先查询清单获取目标地址。
四、 ZooKeeper 的协调艺术：ZNode 与 Watch 机制
在众多注册中心选型中，ZooKeeper 以其强一致性和出色的协调能力占据重要地位。它本质上是一个高可用的分布式状态同步中心。
- ZNode 逻辑节点： ZooKeeper 内部维护着一个类似文件系统的树状结构。服务提供者会在特定路径下（如
/services/pay）创建自己的 ZNode。 - 临时节点 (Ephemeral Node)： 这是服务健康检查的核心。提供者创建的是临时节点，一旦其进程崩溃或网络断开，该节点会自动消失。
- Watch 监听机制： 消费者不需要频繁轮询注册中心。它只需在对应的 ZNode 路径上挂载 Watcher。一旦节点发生变化（如某台服务器宕机），ZooKeeper 会主动推送通知，消费者随之更新本地的负载均衡地址池。
注意区分： ZooKeeper 实现的是典型的客户端发现。流量并不经过 ZooKeeper 转发，消费者拿到地址后，会直接与提供者进行点对点的 RPC/HTTP 通信。
五、 服务治理：双向管理的终极视角
在微服务链路中，“生产者（提供者）”与“消费者（调用者）”的角色是相对的。顺着数据流向，提供能力的为生产者，使用能力的为消费者。
ZooKeeper 通过对这两者的双向管理实现了服务治理：
- 对生产者： 管理其注册状态、健康心跳与负载权重，确保服务可用。
- 对消费者： 管理其订阅关系与动态配置，确保调用及时且受控。
掌握了这套机制，我们就拥有了系统的上帝视角，随时可以切断异常流量或动态扩容，真正让微服务架构“活”了起来。
六、 举例
秒杀请求的完整流转路径
第一阶段：网关寻址（控制流与数据流的交汇）
- 用户发起请求： 用户在客户端点击”立即抢购”，发送一个 HTTP 请求。
- 到达网关： 请求首先到达系统的 API 网关（比如 Nginx、Kong 或 Spring Cloud Gateway）。
- 查通讯录（本地缓存）： 网关内部集成了 ZooKeeper 客户端。网关并不是每次有请求都去实时查询 ZooKeeper，而是早就通过 Watch 机制将 ZooKeeper 里的”可用秒杀服务器 IP 列表”缓存在了自己的内存中。
- 负载均衡： 网关在本地内存列表中，利用算法（如轮询或一致性哈希），挑出一台可用秒杀服务器的 IP（例如
192.168.1.100）。
第二阶段：业务处理（纯数据流）
- 直接转发： 网关将用户的 HTTP 请求直接转发给
192.168.1.100这台秒杀服务器。在这个转发过程中，流量完全不经过 ZooKeeper。 - 交互 Redis： 秒杀服务器（即微服务实例）收到请求后，执行业务逻辑，与后端的 Redis 集群建立连接，发送封装好的 Lua 脚本去尝试扣减库存。
- 异步后续： Redis 返回扣减结果。如果扣减成功，秒杀服务器将订单信息投递到 RabbitMQ，最后沿着原路给用户返回响应。
建筑比喻
- ZooKeeper 是幕后调度： 它就像 DNS 域名解析服务器或 114 查号台。它只负责告诉调用方（网关或微服务）”目标服务器在哪”，绝不负责搬运请求。
- 微服务直连 Redis： 真正去和 Redis 交互的，是那些接收了网关转发、正在执行业务代码的具体微服务实例。
Leave a comment