银行业核心系统分布式数据库改造问题求解？

这些产品和活动给传统的集中式关系型数据库带来极大挑战，硬件扩容、分库分表的传统应对手段效果不尽人意，无法适应营销期间海量数据存取及高并发请求响应的场景。为此，各大银行纷纷开始了核心系统分布式数据库改造的前期探索，部分银行已宣称完成核心系统分布式数据库的切换上线（张家港农商行，中信信用卡核心），但是整体效果和改造、使用过程中的问题未见详细描述且有待时间验证。
因此，想请教各位IT同仁，中型商业银行在准备核心分布式数据库选型时，除了必须要考虑的强一致性、高可用性的原则，还应考虑哪些问题？在CAP定律的限制下如何取得最优解？整个改造大致需要历经几个阶段？

从上述的描述内容可以提炼出来核心话题

（1）集中式数据库在互联网+业务场景下，遇到海量数据存取及高并发请求响应的场景挑战

（2）分布式事务数据库关注哪些关键点

（3）CAP 定律的限制下如何取得最优解

（4）业务系统从集中式数据库 改造为分布式事务数据库 会遇到那些问题，及经历那几个阶段

详细解答如下：

（1）集中式数据库在互联网+业务场景下，遇到海量数据存取及高并发请求响应的场景挑战

解答：

分布式事务数据库设计初衷就是要解决业务系统的 数据存储容量 和数据服务处理的两个维度能力做到水平弹性伸缩，并且不丢失集中式数据库带给业务系统访问数据库的操作体验。

从吞吐量的角度基本上要求达到： 常规数据（每行 1KB 字节）入库的 TPS 可达 1000000 及以上、数据访问的 QPS 可达 1000000 及以上，并发连接数可达 100000 及以上，集群线性扩容系数 0.8 及以上，集群数据容量可达到 TB 级至 PB 级

（2）分布式事务数据库关注哪些关键点

解答：

关注分布式事务是否实时一致、分布式事务吞吐量及响应时间、分布式事务对应业务系统的透明度、实时死锁检测和死锁接触、跨数据分片JOIN、跨数据分片的排序合并集合计算等、数据分片设计是依靠人力还是智能算法（默认主键或隐含健，也即非业务健）、排错分析运维管理能力。

（3）CAP 定律的限制下如何取得最优解
解答：

分布式事务数据库产品必须支持水平数据分片能力；在金融行业必须追求数据一致、数据完整、数据正确、数据持久化的大原则；最后考虑可用性，也即满足CP的前提下保证A

（4）业务系统从集中式数据库 改造为分布式事务数据库 会遇到那些问题，及经历那几个阶段

解答：

业务系统 从集中式数据库 改造为分布式事务数据库 必须要做项POC测试：挑选经典业务场景做功能测试和性能测试以初步判断是否满足要求、做每个组件的高可用测试和集群灾难测试、做业务系统集成的功能测试和性能测试、做业务系统集成的灾难测试。

业务系统 从集中式数据库 改造为分布式事务数据库 ：一定会碰到数据分片设计，也即每张表是按水平分片、垂直分片、全局分片中的哪一种，其次是 每张表数据分片的健选择哪个字段。要是依赖人工收集数据和分析设计，则很难保障业务系统的性能最佳 和 耗费大量人力（小项目估计技术专家 3人天-5人天；中等项目估计技术专家10人天-20人天，中大型项目估计技术专家：30人天-50人天，大型项目估计技术专家 100人天且前后周期长，总体建议：成本转嫁给分布式事务数据库产品厂商免费完成）

从外部了解的信息是目前只有OceanBase和HotDB实现了智能数据分片，自动会根据数据分布、数据访问等信息，结合AI智能算法计算出来数据分片的类型和业务字段是最佳。