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

作者： watermelon_cn 原文来源：https://tidb.net/blog/09bd7c2a

来源：金融电子化

文 / 杭州银行数据库专家 邵健 张显华

区域集中库的架构设想

在银行等金融企业内，通过网络安全访问策略根据服务主题将内部网络分割成若干个网络安全域，如核心网络域、网银网络域等。在各个网络域中，根据业务应用对数据库的需求，配置数据库资源。随着业务的创新和发展，独立部署形态的 MySQL 集群数量持续上升，成为一个个运维和数据孤岛，脱离了数据库服务规模发展、高效运维和按需敏态供给的发展理念，在生产运行的各阶段中存在不少能力短板。

1. 部署建设阶段

（1）资源分配。业务部门在申请数据库规格时，通常会以多年后的业务发展目标用于初始申请，客观上在发展期内存在资源浪费。并且共享虚拟化平台资源，可能会出现规格和性能预期不一致，或者超分配情况下与其他业务相互影响。

（2）版本和管理平台。在行内 MySQL 推广发展的历史过程中，MySQL 版本、部署方案、变量参数和管理平台均有不同方案共存，形成了管理成本较高的历史包袱，管理配置的碎片化不利于团队知识管理，阻碍了数据库服务朝向标准化云化发展。

2. 生产运行阶段

（1）主从同步延迟。MySQL 主从同步复制依赖于表的主键和索引设计，应用数模在开发阶段缺少指导和约束，部分表缺主键等导致主从同步延迟极大，高可用机制存在不稳定，也影响读写分离的实现。

（2）上游的数据推送。大量业务应用的数据库都订阅了全行统一的人员、机构和客户等主数据的数据推送，多份的数据存储不仅浪费容量，重复推送也大量占用数据库和网络资源。

（3）数据的供给。各个业务数据库相互独立，面对下游业务的数据供给需求，需要配置管理多个数据源和复制链路，构成较为复杂的网状结构，管理和维护成本较高，客观上限制了数据价值的进一步挖掘。

（4）日常运行状态管理。MySQL 对于复杂 SQL 和历史版本一致性读取等特性的支持较弱。分布式数据库产品相较于 MySQL 数据库具备良好的水平扩展能力，能满足高并发大数据量业务的使用需求。通过数据库资源管理特性可在一套集群内划分资源，承载不同的业务应用。结合分布式数据库的水平扩展能力和资源管理特性，设想在单个网络域中集中建设一套分布式数据库集群，进行当前业务的迁移，整合替代“孤岛式”的 MySQL 集群，实现部署的标准化和统一运维管理。

数据库整合场景测试

基于网络区域集中库的设计构想，进行实际整合场景功能的需求抽象，利用 TiDB 数据库的资源管理特性作为实践平台，通过测试验证分布式数据库集群是否可以实现数据库整合和按需供给，满足业务创新和生产运行需求。

1. 资源管控

分布式数据库测试集群配置为三台两路 ARM 服务器。Request Unit（RU）是对 CPU、IO 等系统资源的统一抽象的计量单位，用于表示对单个请求消耗的资源量。请求消耗的 RU 数量取决于多种因素，如操作类型或正在检索或修改的数据量。

（1）集群资源的评估。基于硬件配置使用 sysbench read_write 模型估算为 163000 RU、基于硬件配置使用 TPCC 模型估算为 459000 RU、使用 root 用户进行 sysbenchread_write 模型压测从监控可得最大 RU 365000，三种评估方法结果显示：同一模型下 RU 估算与实际压测的差距较大，实际中发现 RU 评估未能正确识别混合部署。

（2）不同规格 RU 对联机交易的影响。sysbench 压测工具使用三个数据库用户对应三个资源组。同时进行 sysbench read_write 压测时 RU 使用监控，三个用户压测 QPS 和实际 RU 使用结果显示：RU 使用量上限符合 RU 配置，QPS 与 RU 配置成正比关系。

（3）资源组 BURSTABLE 属性对调度的影响。三个 sysbench 压测用户对应三个资源组，其中 test_rg1 启用 BURSTABLE 属性。先进行 test1 用户的 sysbench read_write 压测，再依次启动 test2 和 test3 用户的压测。三个用户压测 QPS 和实际 RU 使用结果显示：当系统资源空闲的情况下，BURSTABLERU 属性可以充分利用空闲资源；当系统资源繁忙的情况下，会自动调整 RU 的使用率。

（4）在线调整 RU 对联机交易的影响。进行 test1 用户的 sysbench read_write 压测，在压测过程中在线调整资源组的 RU 值。资源组配置变更即时反应到实际 RU 使用。

（5）在线调整 RU 对单 SQL 的影响。执行包含子查询的单 SQL，并在执行过程中降低资源组资源上限。会影响正在执行中 SQL，降低资源组 RU 上限后，即时生效，执行时长变长。

（6）会话级别设置资源组。test1 用户的默认资源组是 test_rg1。编辑 oltp_read_write.lua，在 event() 函数内的事务启动语句前增加资源组配置语句，模拟在一个会话中，切换默认资源组。使用 test1 用户进行 read_wite 模型压测，实际使用到 20000RU 后趋于稳定，符合 test2_rg 的配置。

2. 读写分离

ETL 数据抽取、交易异步检查、数据备份等场景属于只读场景，为防止对业务主交易造成影响，沿用 MySQL 读写分离架构，需要配置一份只读数据。集群在 Raft 共识算法数据三副本基础上，可配置一种特殊的 Learner 角色，它只参与同步 raftlog 而不参与投票，可用来实现读写分离。使用 Placement rules，将集群中配置有 logic3 标签的单台 TiKV 服务器配置为 Learner 角色。

（1）会话的读写分离。设置会话属性 tidb_replica_read 为 Learner。执行查询 SQL 时只使用 Learner 节点的资源，其他节点没有消耗资源。

（2）物理备份的读写分离。使用 –replica-read-label’logic:logic3’ 参数执行 br 备份命令。br 备份操作只从 Learner 节点写备份文件。备份过程中只使用 Learner 节点的资源，其他节点没有消耗资源。

3. 业务管理

在集中库进行业务整合的场景中，类似数据平面和管理平面的分拆，不仅需要关注数据库的资源限额管理特性，还需要关注多业务整合后，数据库是否具备管理特性，如 SQL 黑名单、细粒度的监控、连接的标识区分等。

（1）SQL 黑名单功能。一是资源组的自动策略。配置 default 资源组 query limit 策略属性，语句执行超过 100s 后自动 kill。查询 information_schema.resource_group 验证配置策略。二是手工配置黑名单。通过慢日志或者 SQL 概览页面得到 sql digest 后添加到 query watch 清单中。查询 information_schema.runaway_watches 验证配置策略。SQL 语句执行后提示因为命中 runaway 清单被中断。查询 mysql.tidb_runaway_queries 验证中断记录。

（2）业务会话标识功能。一是会话的 tidb_session_alias 变量。DBMS_APPLICATION_INFO.SET_MODULE 是 Oracle 数据库中的一个 PL/SQL 包过程，用于设置应用程序信息模块的名称，通过查询 v$session 的 module 列可以帮助追踪运行在 Oracle 数据库上的应用程序或会话的相关信息。会话变量 tidb_session_alias 可用来自定义当前会话相关日志中 session_alias 列的值，实现与 Oracle 类似的功能，如在会话中配置交易码信息。模拟在一个事务内多次配置 tidb_session_alias：编辑 read_write 模型脚本 oltp_read_write.lua，在 event() 函数内的不同语句前后增加不同的业务标识 QUERY001\QUERY002\QUERY003，模拟在一个会话中，可以关联并切换应用多个交易码；慢日志和 generallog 都带有 session_alias 会话属性；会话视图带有 session_alias 会话属性。

二是会话属性 session_connect_attrs 表。performance_schema.session_connect_attrs 表提供了连接属性的信息，连接创建后不可修改。可以配置应用 JDBCURL 的 connectionAttributes 特性或者使用驱动接口，添加应用连接的自定义属性，如：app_name:bank 和 ver:v1.0。以 Jmeter 为例，连接串 URL 配置为 JDBC:mysql://IP:PORT/DB?connection Attributes=app_name:bank,ver:v1.0&…。系统表 performance_schema.session_connect_attrs 中可以查看应用的自定义属性。

（3）细粒度监控功能。与 QPS、Duration 相关的几项 metrics 指标会带有各个 db 和 resource_group 标签，在 grafana 添加对应的监控面板后，可以查看 db 和 resource group 维度的运行指标。

4. 测试小结

通过以上的测试，小结如下：一是资源隔离特性具备数据库规格限制、在线调整即时生效的特点。二是在业务混合共享集群的场景下，可以基于不同业务在不同时间段的资源消耗特点进行合理资源“调度”，实现资源利用的效益最大化。三是额外添加 Learner 角色数据单副本节点，可用于数据抽取、查询和备份等场景，节省“从集群”的资源开销。四是新特性对生产上偶发但影响面较大的不良 SQL 能实现有效隔离，通过规则（执行时长）、已知的 SQL 指纹（文本 /digest/plan digest）、修改资源组上限，能实现对整个集群的资源保护，保护重要应用的持续运行。五是通过业务会话标识和细粒度监控功能，可以基本满足应用整合后的数据操作观测需求。六是产品的使用过程中需要继续改进的功能反馈给产品部门，已经在版本规划中。

采用不同的业务模型得到的集群估算 RU 上限相差较大，同一模型估算的 RU 上限和实际压测的结果差距也较大，也不能正确的评估混合部署的影响，规划进行评估方法和公式的改进。Query Limit 策略目前只有执行时长，规划引入添加 RU 或者扫描行数等有业务价值的维度。BURSTABLE 属性可以考虑添加时间窗口属性，实现与业务时间特征的关联关系，规划引入 Resource Plan 的特性，关联一组资源组策略并基于时间切换。切换 Resource Group 目前没有权限控制，规划添加验证功能。

区域集中库的优势

经过测试验证，分布式数据库产品的集中库是将数据库整合的层次从原有的虚拟化平台提升到数据库层，通过细粒度资源配置，换取更高的灵活性，并利用相同资源承载更多的数据库。两种整合方式在某场景下主要适用特性的对比（见表）。

表  两种整合方式在某场景下主要适用特性的对比

综合各个能力项对比结果，评估分布式数据库整合部署方案在建设和运行成本、服务质量上均具有较大的优势：一是提升运行标准化，降低人员在部署和管理的工作量投入，避免个性化配置造成的故障隐患。二是丰富管理能力，缩短提供数据库服务的响应时间，有效管控上层的运行应用，充分利用闲置的冗余资源。三是减少成本投入，较高的压缩比节约存储容量，不需要从库节点资源，节约虚拟化层软硬件投入，避免虚拟化造成的性能损失。四是更强产品特性，分布式水平扩展支持业务扩展，HTAP 架构支持复杂 SQL 等。五是故障隔离能力弱于独立部署方式。如果涉及重启或版本升级等操作，影响面更广，有待于具备连接保持能力的负载均衡组件的成熟，或者结合规则限制数据分布节点，实现维护操作对应用连接影响最小化。六是资源管理特性目前在使用上对用户比较困惑是资源管理粒度的评估，如 sysbench 模型或者 CPU 等，业务人员并不熟悉具体的性能规格，不能直接对话。

通过区域集中库的建设整合，将进一步简化数据库产品使用场景的分层模型：第一层是多中心部署的分布式数据库，具备数据中心级的数据库服务容灾机制，适用于账务核心、网银等电子渠道的关键业务应用。第二层是分布式数据库，适用于业务并发和数据规模较大的对客交易和对内管理业务。第三层是分布式数据库的整合库和通过管理平台的标准化部署的单机数据库，适用于业务并发和数据规模较小或者预期负载上升较快的小型交易和管理业务。

根据测试结果，在区域集中库使用过程中，需要考虑配套管理措施：一是评估建设统一的典型业务压测模型（如转账交易），形成统一的标尺，根据该模型进行压测得到集群交易性能上限，按典型业务性能设计成多个规格，再由需求方根据该模型提交业务交易性能需求进行对接，按集群的交易性能上限的分配比进行扩容评估。二是配置 BURSTABLE 属性可以充分利用空闲的集群资源。不同业务应用的工作时间窗口不同，可以提前协调业务操作时间，为各个业务应用配置一个 BURSTABLE 的时间窗口，比如，根据业务批量任务发起时间在不同时间段动态调整不同资源组的 BURSTABLE 属性，以保证在整个批量期间能充分地利用闲置的系统资源。三是统一管理区域集中库的共享数据，即全行统一的数字字典，数据团队只需要接入一次数据，实现资源集约使用。四是对备份、ETL 抽取、数据查询平台等非业务的数据需求，通过命令参数或者会话参数进行标准化配置，利用单副本的 Learner 节点实现读写分离，保证业务应用的交易服务质量。五是与行内的低代码开发平台进行对接，通过框架的配置功能使用数据库的会话属性和业务会话标识功能，实现更加有效的 SQL 定位和管理。六是对接集中监控和日志平台，向业务应用管理员开放资源组语句监控和业务应用标识的慢 SQL 日志等管理功能。

通过区域集中库的建设，实现数据库部署架构的收敛和集中。在此基础上，可进一步对业务数据操作行为进行采集和分析，有利于运维方向向智能化转型。

（此文刊发于《金融电子化》2024 年 5 月上半月刊）