2013 年 5 月,支付宝最后一台小型机下线,去 “IOE” 取得里程碑进展。支付宝(以及后来的蚂蚁金服)走的是一条跟传统金融行业不同的分布式架构之路。要基于普通硬件资源实现金融级的性能和可靠性,有不少难题要解决。应用层是无状态的,借助 SOA 架构还可以比较方便地扩展。而数据层就没那么简单了,蚂蚁金服在探索的过程中,积累了一些有用的数据层架构设计经验,还是非常模式化的,可以分享出来供参考。
传统银行使用的高端硬件资源和商业数据库,单机的性能和稳定性肯定占有绝对的优势。互联网分布式架构,则需要从架构设计上做文章,提高系统整体的并发处理能力和容灾能力,其中容灾能力又主要有两个指标:
RTO,Recovery Time Objective,恢复时间目标。表示能容忍的从故障发生到系统恢复正常运转的时间,这个时间越短,容灾要求越高。
RPO,Recovery Point Objective,数据恢复点目标。表示能容忍故障造成过去多长时间的数据丢失,RPO 为 0 表示不允许数据丢失。
分布式领域 CAP 理论告诉我们,一致性、可用性、分区容忍性三者无法同时满足。我们不要奢望寻找能解决所有问题的万能方案,而应该根据不同的场景作出取舍。虽然业务场景五花八门,但是根据实际经验,往往可以归到有限的几种模式中,处理策略也是相对固定的。
我们抽象一个简化的支付系统模型来帮助理解,为了叙述方便,不一定跟支付宝的实际业务情况完全一致。它采用 SOA 架构,主要划分了交易、账务、用户、运营支撑这几个子系统,各自有各自的数据库。另外还有一个全局的配置库,存放一些会被各处用到的配置数据。
这几个子系统涵盖了几种常见的模式,先简要介绍它们的主要业务:
账务:金融/支付系统中最核心的业务,简化后姑且认为只保存每个账户的余额,主要操作是增减余额。它的特点是要求数据强一致,每一次对余额的增减必须基于一个绝对正确的当前值,否则就会造成资损。
交易:负责记录每笔交易的状态和上下文。在电商系统中,它可能是商品订单;在银行系统中可能是转账流水。交易类的数据有生命周期,可能有创建、付款、发货、确认收货、退款等状态变迁。这些都不重要,重要的是它的业务特点:每一笔交易的创建是独立的,不需要依赖其他交易的数据;推进一笔交易状态的时候,要求这条数据是强一致的,但跟其他交易数据无关。
用户:维护用户的用户名、密码、邮箱、手机等非账务信息,提供注册、登录、查询业务。在执行核心业务的时候,有多处需要读用户的基本信息,关键业务链路对其有读强依赖。
运营支撑:供内部工作人员用的后台系统,包括但不限于工作流、客服等功能。
配置数据:这里是个宽泛的说法,笼统地表示各类变更不频繁,但是在主业务流程中需要频繁读取的数据,例如交易类目、机构代码、汇率。它们实际可能是散在各个业务系统中的,为了方便描述,单独用一个配置数据库来表示。
把数据库按业务模块进行拆分,是典型的垂直扩展思路,突破了单库的能力限制,使得系统可以支撑更多的业务量。当然这也引入了分布式事务的问题,另有专题介绍暂且不表。拆分开后,就方便不同的业务采取不同的架构设计了。
账务系统
与垂直拆分对应的,自然就是水平拆分。分库分表已经是一种非常成熟的数据水平拆分方法。例如可以将账号对 10 取模,将数据分散到 10 个逻辑分表中。这 10 个分表又映射到 10 个物理数据库。分库分表中间件可以屏蔽掉底层部署结构和路由逻辑,应用层仍然像使用普通单库一样写 SQL。
拆分开后,“有数据库出故障”的概率其实是大大增加的。假设其中一个账务库故障了,就意味着有至少 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 容灾方案。
本文只讨论了节点级的水平扩展以及容灾能力,没有提及访问距离带来的延时问题。金融系统往往要求机房级甚至城市级的扩展能力和容灾能力,蚂蚁金服就运行在异地多活架构上。这时候数据访问延时就无法忽略了,会冒出很多原本不是问题的问题,架构设计将更加复杂。对数据类型的分类,其实是一个重要的基础,不同类型的数据在异地架构下也有相应的处理模式