为适应业务高速发展及对高可用的要求，金融业务逐渐从集中式架构改造成分布式架构。在这个过程中，底层数据库存储也从原先的单节点数据库变成扩展性更强的分布式数据库。相对于分布式系统中的其他组件，分布式数据库为系统带来最大的收益，同时也对业务系统改造提出要求，主要包含如下几个方面：
1、业务系统组件化、服务化改造。对业务系统进行分层解耦，确定应用层、服务层及数据层的边界，以适应系统弹性扩展的需求。对承上启下的服务层进行服务化改造，提供“去中心化”的服务调用，并以“弹性”扩展计算能力为主要衡量指标。
2、数据库模式设计，满足扩展需求。在数据库模式设计的过程中，主要关注如下几个方面：
- 扩展性需求 随着业务的快速发展，数据量会急剧增大，在模式设计的时候要充分考虑，通常要对数据进行分区，比如按照时间做Range分区、按照记录的某个特征值做Hash分区。保持每个分区的大小适中，对系统的负载均衡、调度以及扩展性都有帮助。
- 性能需求 分布式数据库系统的节点数通常从几个到数百个不等，对数据的访问需要路由。在进行数据库模式设计的时候，需要结合数据常用的访问模式，来确定分区键，以便根据SQL语句就可以准确地路由，减少二次转发带来的性能损失。同时，尽管大多数的分布式数据库系统都支持分布式事务，但相对于单机事务，性能有一定的损耗，所以在模式设计的时候，也需要考虑表数据的亲和性，把可能会被一起访问的数据放在同一个节点上，减少分布式事务的比例，对系统的性能和扩展性都有好处。此外，由于多维度访问数据的需求，有可能需要创建全局索引，相对于单机数据库系统而言，在分布式数据库中维护全局索引会产生分布式事务，对性能也有较大影响，所以要平衡全局索引带来的查询性能提升和维护成本增大。
- 全局一致性快照 有的分布式事务数据库系统只实现了单个节点上的一致性快照，而没有实现全局的一致性快照，在一条语句中访问位于不同节点上的数据时，这些数据可能不属于同一个快照点。这种行为的一个后果是无法保证不同连接上操作的因果序，会给业务带来一定的困扰。为避免这种情况，在模式设计的时候告诉数据库系统相关联数据的亲和性，以便数据库系统在调度的时候将这些数据聚合起来。
3、关系数据库能力评估及业务开发注意事项 目前分布式事务数据库系统并未形成统一标准，产品之间SQL能力差异性比较大，而传统金融业务开发多基于DB2、Oracle等数据库系统，或多或少利用了这些数据库特性，这些特性在分布式事务数据库中有的是功能不支持，有的是性能上有损耗，需要在设计中加以考虑，并进行适当取舍。典型的特性如下：
- sequence支持 有些业务使用数据库的sequence功能来产生记录的唯一键，是否支持该功能以及在分布式系统中获取sequence的性能对系统有较大的影响。
- 强一致性事务及事务隔离级别支持 对于金融核心业务，必须有强一致性的事务支持，弱一致性或者最终一致性会给业务开发带来额外的工作量和巨大的风险。分布式关系数据库通常都支持read committed隔离级别，如果有其他隔离级别的需求，需要在系统设计过程中结合数据库能力加以考虑。
- 复杂查询支持 相对于单节点数据，分布式数据库优化器生成最优计划面临更大挑战。对包含多表联接以及复杂子查询的语句，能否确定合适的联接顺序，将联接和计算更多的下降到每一个节点，减少节点间的数据传输，不仅仅是功能性问题，也是性能问题。
- 存储过程支持 传统单节点数据库对存储过程都有良好的支持，对性能要求高的业务系统也往往采用存储过程处理关键业务流程。在采用分布式数据库的时候，需要考察该方面的能力。
4、系统容量评估及弹性方案
分布式事务数据库的一个重要特性是扩展性好，可以方便地对系统容量进行弹性伸缩。在系统设计的时候，要对系统容量进行评估，以便确定数据库系统的硬件资源需求。在容量评估过程中，除从系统总的TPS/QPS角度去估算以外，还要关注热点账户等关键特征，以便在资源和负载均衡等方面有一个更全面的考虑。
在完成对日常场景的容量评估后，还需要对诸如“双十一大促”、“春节红包”、“秒杀”等特定事件触发的流量峰值规划弹性方案，上述场景大多是有计划的，可以提前进行容量规划和根据预估峰值流量进行扩容；当该特定事件结束后，系统要相应地进行缩容以便释放多余资源。扩容和缩容都应该是在线的，不影响正常的，需要根据业务特点（流水型或者状态型），结合分布式数据库的弹性能力，进行弹性方案的设计。
5. 高可用及容灾方案
和传统商业数据库系统依赖硬件设备高可用来达到系统高可用不同，分布式事务数据库运行在普通的硬件设备上，硬件故障和损坏是一个大概率事件。数据库系统的高可用依靠分布式数据库软件来实现。目前主流的高可用方案是多副本强一致方案，同一个数据的多个副本存放在不同的数据库节点上，这些数据库节点有可能存放在同一个机房中，也可能存放在同一个城市的不同机房中，甚至是不同城市的机房中，多个副本之间通过回放日志进行数据同步，事务对数据的修改必须在大多数的副本上生效才算成功。
系统设计过程中，要根据系统对高可用的要求选择相应的方案：
- 单机房多副本，副本存放在不同节点中。该方案可以应对单节点故障，事务提交操作没有跨机房日志同步操作，对事务响应时间影响最小。在单节点故障情况下，数据不丢失，原故障节点对外提供的服务有几十秒的影响。
- 同城三机房，每个机房一个数据副本。该方案可以应对单机房故障，事务提交操作需要在同城机房间进行日志同步，对事务响应时间有较小影响。
- 两地三机房，可以使用3个副本或者5个副本。该方案在应对单机房故障的基础上，如果存放单机房的城市发生故障，数据也不会丢失；事务提交操作大概率在同城机房间进行日志同步，对事务响应时间有较小影响；但一旦同城的两个机房中一个机房发生故障，事务提交就需要跨城日志同步，对事务响应时间有较大影响。
- 三地三机房，多使用5个副本。可以应对城市级故障。事务提交操作需要跨城进行日志同步，对事务响应时间有较大影响。
在考虑数据库系统的部署方案时，也要一并考虑业务系统的部署方案，比如对于可用性要求特别高的系统，分布式数据库系统采用三地三机房的方案，业务系统也需要相应部署在三个机房里，避免跨城数据库访问造成的性能损失；同时每一次事务提交需要跨城事务日志同步，对响应时间有一定的影响。
6. 系统运维方案
相对于集中式系统，分布式系统的运维复杂度更高，需要尽可能自动化和在线操作。两个常见的运维过程：系统升级和系统备份，都需要在线实施，不能影响业务的正常运行。为达到这个目的，业务系统和分布式数据库系统都需要支持在线升级。对集群数据库节点分批升级，在升级之前，利用多副本特点，将一部分节点的流量切换到位于其他节点的副本上，在升级完成后再切换回来；业务系统的在线升级过程也类似。
此外，对于分布式系统，问题跟踪也更加复杂。在业务系统设计过程中，需要单独考虑问题跟踪能力，比如为每一笔业务，生成一个单独的交易号，通过交易号串联整个业务流程，并持久化在数据库中，方便异常情况下的问题分析和解决。
在将金融核心系统从集中式架构升级到分布式架构的过程中，OceanBase数据库和上层的金融分布式架构一起做了大量的工作，形成了一系列的最佳实践。
————————————————————————————————————————————
社区版官网论坛
社区版项目网站提 Issue
欢迎持续关注 OceanBase 技术社区，我们将不断输出技术干货内容，与千万技术人共同成长！！！
搜索🔍钉钉群，或扫描下方二维码，还可进入 OceanBase 技术答疑群，有任何技术问题在里面都能找到答案哦～
