江苏龙网

  1. 主页 > 生活百科 > >

金融级分布式交易的技术路径( 二 )

分布式交易


【金融级分布式交易的技术路径】从 2008 年初上线至今，微交易架构已经应用到蚂蚁金服的各种金融业务场景，经历过历次大促高峰考验，证明这套架构与技术的可行性 。
2
请金融级分布式数据库: OceanBase
目前，主要商业数据库本质上是单机系统，其容量、性能和可靠性均依赖于单个或少量高性能服务器与高可靠存储的组合，成本高昂且扩展困难 。尽管通过运用微交易架构，可以将对数据操作的压力分拆多个数据库，解决了水平可扩展的问题，但数据库本身的性能、成本与可靠性依然是一个难点 。因此，阿里巴巴与蚂蚁金服从 2010 年起，开始研发专门的金融级分布式数据库 OceanBase 。
OceanBase 在以下几个方面，对传统数据库架构进行了突破：
高性能：数据库的一个显著特征是总数量比较大，但每天变化(增删改)的数据只是总数据量的很小一部分 。因此 OceanBase 将数据划分为基线数据和修改增量 。基线数据即数据库在某个时间点的一个快照，存放在每台 OceanBase 服务器的硬盘中，修改增量即快照点之后的增删改数据，相对比较小，通常存放在每台 OceanBase 服务器的内存中 。通过这种方式，使得增删改操作基本都在内存中进行，从而获得接近内存数据库的事务处理性能；
强一致：经典的主库+备库方式的数据库，很难兼具高可用与强一致能力 。为了解决这个问题，OceanBase 使用多数据副本（>=3）投票协议，对于每个写事务，OceanBase 只有在事务日志（redo log）到达超过半数服务器后，才应答客户 。这样当少数服务器（例如 3 台中的 1 台，或者 5 台中的 2 台）异常时，剩下的服务器至少有一台有事务日志，保证了数据库不因为少数服务器故障而导致数据丢失；
高可用：关键业务的数据库必须达到 99.999% 的可用性，服务器故障、机房或网络故障都不能导致数据库不可用 。OceanBase 通常由分布于多个机房（3 个或以上）的机群组成，每个机群有完整数据，其中一个机群作为主库对外提供读写服务，其余机群作为备库，接收主库的事务日志和回放日志 。当主库故障时，剩下的机群会立刻自动发起投票选举，选出新的主库，新主库从其他机群获得可能存在的最新事务日志并回放，完成后对外提供服务 。
目前 OceanBase 已经稳定支撑了支付宝的核心交易、支付与账务，支撑了网商银行的核心系统，经历了多次“双十一”的考验，形成了跨机房、跨区域部署的高可用架构，并在日常运行、应急演练和容灾切换中发挥了重要作用 。
3
异地多活与容灾: 单元化架构
“两地三中心”是一种在金融系统中广泛应用的跨数据中心扩展与跨地区容灾部署模式，但也存在一些问题：在扩展能力上，由于跨地区的备份中心不承载核心业务，不能解决核心业务跨地区扩展的问题；在成本上，灾备系统仅在容灾时使用，资源利用率低，成本较高；在容灾能力上，由于灾备系统冷备等待，容灾时可用性低，切换风险较大 。
因此，蚂蚁金服没有选择“两地三中心”部署模式，而是实现了异地多活与容灾模式 。异地多活与容灾架构的基础是对系统进行单元化 。每一个单元可以认为是一个缩小规模的、包含从接入网关、应用服务到数据存储的全功能系统 。每个单元负责一定比例的数据与用户访问 。单元有以下关键特性：
自包含性：比如用户的一次账户充值交易，涉及到的所有计算与数据都在一个单元内完成；
松耦合性：跨单元之间只能进行服务调用，不能直接访问数据库或其它存储 。对于一些必须跨单元的交易处理，比如分属于两个不同单元的用户之间的转账交易，跨单元的服务调用次数尽可能少，在业务与用户体验允许的情况下尽量异步处理 。这样，即使两个单元之间相距上千公里，也可以容忍跨单元的访问时延；
故障独立性：一个单元内的故障，不会传播到其它单元；
容灾性：单元之间相互备份，确保每个单元在同城和异地都有可在故障期间进行接管的单元 。数据在单元间的备份方式，我们以 OceanBase 提供的多地多中心强一致方案为主 。
通过单元化架构，能够将一个大规模系统分拆成许多个相对独立的小规模系统，每一个单元系统可以部署到任何地区的数据中心，从而实现了灵活的异地多数据中心部署模式 。系统的主要伸缩模式变成单元的增减，但一个单元内部的规模与复杂性不变，降低了系统的复杂性 。单元之间的故障隔离，降低了软硬件故障的影响面 。“活”的单元和跨单元的快速切换能力，使同城异地的容灾处理更为简单高效 。


推荐阅读


上一篇：现代Web开发中的JavaScript音频库——howler.js

下一篇：加密钱包漏洞利用与分析