金融企业区域集中库的设计构想和测试验证

导读

本文探讨了金融企业区域集中库的设计构想和测试验证，包括架构设想、数据库整合场景测试及优势和使用设想。作者提出利用 TiDB 数据库产品集中建设区域集中库，解决 MySQL 存量节点的整合问题，实现部署的标准化、按需扩展和统一运维管理。文章详细介绍了测试内容和结果，强调了区域集中库在建设和运行成本、服务质量等方面的优势，并提出了相应的管理措施，为金融企业数据库架构提供了有价值的参考。

区域集中库的架构设想

在银行等金融企业的网络设计中，会根据服务主题将内部网络分割成若干个网络安全域，如：核心网络域、网银网络域等。在各个网络域中，根据业务应用对数据库的需求配置资源。随着业务的创新和发展，MySQL 存量节点多，管理难度大，资源利用率低，背离了规模部署、高效运维、敏态供给的云化发展理念，在生产运行的各阶段中存在不少的能力短板，比如：

• 部署建设阶段
  • 以业务发展目标或者每日批量压力高峰进行数据库资源规格评估，可能存在资源浪费和发展不同步的可能性。
  • 不同的版本、部署方案、变量参数和管理平台共存， 配置的碎片化不利于团队知识管理，阻碍标准化发展。
• 生产运行阶段
  • 应用数模设计阶段缺少主键约束造成主从同步延迟，影响从库数据时效，高可用机制可能存在不稳定。
  • 业务应用重复订阅全行统一的人员、机构和客户等主数据推送，浪费存储容量，占用数据库和网络资源。
  • 数据库面对下游业务的数据供给需求，复制链路构成较为复杂的网状结构，管理和维护成本较高，客户上限制了数据价值的进一步挖掘。

TiDB 数据库产品具备良好的水平扩展能力，能满足高并发大数据量业务的使用需求。通过 resource control 特性可划分集群资源，承载不同的业务应用。设想在单个网络域中集中建设一套 TiDB 集群，进行当前业务的迁移，整合替代“孤岛式”的 MySQL 集群（见图一），实现部署的标准化、按需扩展和统一运维管理。

图一 “孤岛式”的 MySQL 集群和分布式数据库区域集中库演进设想

数据库整合场景测试

基于网络区域集中库的设计构想，进行实际整合场景的需求抽象，使用 TiDB 做为测试平台，验证在分布式数据库上快速创建不同规格的数据库服务以提高设备利用率，并通过标准化高可用等管理体系降低总体成本。

资源管控

Request Unit (RU) 是对 CPU、IO 等系统资源的统一抽象的计量单位，用于表示对单个请求消耗的资源量。请求消耗的 RU 数量取决于多种因素，例如操作类型或正在检索或修改的数据量。

• 集群资源的评估

测试集群配置为三台两路 ARM 服务器。使用 oltp_read_write 模型估算集群的 RU 上限为 163000 RU（见图二）。

图二 oltp_read_write 模型容量估算的标签页

使用 TPCC 模型估算为 459000 RU（见图三）。

图三 TPCC 模型容量估算的标签页

使用 root 用户进行 oltp_read_write 模型高并发压测可得集群最大 RU 365000（图四）。

<