印度网站后缀,泰安市最新招聘信息,五八同城网站开发了多久,cnzz站长统计工具导读 本文探讨了金融企业区域集中库的设计构想和测试验证#xff0c;包括架构设想、数据库整合场景测试及优势和使用设想。作者提出利用 TiDB 数据库产品集中建设区域集中库#xff0c;解决 MySQL 存量节点的整合问题#xff0c;实现部署的标准化、按需扩展和统一运维管理。…导读 本文探讨了金融企业区域集中库的设计构想和测试验证包括架构设想、数据库整合场景测试及优势和使用设想。作者提出利用 TiDB 数据库产品集中建设区域集中库解决 MySQL 存量节点的整合问题实现部署的标准化、按需扩展和统一运维管理。文章详细介绍了测试内容和结果强调了区域集中库在建设和运行成本、服务质量等方面的优势并提出了相应的管理措施为金融企业数据库架构提供了有价值的参考 。 本文作者  邵 健 杭州银行股份有限公司数据库专家 张显华丨杭州银行股份有限公司数据库专家 区域集中库的架构设想 在银行等金融企业的网络设计中会根据服务主题将内部网络分割成若干个网络安全域如核心网络域、网银网络域等。在各个网络域中根据业务应用对数据库的需求配置资源。随着业务的创新和发展MySQL 存量节点多管理难度大资源利用率低背离了规模部署、高效运维、敏态供给的云化发展理念在生产运行的各阶段中存在不少的能力短板比 如 部署建设阶段以业务发展目标或者每日批量压力高峰进行数据库资源规格评估可能存在资源浪费和发展不同步的可能性。不同的版本、部署方案、变量参数和管理平台共存 配置的碎片化不利于团队知识管理阻碍标准化发展。生产运行阶段应用数模设计阶段缺少主键约束造成主从同步延迟影响从库数据时效高可用机制可能存在不稳定。业务应用重复订阅全行统一的人员、机构和客户等主数据推送浪费存储容量占用数据库和网络资源。数据库面对下游业务的数据供给需求复制链路构成较为复杂的网状结构管理和维护成本较高客户上限制了数据价值的进一步挖掘。 TiDB 数据库产品具备良好的水平扩展能力能满足高并发大数据量业务的使用需求。通过 resource control 特性可划分集群资源承载不同的业务应用。设想在单个网络域中集中建设一套 TiDB 集群进行当前业务的迁移整合替代“孤岛式”的 MySQL 集群见图一实现部署的标准化、按需扩展和统一运维管理。 图一 “孤岛式”的 MySQL 集群和分布式数据库区域集中库演进设想 数据库整合场景测试 基于网络区域集中库的设计构想进行实际整合场景的需求抽象使用 TiDB 做为测试平台验证在分布式数据库上快速创建不同规格的数据库服务以提高设备利用率并通过标准化高可用等管理体系降低总体成本。 2.1 资源管控 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图四。 图四 单个 root 用户测试的 RU 消耗监控面板 三种评估方法结果见表一表明估算和实际的差距较大估算方法需要改进。 表一 评估方法结果 不同规格 RU 对联机交易的影响 配置三个资源组的每秒 RU 参数 见图五数据库用户归属于资源组后每秒使用的 RU 上限受该参数控制。 图五 三资源组测试的资源组容量 三个用户对应三个资源组同时压测RU 使用平稳见图六。 图六 三资源组测试 RU 消耗监控面板 压测结果见表二表明实际使用上限基本符合配置QPS 与 RU 成正比关系符合配置规则。 表二 资源组每秒 RU 规划的业务测试结果 资源组 BURSTABLE 属性对调度的影响 配置资源组 test_rg1 启用可突发BURSTABLE属性见图七当系统资源闲置时该资源组可以超出上限。 图七 burstable 属性测试的资源组容量标签页 先发起 test_rg1 资源组中用户的压测RU 使用达到了 293000 左右体现 burstable 参数在集群空闲状态下的配置效果再发起另外两个资源组的压测test_rg1 逐步回落到资源组配置上限 160000 左右见图八。 图八 资源组 burstable 属性测试的 RU 消耗监控面板 压测结果见表三表明BURSTABLE 属性可以充分利用闲置资源。繁忙时会优先保证上限内的 RU 分配。 表三 资源组 burstable 属性的业务测试结果 在线调整 RU 对联机交易的影响 发起 test_rg1 组中用户的压测在线调整资源组的每秒 RU 值即时反应到实际 RU 使用见图九。 图九 在线调整资源组测试的 RU 消耗监控面板 压测结果见表四表明资源组配置变更即时反应到业务的 QPS 上。 表四 在线调整资源组测试的业务测试结果 2.2 读写分离 在 MySQL 架构中为防止对业务主交易造成影响将从库用于数据抽取、异步检查等只读场景。区域集中库也需要实现等同于读写分离的隔离效果分布式数据库配置 Learner 角色只参与同步数据而不参与多数派投票。 使用 Placement Rules 将 33 节点的 TiKV 实例标签配置为 Learner 数据副本监控中对应实例的 Leader 数量为 0见图十只同步数据不响应交易的读写请求。 图十 各个 TiKV 实例的 Leader 数量分布监控面板 会话的读写分离 设置变量 set session tidb_replica_read‘learner执行查询 SQL 时只使用 33 节点的资源见图十一。 图十一 TiKV 实例 CPU 监控面板 物理备份的读写分离 使用 --replica-read-label 参数执行 br 备份命令只使用 33 节点写入备份文件见图十二。 图十二 备份写数据监控面板 2.3 业务管理 多业务整合的场景中不仅需要关注资源开销还需要关注数据库的业务管理特性比如 SQL 黑名单、细粒度监控、连接标识等提升管理员的运维效率。 2.3.1 SQL 黑名单功能 资源组的自动策略 配置 default 资源组属性 query_limit(exec_elapsed100s, actionkill,watchsimilar )实现语句执行超过 100s 后自动 kill。慢 SQL 语句执行超时后被 kill测试效果如下说明自动策略可以支持慢 SQL 的自动化管理。 MySQL select now();select *,(select max(c) from sbtest2 where sbtest1.csbtest2.c group by id ) avgc from sbtest1 where sbtest1.id 5000;select now(); --------------------- | now() | --------------------- | 2024-02-05 15:33:15 | --------------------- 1 row in set (0.000 sec) ERROR 1105 (HY000): other error: Coprocessor task terminated due to exceeding the deadline --------------------- | now() | --------------------- | 2024-02-05 15:34:55 | --------------------- 1 row in set (0.000 sec) 手工配置黑名单 配置 query watch 清单 query watch add action kill sql digest DIGEST 值中。SQL 语句执行后提示被中断测试效果如下说明可以支持慢 SQL 的手工管理。 MysQL select *,(select max(c) from sbtest2 where sbtest1.csbtest2.c group by id ) avgc from sbtest1 where sbtest1.id 100; ERROR 8254 (HY000): Quarantined and interrupted because of being in runaway watch list 查询验证限制记录测试效果如下说明可分析黑名单生效记录。 MySQL select * from mysq1.tidb_runaway_queries order_by time desc limit 1\G *************************** 1. row *************************** resource_group_name: defaulttime: 2024-02-05 14:57:37match_type: watchaction: ki11original_sq1: select *,(select max(c) from sbtest2 where sbtest1.csbtest2.c group by id ) avgc from sbtest1 where sbtest1.id 100 plan_digest: 85484f90b715278bd114095a4bbbe168da158f24e824a04d11c09be7268fe2ab tidb_server: 10.186.136.31:4000 1 row in set (0.002 sec) 2.3.2 业务会话标识功能 会话变量 会话变量 tidb_session_alias 可动态定义会话中业务标识如当前运行的交易码信息会话视图、慢日志及 General log 的 session_alias 列中会记录运行值类似 Oracle 数据库 v$session 的 module 列可以帮助识别应用程序功能模块信息。 编辑测试描述文件 oltp_read_write.lua添加 con:query(set tidb_session_aliasQUERYXXX)模拟应用切换交易码。慢日志见图十三和 processlist 视图见图十四中 session_alias 标识 SQL可分析 SQL 语句的业务行为。 图十三 慢日志中的业务标识 图十四 processlist 视图的业务标识 会话属性 系统视图 session_connect_attrs 可查看连接的固定属性信息数据库侧可用于梳理应用的自定义连接信息。配置连接串参数 connectionAttributesapp_name:bank,ver:v1.0见图十五或者使用 JDBC 内置方法实现应用版本等标识。 图十五 Jmeter 的连接串配置 系统视图 session_connect_attrs 可查看应用的自定义属性见图十六说明可分析客户端信息。 图十六 系统视图中的客户端属性 2.3.3 细粒度监控功能 配置 record-db-label 可以在 db 和 resource_group 粒度上提供 QPS、Duration 等 metrics 指标在 grafana 添加监控面板见图十七。 图十七 细粒度的 QPS 和 Average Duration 监控面板 2.4 测试小结 通过以上的测试基本上验证了利用分布式数据库实现区域集中库的设想 资源隔离特性具备数据库规格限制支持用户、会话及语句等粒度。在线调整即时生效的特点可以基于不同业务资源消耗的时间窗口进行资源“调度”实现资源利用效益最大化。Learner 角色副本可用于数据抽取、查询和备份等场景保证生产隔离节省“从集群”的资源开销。通过规则和已知的 SQL 指纹对不良 SQL 能实现有效防范。通过业务会话标识和细粒度监控功能基本满足应用整合后的观测需求。集群 RU 评估方法、Query Limit 策略添加扫描行数或 RU 资源使用监控、资源组添加时间计划等有待继续改进。 区域集中库的优势和使用设想 区域集中库是将数据库整合落地在数据库层通过标准化部署和细粒度资源配置得到更高的服务可用性、规格弹性和资源利用率。两种整合方式的适用情况对比如表五。 表五 区域集中库特性对比 表五 区域集中库特性对比 综合各个能力项对比结果评估区域集中库在建设和运行成本、服务质量上均具有较大的优势。在使用过程中需要配套管理措施 开发建设典型业务压测模型如转账交易作为标尺根据该模型得到集群交易性能上限按典型业务性能设计成多个规格再由需求方根据该模型评估业务交易性能需求规格和业务批量窗口特点进行对接。统一管理区域集中库的全行主数据数据团队只需要接入一次数据实现资源集约使用。利用单副本的 Learner 节点实现读写分离对接备份、ETL 抽取、数据查询平台等非业务的数据需求。与行内的低代码开发平台进行对接通过框架的配置功能使用数据库的会话属性和业务会话标识功能实现更加有效的 SQL 定位和管理。引导应用运维自助查看资源组监控和细粒度日志。 通过区域集中库的建设整合将简化数据库能力分层模型图十八。 第一层关键业务使用两地三中心的分布式数据库。 第二层高并发大数据量业务使用独立的分布式数据库。 第三层规模较小或者业务发展规模较灵活的业务使用区域集中库。 图十八 数据库能力分层模型 通过区域集中库的建设实现数据库部署架构的收敛。在此基础上可进一步对业务数据操作行为的采集和分析有利于生产运行向智能化转型。