如何写一份食品的网站建设规划,软件开发专业培训学校,色彩搭配 网站,租车网站建设本文详细介绍了中泰证券在系统国产化改造项目中采用 TiDB 多租户技术的实施过程。文章分析了中泰证券数据库系统现状以及引入 TiDB 资源管控技术的必要性#xff0c;探讨了 TiDB 多租户的关键特性#xff0c;并阐述了在实际应用中的具体操作步骤。通过该技术的应用#xff0…本文详细介绍了中泰证券在系统国产化改造项目中采用 TiDB 多租户技术的实施过程。文章分析了中泰证券数据库系统现状以及引入 TiDB 资源管控技术的必要性探讨了 TiDB 多租户的关键特性并阐述了在实际应用中的具体操作步骤。通过该技术的应用中泰证券有效降低了运维成本提升了开发效率。 文章强调了 TiDB 多租户在证券企业中的应用优势特别突出了其在资源观测、复用、可配置性等方面的价值。
项目背景
中泰证券股份有限公司原名齐鲁证券有限公司成立于 2001 年 5 月是国内排名前 20 的全国大型综合性券商在全国 28 个省市自治区设有 45 家分公司、280 多家证券营业部员工 9000 多人控股中泰期货、中泰资本、中泰金融国际、中泰资管、中泰创投、齐鲁股权交易中心、万家基金形成了证券、期货、基金、投资等各项业务齐头并进的发展格局。
受国际环境影响在国家政策的大力支持下系统国产化开始在全国范围内加速落地。中泰证券在系统国产化改造项目中使用 TiDB 和国产化操作系统、芯片提升自主可控能力。
中泰科技研发部目前使用两套 TiDB 集群将多套业务系统进行集合。TiDB 集群版本号均为 V7.1。按照业务系统服务对象的不同分别承载对外和对内客户业务。基于 TiDB 对大表的支持性更友好无需分库分表复杂 SQL 的性能提升明显TiDB 的弹性扩缩容简单易运维操作。这些都毫无疑问地降低了运维成本、提升了开发效率。但是这两套集群都是多套业务系统共用因此非常需要资源管控技术确保每一个业务系统都拥有独立的资源池。
TiDB 多租户介绍
TiDB 6.6 首次引入资源管控Resource Control简称RC特性并在 TiDB 7.0 进行了优化和增强。该技术利用资源组 (Resource Group) 限制每个资源组所能使用的计算和 IO 资源同时创造性的引入 burst 可超用属性当集群有空闲资源时允许资源组超越限制实现资源的充分利用。 这个特性满足了目前一些企业的需求也可以顺带解决了部分用户的痛点
业务系统间影响和干扰 某个业务系统的非预期负载变化会影响其他业务系统的正常运行。分析业务对交易的影响 对资源需求较高的数据分析或批量作业会影响其他业务系统的响应时间。运维操作对资源的消耗 数据备份、统计信息收集等后台任务可能会影响服务质量。
具体应用和实施
以下文章内容中的数据均基于生产环境做过修改不是真实数据仅供参考。
3.1 资源评估
打开 Dashboard 页面在左侧菜单列表中找到 Resource Manager在 Estimate Capacity 中 根据标准测试类型进行资源评估。 3.2 应用绑定 RU
通过梳理数据库中的业务用户确定哪些用户是属于哪些业务系统方便后面将不同的资源组与不同的用户绑定。
执行以下 SQL 为业务 A、业务 B、以及管理员绑定 Resource Control 和 RU。业务 A 和业务 B 同属于 TP 系统业务重要性较高对 sql 查询速度和效率都有一定的要求对慢查询容忍性较低。所以对业务 A 和业务 B 的资源分配优先级要高一些并且允许资源超用BURSTABLE应对前端业务流量的突增。而管理员账户日常主要用来做数据库管理相关的工作很少或者不涉及业务 SQL所以资源分配优先级较低可以先设置成允许资源超用。
初步绑定都设置 BURSTABLE 属性确保每个业务都有充足 RU 可以使用避免资源不足情况而无法观察到某个业务真实 RU 消耗情况。
-- 创建A资源组
CREATE RESOURCE GROUP IF NOT EXISTS a_rg RU_PER_SEC180000 PRIORITYHIGH BURSTABLE;
-- 创建B资源组
CREATE RESOURCE GROUP IF NOT EXISTS b_rg RU_PER_SEC90000 PRIORITYHIGH BURSTABLE;
.....
-- 创建管理员查询资源组
CREATE RESOURCE GROUP IF NOT EXISTS admin_rg RU_PER_SEC20000 BURSTABLE;
-- 为不同业务系统用户绑定资源组
-- 将A资源组绑定到A业务系统用户上
ALTER USER a_user RESOURCE GROUP a_rg;
-- 将B资源组绑定到B业务系统用户上
ALTER USER b_user RESOURCE GROUP b_rg;
.....
-- 将管理资源组绑定到系统管理用户上
ALTER USER admin_user RESOURCE GROUP admin_rg;
3.3 观察应用 RU 使用情况
完成绑定后 TiDB 可以实时统计到各个业务消耗的资源情况。生产运行一段时间后需要观察业务实际消耗 RU 完成后续调整。
依然是去 Dashboard 页面在左侧菜单列表中找到 Resource Manager。这个页面较之前业务系统用户没有绑定 RU 之前多了一个 Configuration 模块。可以在这里模块清晰的观察到每个资源组的详细信息。 继续在 Resource Manager 页面中找到 Metrics 模块观察 RU 的使用情况建议观察时间区域尽可能长以得到更全面的 RU 消耗情况如下图所示。 将这个曲线和上面 Configuration 模块的 RU 信息对照查看是否需要进行 RU 调整。调整语句如下
-- A业务系统最高消耗 17000 RU 建议绑定 25000 RU 预留一定 Buffer 由于总体资源充足设置 BURSTABLE 属性确保业务有足够资源
alter resource group a_rg RU_PER_SEC25000 PRIORITYHIGH BURSTABLE;
-- B业务系统最高消耗 14000 RU 建议绑定 20000 RU 预留一定 Buffer 由于总体资源充足设置 BURSTABLE 属性确保业务有足够资源
ALTER RESOURCE GROUP b_rg RU_PER_SEC 20000 BURSTABLE;
-- 设置管理员查询资源组不设置 BURSTABLE 属性降低管理员执行 Slow Query 时对集群影响
alter resource group admin_rg RU_PER_SEC10000;
RU 使用收益
由于目前 TiDB 服务器资源充足并且各个业务系统的峰值谷值都具有同一性每个业务系统的重要程度也差不多。所以 TiDB 这个多租户特性带来的价值主要体现在资源的可观测性和可配置性上。
在资源可观测性上 有了 RU结合 Dashboard可以清楚的观察到每个业务系统使用了多少资源TiDB 整个集群资源是否充足是否需要添加资源。
在资源可配置性上 TiDB 多租户最重要的能力是在资源繁忙时实现资源控制后续继续迁移新业务导致资源不足且临时没有服务器添加到集群的场景下可以在线解除 BURSTABLE 属性给业务设置合适的 RU 大小来实现资源控制。此能力可以在线调整对业务几乎无感知。在资源不足的极端场景下能够控制不同用户的资源消耗保证各业务系统的资源隔离性用户可以安心使用 TiDB 多租户能力。
结语
大部分企业会给 TiDB 集群预留充足资源此时利用 BURSTABLE 属性实现资源观测和资源复用小部分企业无法给 TiDB 集群预留充足资源此时可以在线修改多租户配置并实现资源控制。
目前在证券企业中许多业务系统跑在不同的 MySQL 集群上面。随着 MySQL 5.7 生命周期结束以及 IT 基础设施国产化改造的推进把存量的多套 MySQL 集群归集到一套 TiDB 集群成为一个理想的解决方案。通过 TiDB 的资源管控特性多个业务能够共享一套集群实现资源的有效利用。对比传统多租户方案TiDB 多租户除了基础资源控制能力以外还提供了更强大的资源复用能力、资源可观测性、在线可配置性、在线限流等能力。可以更好降低整体硬件成本、减少多集群运维成本、观测资源池使用率。
