一、高可用架构范式
高可用架构的核心目标是保障系统在面对硬件故障、软件异常或网络中断等风险时，仍能持续对外提供服务，最大限度减少停机时间，确保业务连续性和数据一致性。为实现这一目标，系统通常会采用分层架构隔离风险、冗余设计保障数据灾备、故障转移机制实现应急恢复等。其设计范式已从传统的单点冗余演进为分布式环境下的全链路高可用体系。
为电商系统设计高可用架构，需要从全链路多个层面考虑系统的水平伸缩能力、容错性、快速恢复能力以及数据的安全性。电商系统内通常分为如下几层：
•前端层：通常使用内容分发网络（CDN）或者边缘缓存，提供高性能静态资源查询服务，减轻后端服务器压力。静态资源是无状态的，在高可用架构设计时，可考虑通过冗余提高性能和保障灾备恢复。
•网关层：业务请求的第一道门户，主要提供负载均衡和请求转发能力。网关层亦是无状态服务 ，需要考虑通过限流熔断隔离风险，防止雪崩效应。
•服务层：业务系统面向服务的架构，各业务服务多实例冗余部署，服务与服务之间采用同步或者异步的方式进行通讯和解耦，建设成高内聚、低耦合分布式微服务架构。服务层亦是无状态的。
•存储层：为各业务系统提供数据存储服务，包括关系数据存储、NoSQL存储和检索等，通常采用数据分片提升存储系统的吞吐量、主从数据冗余保障数据灾备恢复。整个业务链路中存储是唯一有状态的，其在架构设计时需考虑数据访问吞吐能力、读写性能、单节点故障的风险隔离、主从数据延迟和数据备份快速恢复等。
单节点的可用性，可通过冗余部署、负载均衡、服务降级等措施来保障，但大型电商系统通常是多数据中心架构，业务系统全链路多机房多活，高可用架构需考虑全业务链路在机房间切流期间，业务服务的连续性和数据的一致性等问题。此外，为了满足业务规模的快速增长，核心链路的系统容量的扩缩容机制，也是高可用架构设计需要重点考虑的方面。
业务连续性、数据一致性、弹性扩缩容等，是全链路高可用体系核心要解决的问题，而解决这些问题的核心点在于有状态的存储层，数据分片、主从同步、扩容机制等方面设计的优劣直接关系到上述核心问题的解决程度。电商系统的存储层的高可用架构设计需根据电商业务特点来有针对性的进行。
二、电商业务数据特点分析
在电商庞大业务场景下会产生各种类型的数据，比较常见的业务数据有：用户信息、商品信息、商品库存、订单、支付单、物流单、优惠卷、红包等。这些数据按特征主要分为如下两类：
•单据类数据（订单、支付单、物流单等），电商在线交易活动产生的一系列单据数据，这些数据前后之间无任何依赖关系，数据呈是流水式，被称为流水型数据。电商最核心链路、吞吐量最高的的系统均和在线交易相关，这些系统产生的几乎都是流水型数据，占电商数据的绝大多数。
•状态数据：除了单据业务外，用户信息、商品信息、库存等也是非常常见的电商数据，在线交易强依赖这些数据，以读为主，但少量写操作必须基于其最新数据来进行，否则可能出现脏写和丢数据。这类业务数据前后之间有依赖关系，被视为有状态型的数据。
| 业务特性 | 流水型数据 | 状态型数据 |
|---|---|---|
| 代表业务 | 订单、支付单、物流单等； | 用户信息、商品信息、商品库存、红包等； |
| 业务特点 | 业务请求会创建新的数据，前后数据之间无依赖关系，数据呈流水式； | 业务请求必须基于最新数据来执行更新，前后之间有依赖关系； |
| 数据增长 | 数据增长较快，业务请求会创建新的数据； | 数据增长慢，业务请求基于已有数据，较少创建新数据； |
| 业务请求特点 | 新增和更新请求的比例大于是10：1； | 用户、商品读多写少，库存对写比例相当； |
电商系统核心链路上吞吐量最大的业务系统，几乎均是单据类流水数据，电商系统高可用保障，首先要解决流水数据的高可用问题。而状态数据业务场景以多读写少为主，通过添加缓存、一写多读等机制，可保障状态数据的高可用。
三、存储层高可用建设
3.1、流水类数据的高可用架构升级
流水型业务的高可用建设最主要目标：业务无感知的存储扩容和全业务链路统一容灾 。 流水数据前后之间无依赖关系，在原存储容量不足或故障时，实时将新的流水数据写至新的存储中，这样无论是扩容场景还是容灾场景，均能得到解决。并且，若全核心链路均按上述相同的机制，路由新的单据数据至新的存储，便可以实现全链路统一扩容和容灾。
为达到上述目的，需业务系统完成如下架构升级：
1、统一流水单据号生成规则：每一笔单据数据均有一个唯一ID，即单据号。如下图"第一步"所示，改造流水数据单据号的生成规则，在流水数据的单据号中，拼接入数据库路由信息，该路由信息明确该笔单据所存储的目标库。
2、基于单据号路由数据库：如下图所示，基于业务单据号中的路由信息路由单据数据至目标库。
完成上述两项改造之后，在运行期通过动态调整单据号的生成测策略来生成新规则的单据号，进而动态将新流水路由至新的存储库，这样无论是扩容场景还是容灾场景，均能很灵活的解决流水业务系统的高可用问题，这些操作可以做到对业务无感知。
对整个核心业务链路来说，各系统统一单据号规则和运行期统一调整单据号生成策略，可实现全业务链路的存储层的统一切换。存储层做到统一切换，而上层服务层、网关层等又是无状态的，那么随着网络入口流量的切换，可实现全核心链路的弹性扩容、统一容灾和跨机房切流等，进而建设起流水类业务全链路的高可用性体系。
3.2、状态类数据的高可用建设探讨
电商的在线交易系统生产流水数据会强依赖一些状态数据，如用户信息、商品信息、商品库存、红包等，这些状态数据按业务场景特点，被分为读多写少和强一致读写两类：
•读多写少的状态数据，代表业务商品、库存、用户等，业务场景以读为主，且能接受少量读延迟。读多写少的业务采用一写多读架构，用数据库承接写请求，用缓存承接部分读请求，底层数据库和缓存间做数据实时同步。缓存节点故障可执行缓存集群的主从切换，必要时也可以将请求回源到数据库。数据库故障可执行数据库主从切换。
•强一致读写的状态数据，代表业务京豆、红包、优惠卷等，主要和资产业务相关，要求读写数据均强一致，采用分库分表+未决数据隔离。为来保证强一致读写需要用数据库承接读写请求，同时为主库设置容灾备库，主从切换时需要按黑名单切流避免出现脏写。
3.3、数据库多副本高可用保障
上述针对电商业务特点，分别对流水和状态业务进行了全业务链路高可用架构升级。对于单个存储节点，通常采用数据库多副本机制来保障其高可用性。
如下图所示，单存储节点采用三副本机制，即一主二从，三副本分别部署在三个可用区中以便风险隔离，副本间采用半同步机制进行数据复制。在运行期，一个数据库事务在主库上提交时，其日志至少被同步到一从库上，才算提交成功，这种机制能保障即使主库宕机，也能从其中一个从库上恢复数据，保证数据不丢失。数据库高可用组件负责对数据各副本节点进行多维度健康检测，当主库出现故障，其根据复制拓扑和选主算法，实现故障主库的秒级隔离与复制关系的重构，在短时间内快速恢复集群。
数据库多副本及复制机制保障业务数据不丢失，高可用组件的健康检测和秒级切换保障故障快速恢复，共同铸造了高可靠的数据库存储服务。
四、多机房场景下的高可用建设
京东数据中心架构是北京和宿迁多机房多活，如下图所示，京东以用户为维度拆分出多个逻辑单元，将逻辑单元分布到北京和宿迁不同机房中。在各机房内流量完全收敛以避免网络延迟，机房间按逻辑单元切流，随着机房间的切流，一个逻辑单元可能落在北京机房也可能落在宿迁机房。
在异地多活单元化架构下，为了保证业务系统对数据库的访问都在本机房内收敛，底层数据库需在北京和宿迁机房对等部署并且双向循环复制，又由于地理距离远的原因，数据同步会存在一定的网络延迟。若切流时禁写数据库，再等待数据数据同步完成，则跨机房切流期间业务不可用；若不等待数据同步完成就切换，则可能出现数据脏写造成数据丢失。
多机房场景下的高可用核心要解决的问题是： 在机房间数据有延迟的情况下，跨机房切流业务连续性和数据一致性，即跨机房切流业务不停、数据不丢。
前文已对电商业务特点进行了分析，电商核心链路上吞吐量最大的业务均是流水数据。流水型数据前后之间是没有依赖关系的，创建新的流水是不需等待存量数据同步完成的，存量数据的更新才需要等数据同步完成，前者和后者的占比例在10：1以上，也就是说，解决新增流水的高可用问题，便可解决跨机房切换时的绝大部分高可用问题。
如下图所示，在发生跨机房切换时，将新增流水数据路由至一个全新的数据库中（如下图 "宿迁异地库01"），此库无需等到跨城同步延迟，跨城切换时完全可用，新增数据场景业务连续性百分百。对于存量数据，在跨城切换时任需等待跨城同步延迟，但是存量数据的更新在整个业务活动的占比是较少（不到十分之一），且正常延迟是秒级，对跨城切换时业务连续的影响不明显。
通过跨城切换时将新流水路由至新的数据，可有效规避数据库跨城同步延迟对业务连续性的影响，保障跨城切换期间绝大部分业务请求的连续性和数据一致性。
五、业务高可用架构升级案例
5.1、外卖配送系统数据库架构升级
2025年京东发力外卖业务，但原外卖配送系统由于业务规模小在存储上存在单点瓶颈，在外卖业务井喷式发展的背景下，其存储瓶颈严重制约了业务的发展，亟需对外卖配送系统进行架构升级。外卖数据是流水数据，通过改造单据号和基于单据号路由，以及双写和灰度切换，总计用时一个月时间完成了架构升级改造工作，将外卖配送系存储从单点架构升级至分布式存储架构，且后期还能业务无感知弹性扩容和容灾切换，满足了外卖业务当前和未来的吞吐量和稳定性需求。
5.2、电商核心链路单据数据统一架构升级
2025年京东电商核心链路的单据数据完成架构升级，通过升级单据号生成规则和基于单据号路由，统一了电商核心链路单据数据的拆分维度和拆分规则，实现电商核心链路单据弹性扩容和统一容灾。
5.3、电商支付系统异地多活建设
京东电商支付系统有金融属性，对高可用和数据一致性有比较高的要求。在京东的异地多活单元化架构下，为了支持统一支付系统北京宿迁多活部署和跨城切流的业务不停、数据不丢失的诉求，2025年用时一个月余，完成了流水数据同城和跨城切流机制的建设，为支付系统建设起同城和异地多活切高可用容灾部署架构。在同城和异地容灾下，RPO=0，RPO<10s，且基于新流水路由至全新库的机制，保障业务不停，数据不丢。
六、总结
在电商系统全链路高可用架构中，存储层作为唯一承载业务状态的核心模块，其架构设计直接决定了全系统的业务连续性、数据可靠性和扩展性。不同于无状态的网络接入层和应用服务层，存储层需要在服务可用性、数据强一致性与跨地域网络延迟三者间寻求最优平衡。
本文对电商核心链路业务场景进行了深度剖析，流水型业务在电商核心链路中占绝大多数，通过流水业务单据号生成规则改造和基于单据号来路由数据库，可实现流水业务的对业务无感知的动态扩容和容灾恢复。甚至在多机房单元化场景下，基于上述机制也能巧妙规避跨机房主从同步延迟问题，保障多数据中心下跨机房切流期间业务的连续性和数据一致性。外加状态型业务的高可用架构升级和数据库多副本的高可用保障机制，京东电商已建设起高扩展性、高可用性的分布式异地多活系统架构。