一、高可用架构范式

高可用架构的主要目标是保障程序在面对硬件故障、软件异常或网络中断等风险时仍能持续对外提供服务。最大限度减少停机时间，确保业务连续性和数据一致性。为实现这一目标，程序通常会采用分层架构隔离风险、冗余设计保障数据灾备、故障转移机制实现应急恢复等。其设计范式已从传统的单点冗余演进为分布式环境下的全链路高可用程序。

使用者常见痛点包括：订单突然下单失败导致收入损失；说起来，库存信息滞后造成售罄误导；还有程序宕机时无法及时恢复业务。其实，这些痛点正是高可用架构必须解决的问题。

为电商程序设计高可用架构，需要从全链路多个层面考虑程序的水平伸缩能力、容错性、快速恢复能力还有数据安全性。电商程序内通常分为如下几层：

• 前端层使用CDN或边缘缓存提供高性能静态资源查询服务，减轻后端服务器压力。怎么说呢，静态资源无状态，可通过冗余提高性能和灾备恢复。
• 网关层业务请求第一道门户，提供负载均衡与请求转发。网关需无状态，并通过限流熔断隔离风险，以防雪崩效应。
• 服务层业务微服务多实例冗余部署。采用同步或异步解耦通信，高内聚低耦合，无状态化部署。
• 存储层唯一有状态组件，需要关注吞吐量、读写性能、单节点故障隔离、主从延迟和备份快速恢复。

二、电商业务数据特点分析

电商庞大业务场景产生多种类型的数据，包括使用者信息、商品信息、库存、订单、支付单、物流单等。这些数据按特征主要分为两类：

• 流水型数据: 订单/支付/物流等无依赖关系的数据流。在主要链路吞吐量最高，占绝大多数。
• 状态型数据: 使用者/商品/库存等需要最新数据支持读写操作，对一致性要求较高。

至于使用者痛点一，大量订单在高峰期提交时出现“下单超时”现象；使用者痛点二：库存更新延迟导致“售罄”页面显示错误；使用者痛点三：支付环节出现“余额不足”误报，引发信任危机。

三、存储层高可用建设

3.1 流水型数据的高可用架构升级

从主要目标来看，实现业务无感知存储扩容与统一容灾。

当流量激增或数据库容量不足时如果无法及时写入新存储，将直接导致订单提交失败——这是最常见的“下单失败”痛点。

1. 统一流水单据号生成规则： 将数据库路由信息嵌入单据号。使每笔交易都携带目标库标识，避免集中写入造成瓶颈。
2. 基于单据号路由数据库： 按路由信息将新流水动态切到对应库。 实现弹性扩容与容灾切换，无需停机维护。不过，

运行期策略。实现自动扩容，上层服务无感知，网关与服务层均保持无状态。这样就能实现跨机房切流与弹性扩容的一体化。

3.2 状态型数据的高可用建设探讨

针对读多写少与强一致两类场景分别制定方案：

• 读多写少：  采用一写多读模式——数据库承载写请求。缓存承载大部分读取，通过实时同步保持一致；不过，缓存节点失效时回源到数据库；数据库主从切换保证持久化可靠性。
• 强一致需求：  使用分库分表+未决隔离。每笔事务同时走主库和备库，并按黑名单切流防止脏写；保证RPO/RTO满足金融级要求。

3.3 数据库多副本高可用保障

三副本机制部署在不同AZ，实现风险隔离与半同步复制。事务提交需至少同步到一从才算成功，即使主宕也能迅速从库接管并保证零丢失。

四、多机房场景下的高可用建设

京东采用北京和宿迁双活，多逻辑单元拆分至各机房。在跨机房切流期间，由于网络延迟可能导致：

• A) 禁止写操作等待同步完成 → 业务不可用 B) 立即切换 → 脏写导致数据不一致

实际表现为"支付成功但最终未到账"。或者"配送地址错误".

解决思路是利用流水数据无依赖特性，将新增流水直接路由至新的本地库，不必等待跨城同步完成，从而保证新增订单始终在线。而对已有存量更新，则接受秒级延迟，因为其比例远低于新增比例。可在后台异步完成同步而不会影响整体业务连续性。话说回来，

五、案例实践—提高真实业务痛点解决效果

5.1 外卖配送程序数据库升级

• - 原方案因单节点瓶颈导致配送确认延迟10~15秒 - 改造后通过流水号路由+灰度双写，在一个月内完成升级。实现无感知弹性扩容和容灾切换 - 结果：配送确认时间降至<5秒，峰值并发提升200%。

5.2 电商主要链路单据统一升级

• - 单据拆分规则混乱引发支付冲突 ‑ 改造后统一拆分维度及规则，实现全链路统一扩容与容灾 ‑ 成功降低支付冲突率30%。

5.3 电商支付程序异地多活建设

• - 金融属性对RPO/RTO要求极严苛 ‑ 新建同城&异地切流机制。在10秒内完成RPO控制 ‑ 支付成功率提高至99.999%，信用投诉下降40%。

六、与工程智慧体现

电商全链路高可用程序中，唯一承担状态的数据层决定了整个业务链条是否顺畅。通过把握以下几个关键技术要素，可以让工程智慧真正落地：

• 流水号智能化生成 & 路由控制： 让新增交易无需等待即可落盘。实现动态弹性
• 读多写少 & 强一致双轨并行： 缓存+数据库一键结合，对抗库存滞后 & 脏写问题;按理说，
• 三副本半同步 + 自动选主 / 健康检测： 确保即使主节点宕机。也能零丢失恢复，
• 跨机房新流水直投本地库策略： 彻底规避跨城延迟带来的停摆;