交易、账务系统去 Oracle 经验

2013 年 5 月，支付宝最后一台小型机下线，去 “IOE” 取得里程碑进展。支付宝（以及后来的蚂蚁金服）走的是一条跟传统金融行业不同的分布式架构之路。要基于普通硬件资源实现金融级的性能和可靠性，有不少难题要解决。应用层是无状态的，借助 SOA 架构还可以比较方便地扩展。而数据层就没那么简单了，蚂蚁金服在探索的过程中，积累了一些有用的数据层架构设计经验，还是非常模式化的，可以分享出来供参考。

 

传统银行使用的高端硬件资源和商业数据库，单机的性能和稳定性肯定占有的优势。互联网分布式架构，则需要从架构设计上做文章，提高系统整体的并发处理能力和容灾能力，其中容灾能力又主要有两个指标：

 

RTO，Recovery Time Objective，恢复时间目标。表示能容忍的从故障发生到系统恢复正常运转的时间，这个时间越短，容灾要求越高。

RPO，Recovery Point Objective，数据恢复点目标。表示能容忍故障造成过去多长时间的数据丢失，RPO 为 0 表示不允许数据丢失。

 

分布式领域 CAP 理论告诉我们，一致性、可用性、分区容忍性三者无法同时满足。我们不要奢望寻找能解决所有问题的万能方案，而应该根据不同的场景作出取舍。虽然业务场景五花八门，但是根据实际经验，往往可以归到有限的几种模式中，处理策略也是相对固定的。

 

我们抽象一个简化的支付系统模型来帮助理解，为了叙述方便，不一定跟支付宝的实际业务情况完全一致。它采用 SOA 架构，主要划分了交易、账务、用户、运营支撑这几个子系统，各自有各自的数据库。另外还有一个全局的配置库，存放一些会被各处用到的配置数据。

 

 

这几个子系统涵盖了几种常见的模式，先简要介绍它们的主要业务：

账务：金融/支付系统中最核心的业务，简化后姑且认为只保存每个账户的余额，主要操作是增减余额。它的特点是要求数据强一致，每一次对余额的增减必须基于一个正确的当前值，否则就会造成资损。

 

交易：负责记录每笔交易的状态和上下文。在电商系统中，它可能是商品订单；在银行系统中可能是转账流水。交易类的数据有生命周期，可能有创建、付款、发货、确认收货、退款等状态变迁。这些都不重要，重要的是它的业务特点：每一笔交易的创建是独立的，不需要依赖其他交易的数据；推进一笔交易状态的时候，要求这条数据是强一致的，但跟其他交易数据无关。

 

用户：维护用户的用户名、密码、邮箱、手机等非账务信息，提供注册、登录、查询业务。在执行核心业务的时候，有多处需要读用户的基本信息，关键业务链路对其有读强依赖。

 

运营支撑：供内部工作人员用的后台系统，包括但不限于工作流、客服等功能。

 

配置数据：这里是个宽泛的说法，笼统地表示各类变更不频繁，但是在主业务流程中需要频繁读取的数据，例如交易类目、机构代码、汇率。它们实际可能是散在各个业务系统中的，为了方便描述，单独用一个配置数据库来表示。

 

把数据库按业务模块进行拆分，是典型的垂直扩展思路，突破了单库的能力限制，使得系统可以支撑更多的业务量。当然这也引入了分布式事务的问题，另有专题介绍暂且不表。拆分开后，就方便不同的业务采取不同的架构设计了。

 

账务系统

与垂直拆分对应的，自然就是水平拆分。分库分表已经是一种非常成熟的数据水平拆分方法。例如可以将账号对 10 取模，将数据分散到 10 个逻辑分表中。这 10 个分表又映射到 10 个物理数据库。分库分表中间件可以屏蔽掉底层部署结构和路由逻辑，应用层仍然像使用普通单库一样写 。

 

 

拆分开后，“有数据库出故障”的概率其实是大大增加的。假设其中一个账务库故障了，就意味着有至少 10% 的核心业务受影响了，实际还不止，因为一笔交易涉及双方账号。这种情况怎么办，立即切换到备库？不行的，前面说过账务要求数据强一致，即 RPO=0。数据库的主备复制一般有延时，不能保证数据无丢失。即使用 Oracle+ 共享存储的方式保证不丢数据，回放 Redo Log、检查数据一致性、切换备库，通常要花费数十分钟，足够用户在社交网络炸锅的了。怎么办？早期其实没什么好办法，情愿牺牲一些 RTO，也要保证 RPO。当然可以做一些体验上的优化，例如界面展示余额时，可以使用只读备库，减少用户恐慌，但不允许基于此余额做实际业务，聊胜于无吧。

 

后来逐渐探索出了一套账务容灾方案，需要业务层参与，还挺复杂的。这个话题足够单独成文，本文先不详细介绍，只说一下基本思路：主备库数据不一致无法避免，但可以想办法锁定有哪些账号的数据是最近刚刚在主库有过变更的，我们没法确定这个变更是否已经同步到备库了，就把这些账户全部加入黑名单，数据库恢复前不允许他们再做业务，避免发生资损。可以采取一些手段，让黑名单范围尽量小，并且确保黑名单以外的账户一定是主备库一致的，实践中可以缩小到几十几百个账户。这样，不可用范围就从库粒度一下子降到账号粒度，不在黑名单中的账户，就可以基于备库余额正常开展业务。

 

这套基于黑名单的容灾方案一直运行了好几年，效果还不错，缺点就是比较复杂，这是账务类业务本身的特点决定的。直到自研数据库 OceanBase 的诞生，情况有了改观。OceanBase 是基于 Paxos 协议的分布式强一致数据库，对于单节点故障，它提供 RPO=0，RTO<30 秒的容灾能力，致力于从数据库层屏蔽容灾细节，为应用层提供简单的使用方式。

 

交易系统

交易数据也是非常适合水平拆分的，可以将交易单据号取模，做分库分表。除此之外，根据交易类业务的特点，还有更有意思的玩法。除了正常的交易主库之外，另外再准备一组表结构完全相同的空库，称为 Failover 库（注意不是备库，跟主库没有数据同步关系）。交易系统在创建一笔交易的时候，首先要生成交易单据号，其中有一位叫做弹性位，正常情况下它的值是 1，代表这笔数据应该写入主库。后续根据交易单据号读写该条数据的时候，一看弹性位是 1，就知道到主库找这条数据。

 

 

假设 3 号主库突然故障了，这时就需要自动或手动给交易系统推送一个指令，告诉它以后第 3 分片的新数据应该插入 Failover 库。以后生成的第 3 分片的交易单据号，弹性位就是 2，代表 Failover 库，后续读写这条数据，也可以根据这一位自动找到 Failover 库。这时候主库的存量数据是无法修改的，已创建未付款的交易，用户可以放弃，重新创建一笔，就会落到 Failover 库正常处理。已经付款的交易，就暂时不能做发货、确认收货等状态推进了，但这不是关键业务，迟一点做也问题不大。当主备库数据一致性检查通过，主备切换完成，落在主库的老数据又可以继续处理了。这时再推送指令给交易系统：3 号库恢复正常状态，以后新数据落主库。Failover 机制让主业务（创建交易、付款）在很短的时间内恢复可用，放弃非关键业务（存量数据的状态推进），为主备切换争取了时间。分库分表、Failover 的逻辑，都可以由数据访问层封装，业务层并不用感知。

 

这期间在 Failover 3 号库创建的、弹性位为 2 的数据怎么处理？答案是不用特殊处理，根据弹性位 2，以后仍然可以在 Failover 库访问到这条数据，经过一段时间后，主库、弹性库的数据最终都会迁移到历史库去。Failover 库主要用于临时接管主库的新增数据，只要保持表结构一致即可，容量可以低于主库。当然弹性位也可以启用 3、4、5 更多编号，来灵活切换更多存储，这也是“弹性”的含义所在。

 

配置数据

配置数据很好理解，读多写少，读可靠性要求高，非常适合采用读写分离方案。根据具体业务，可以采用读从库、分布式缓存、内存缓存等方式。

 

用户系统

用户数据跟账务数据有紧密的对应关系，直观地想，也应该跟账务数据采用同样的处理策略，甚至合并到账务库中。这的确也是可行的，但在实践中，我们根据它的业务特性，采取的却是跟配置数据类似的处理策略，没有做水平拆分，而是做全量复制、读写分离。理由有如下这些：

 

用户数据更新较少，写操作不在关键路径，读操作在关键路径，跟配置数据的特性非常相似

对数据一致性要求没那么高，可以接受少量延迟同步，没有必要用账务数据那么强的一致性保障，账户余额不可信时，希望至少不影响登录

不全是按账号较精确查找，可能有邮箱、手机号等维度的查询，按账号水平拆分后，难以路由

 

所以用户系统实际采用的方案是：一个写库，全量异步复制到多个读库，再加上分布式缓存。如果写库故障，则不能注册新用户、更新个人信息；个别读库故障，不影响业务。

 

运营支撑系统

这里用运营支撑系统举例子，实际上是想代表这么一类业务数据：读写比差不多，业务流程依赖写操作，也不适合做水平拆分。这种称之为全局状态型数据。全局状态型数据一般是辅助型的非关键业务，一旦数据库故障，“要么等，要么忍”——牺牲 RTO 等待数据库主备切换，或者牺牲 RPO 立即强切备库。在做架构设计时，需要尽量避免关键业务强依赖全局状态型数据。如果真的有关键业务是全局状态型的，只能依靠 OceanBase 这样的多副本强一致数据库产品了。

 

归纳一下，业务数据主要可以归为三大类：

状态型：读写比相当，必须保证可写才有意义，每一次写操作必须基于前一个正确的状态。这是最棘手的一种数据，难以完美兼顾 PTO 和 RPO 。关键业务的状态型数据，应尽量想办法把维度拆细，一是提高并发处理能力，二是方便隔离故障影响。

 

流水型：不断产生新的数据，各条数据间是独立的，可以随时切换新数据的存储位置，每条数据的主键自包含存储位置信息。单条数据的更新需要保证强一致性。流水型数据很方便做水平扩展。

 

配置型：读写比大，强依赖读，弱依赖写，不要求严格的读一致性。可以采用读写分离、一写多读的方式保证读操作的性能和高可靠。

 

在做架构设计的时候，如果能准确地识别出业务数据的“模式”，可以帮助更合理地划分业务模块，更方便套用特定模式的性能扩展和可靠性保障策略，乃至将公共逻辑抽象成通用组件。一个没有经过数据类型拆分的系统，可以先当成最坏的情况：全是全局状态型数据。然后识别出其中的流水型数据、配置型数据，逐渐分离出去，状态型数据尽量做水平拆分。最后肯定还是会存在无法规避的全局状态型数据，则要想办法尽量降低它的重要性，避免关键链路对它的强依赖。

 

金融/支付系统中，最重要的往往就是类似账务的这种状态型数据，是必须要面对的难题。蚂蚁金服的经验是将所有“类账务”的业务（例如余额、余额宝、花呗）做抽象化、平台化，封装黑名单容灾等固定的业务逻辑，减少重复开发。当然，OceanBase 数据库上线后，把复杂度封装在数据库层内部，在性能和容灾能力（RTO/RPO）上达到了业务期望的平衡，对业务开发是一个不小的福音。目前支付宝的核心系统已经 100% 运行在 OceanBase 数据库上。

 

本文介绍的几种数据模式，基本可以覆盖常见的业务，可以作为架构设计的参考。但也不必过于拘泥，业务本身是复杂多样的，不一定是单纯的某种模式。举两个例子：

 

我们日常在支付宝界面上看到的消费记录，并不是直接查询交易系统，而是从一个专门的消费记录系统查询的。交易系统会通过异步消息把数据复制到消费记录系统。双 11 高峰期消费记录展示可能会有少许延迟，就是这个道理。交易是典型的流水型业务，但交易系统和消费记录系统组成的体系，用的却是读写分离思想。

 

账务系统的余额是状态型数据，但每个账户的变更明细，却是流水型数据，可以适用流水型 Failover 容灾方案。

 

本文只讨论了节点级的水平扩展以及容灾能力，没有提及访问距离带来的延时问题。金融系统往往要求机房级甚至城市级的扩展能力和容灾能力，蚂蚁金服就运行在异地多活架构上。这时候数据访问延时就无法忽略了，会冒出很多原本不是问题的问题，架构设计将更加复杂。对数据类型的分类，其实是一个重要的基础，不同类型的数据在异地架构下也有相应的处理模式，后续异地多活的系列文章还会深入讨论。