银行核心系统如何选型分布式数据库.pdf

《银行核心系统如何选型分布式数据库.pdf》由会员分享，可在线阅读，更多相关《银行核心系统如何选型分布式数据库.pdf（13页珍藏版）》请在三个皮匠报告上搜索。

1、银行核心系统如何选型分布式数据库洪烨CONTENT目 录p 银行核心系统需要一个什么样的数据库 一致性 高可用 性能&扩展性 生态&迁移&维护 总结能够保证任何情况下的事务强一致性，严格保证账务一致性，不能返回中间态结果一致性满足7*24运行要求，数据不能丢失，支持多机房多中心部署高可用联机交易TPS、联机响应时间ART、批量整体时长高性能计划内并发扩展（计算、存储能力），在线扩缩容（例如硬件寿命到期自然淘汰更换）可扩展异构数据库的数据同步，SQL生态与周边产品兼容生态丰富具备可视化管理能力（切换、监控、告警等），以及具备能够管理整个集群的能力易维护银行核心需要一个什么样的数据库银行核心系统主

2、要功能是处理账务信息，因此对数据的一致性、性能和系统的服务响应能力都有严格的要求，对数据库的要求也最为严格：l 账务不能错，数据不能丢l 系统不能停，应用可逃生l 联机不能慢，批量不能晚l 数据易迁移，整体易运维分布式数据库中，对于事务一致性的难点通常在锁隔离性、死锁的探测处理死锁的探测处理以及二阶段二阶段提交过程中提交过程中协调节点异常情况下的处理机制。通常可以采用以下三种方式结合来验证分布式数据库的事务一致性演示或简单操作演示或简单操作：验证各个隔离级别下增删改查，死锁，锁等待的处理机制正常情况下一致性验证：正常情况下一致性验证：高并发场景下，通过对热点账户的增删改查，汇总流水明细与账户余

3、额进行比对，验证高并发下的隔离性及死锁检测异常情况下一致性验证：异常情况下一致性验证：高并发场景下，对协调节点进行宕机等故障场景的模拟，汇总流水明细与账户余额进行比对，验证数据库能否保障事务一致性一致性验证APP高可用主要是验证各个场景下的RTO与RPO，从场景上，可以粗略分为机房间故障与机房内故障 多中心切换：n 整体故障（中心整体切换）n 中心间网络故障（网络抖动、网络中断、网络阻塞等）中心内切换：n 计算资源故障（服务器异常）n 存储资源故障（磁盘异常）n 网络资源故障（网络抖动、网络中断、网络阻塞等）n 软件故障1.NTP时间异常2.进程异常（进程崩溃、进程挂起等）3.文件异常（权限、

4、误删除、文件系统满等）高可用验证扩展性验证此外，需额外关注数据库是否具备在线缩容在线缩容能力，可以采取整体先缩再扩的方式，可以能力，可以采取整体先缩再扩的方式，可以更好的验证扩缩容能力。更好的验证扩缩容能力。线性扩缩容能力：随着节点增加或减少，TPS是否能够与响应时间的变化，是否具备在线扩缩容的能力节点扩展与性能的线性关系半数资源情况下，性能是否为全部资源性能的一半ProxyProxy指标类别指标名称指标值联机性能联机交易处理能力TPSTPS限制联机交易平均响应时间ART响应时间限制联机交易成功率99.5%CPU使用率=80%内存使用率=85%批量性能批量执行时长同硬件Oracle为基准IO使

5、用率90%稳定性压力持续时间12hTPS波动率10%压力点TPS限制高可用性同城RTO60s同城RPO0是否保证一致性是扩展性压力点TPS限制性能受到影响的时间60s主要关注指标数据库的选择不仅仅是数据库软件产品本身，也涉及周围开发工具、数据同步工具、监控、备份等一系列生态，目前主流的生态包含Oracle生态 Oracle生态主要是由于原有系统大部分部署在Oracle上，但是在迁移过程中，也需注意与原有生态的过渡，数据迁移过程中通常可依靠一些迁移工具，但应用迁移的过程中，分布式数据库的兼容性会带来SQL改造的工作量。开源生态（MySQL&PG）目前大部分联机事务系统主要还是以MySQL生态为主

6、流，也有部分企业选择了PG生态，也基于此，目前市场上大部分产品都可以兼容MySQL或PG生态，对于各自生态的周边产品也都可以直接对接。此外，在验证过程中也可以适当的考虑产品与云结合部署的能力，虽然目前重要系统大多数还是独立部署，但随着基础层及平台层的快速云化，上云能力也需要进行考量。生态 兼容性验证 分类描述字符集GBK、UTF8等字段类型数字、浮点、字符、日期、大字段、JSON等表类型堆表、索引组织表、分区表（HASH、Range、List）、多级分区索引类型B+索引、哈希索引、函数索引等SQL语法HINT、递归