客户心声｜福建海峡银行TDSQL国产分布式数据库应用实践

数据库选型一直是困扰客户的难题，不仅要考虑底层的数据库技术，还需要结合企业业务特点、企业未来规划做决策。如何快速掌握数据库选型秘诀呢？答案无疑是看市场怎么做，看市场的同行是如何选择的。

近期，腾讯云数据库TDSQL助力福建海峡银行新一代核心业务系统正式上线（点击查看详情），为城商行提供核心改造解决方案。新核心关键业务系统采用“微服务+分布式”架构，改造历时14个月，依托腾讯云企业级分布式数据库TDSQL良好的兼容性、成熟的迁移能力和技术服务支持，海峡银行快速完成了核心系统的国产数据库替换，并基于腾讯云数据库TDSQL两地三中心高可用架构，实现了同城双活和异地容灾。在同等的计算和存储资源需求下，预计每年可节约800万元，并将持续发挥降本增效的作用。

今天，我们来听听客户怎么说。福建海峡银行信息科技部朱正珊为大家分享TDSQL国产分布式数据库在福建海峡银行的应用实践，用福建海峡银行的“亲身经历”教会您如何选型，如何优化，其中的关键节点、注意事项也都一一给您讲清楚。

实施背景

福建海峡银行成立于1996年12月，是一家省级股份制商业银行。截至2021年末，全行资产总额2011.46亿元，各项存款余额1506.45亿元，各项贷款余额1108.79.亿元。

早期，Oracle数据库在开放性、可伸缩性、风险性有更多的先发优势，因此我行的数据库应用也以Oracle为主。

随着近几年，云计算和大数据时代，金融业务飞速发展，业务流量激增，"IOE"架构的数据库在业务连续性和扩展性上面出现了明显短板，为加强技术储备、提高业务连续性、降低成本和提高核心竞争力，海峡银行适时探讨数字化转型，寻找具备多中心部署多活能力的数据库。

选型原则

我们从安全性、稳定性、业务连续性、运维成本、实施案例、产品生态等多维度出发，经过多轮测试选择了腾讯云企业级分布式数据库TDSQL。腾讯云TDSQL具备多副本强一致性特性，在高可用方面具备同城双活、异地灾备等功能，支持弹性水平扩展，在智能运维层面提供自动化运营、监控预警等功能。

实践历程

TDSQL概览

TDSQL的结构比较清晰，包括应用端（对应业务系统）、对外服务的网络接入层、核心数据存储区域、管理调度区和数据交换及备份区。

网络接入区主要是应用端与TDSQL中间的负载均衡组件，可采用TDSQL的LVS组件也可以使用传统的硬件负载均衡设备，如F5。

核心数据区所部署的节点为TDSQL的数据库节点包括Proxy和DB节点。

Proxy节点在每个网络区域至少2台，实现查询访问的的关键所在,主要负责接收客户端的查询请求，根据目标表的分布信息对查询请求进行拆分，转换成子请求发送给后端数据库执行，最终汇总各个数据库的执行结果，并将结果返回给客户端。

DB节点，也就是TDSQL的数据存储节点，通常采用一主多从的模式进行部署。在proxy和DB节点还有mysqlagent组件，作为TDSQL的旁路模块，承担着节点和集群（zk、schedule）桥梁的作用，主要用于自动拉起服务进程、一致性切换、主备同步和备机重做等操作。

管理调度区，主要部署TDSQL的集群管控节点，如zk集群、Schedule组件、OSS组件、监控数据采集、分析告警组件以及日常自动化运维的赤兔平台。TDSQL集群管控节点的主要保障数据库的高可用容灾等。

最后端为数据备份和交换区，涉及到数据交换和备份存储的HDFS集群和异构数据迁移工具DBbridge、慢日志收集和分析的ES日志服务器。

TDSQL 部署架构

海峡银行TDSQL生产环境是基于两地三中心架构（福州主中心、福州同城灾备中心以及厦门异地灾备中）进行部署，分别构建两个TDSQL集群，其中福州集群纳管是生产中心和同城灾备中心两个中心的所有节点，厦门灾备集群则纳管厦门异地灾备中心节点。集群之间采用TDSQL DCN准实时同步复制功能，可以实现异地灾备RPO小于1分钟，RT0小于15分钟，同城灾备RPO=0，RP0<2分钟。在同城中心里面采用跨IDC强同步，保证在双中心同城双活的情况下，至少保证同城中心数据和生产中心是一致的。

实践历程

2020年初海峡银行选择了客户量大、并发峰值高、场景丰富、响应实效要求高的互联网电子渠道（个人手机银行和个人网银）作为分布式数据库的首个应用试点，同年10月投产。经过反复调校，在高并发场景下，互联网电子渠道系统可用率能够达到99.99%以上，系统同城灾备切换演练，系统RTO时间由1200秒提高至98秒，这98秒是指业务系统从断开数据库链接到从库数据库接管业务的时间周期，从数据库层面来看的切换时间是42秒。

2020年底海峡银行在手机银行试点应用的基础上选择了交易流程复杂、改造难度高的新一代信用风险管理系统进行分布式数据库试点应用。在实施过程中，集中建设厂商、数据库厂商和业务人员各方力量共同梳理优化业务流程，优化数据库设计，顺利完成风险管理、对公信贷风险预警系统、资产保全和额度管理等子系统的投产，系统单笔处理时长、高并发成功率等关键指标均超过设计目标。

这两个项目基础之上，我们在2021年2月份开始启动新核心项目群建设重点攻关工作。在核心业务系统的数据库设计上，我们采用多个不同的数据库实例，包含公共库、历史库和联机库，这三者之间涉及到数据同步复制，我们采用了TDSQL里 kafka多源同步组件，这样可以避免微服务交易的调用链过长。联机库只保留短期内数据，历史库设计用于长期保留业务数据。

关键节点

关注库表设计评审。在系统建设的开发设计阶段，DBA团队就要介入到库表设计中去，因为分布式数据库引入了分片关键字的概念，根据全局业务选择最佳的数据分布策略。对数据分片进行存储设计，需要足够的了解业务，并与开发团队探讨出合理的数据冗余规则，才能做好仅需一次查询即可实现获取相关数据。TDSQL可使用三种类型的表，分别为单表、广播表和分片表。分表是大表，记录数大于200万或300万；广播表是小表，以查询为主，有少量更新操作和跨表join的查询操作；单表有频繁的更新操作，无跨表join的查询，比如只对用户本身查询的表可以建为单表。

句法差异性提前宣导。目前使用的分布式数据库与传统Oracle数据库之间存在语法差异。在项目建设初期，需要进行差异性培训宣导。在Oracle支持但MySQL不支持的场景下，需要多方参与讨论，对业务流程进行重构，以此来规避语法差异带来的问题。

其他数据库特性差异宣讲。存储过程、视图、触发器使用上是在开发规范中强制拒绝掉，尽可能把数据库当成一个简单的数据存储工具，不再像以前一样把非常多的业务逻辑放在上面。这部分强调数据处理要调整到应用层去实践。

性能问题解决。每一种数据库的应用都不可避免会出现一定的性能问题。在解决性能问题的根源上，第一是在基础设施在设置上的优化，比如说服务器的参数配置，网络参数配置，如何选择一个合适的版本以及怎么去优化资源、优化数据模型，最终做到一次查询满足所有的业务流程，避免多次操作带来大批量数据的磁盘、IO的占用。在基础设施优化的基础上后，重点关注SQL性能，可采用二八原则重点突破。抓住20%的SQL，即执行频率最高、执行时间最长，先优先处理高频交易，后关注批处理时效。

寻找最佳实践。结合TD的慢SQL日志捕捉功能，持续对前面四个关键节点进行持续优化，寻找全局最佳实践方案。

经验总结

应用中的关键节点

基于海峡银行分布式数据库应用过程中的经验，我从以下几个关键节点去展开分享：

持续做好开发规范更新培训工作。从2020年1月开始，我们就基于原厂商的开发规范，结合各个系统的试点工作，持续优化更新开发规范。并且在后续项目开始之前，我们会对相关开发人员进行规范培训。特别是连接池的使用培训，这是因为在实际工作连接失效的问题经常出现。

做好基础设施基线选择。每个系统建设过程中都会面临基础设施基线的选择问题，例如基础硬件资源的配置、系统及内核参数配置、数据库版本的选择、网络带宽以及F5的设置。

做好开发规范落实检查。项目开发进入集成测试阶段或性能测试阶段，就需要检查字符集的设置、大对象字段的使用、表类型选择的合理性、字段默认值设置（避免空指针）以及字段类型定义，进行评估和回溯。

常规问题普及。我行持续开展赤兔平台应用培训，同时也整理了TDSQL性能优化的宣讲材料，并且这个材料是在不断优化的，帮助开发人员将性能优化落实到位。这样避免了开放人员在实际生产过程中出现问题又要回过头来解决问题。

性能测试问题收敛。在性能测试这方面我们要关注问题，做到问题收敛。常见的方法有应用性能测试、多场景性能测试，我们要重点关注性能瓶颈点，也就是前面讲过的二八原则中的20%。

投产阶段实施流程优化。对于投产实施阶段，我们要和项目组一同梳理投产流程，尽可能做到自动化处理，缩短投产时间。

注意事项

在整个使用过程中，我们也整理了一些注意事项。

基础设施要进行优化，软硬件资源合理配置，适当调整运营监控，在版本标准化、语法兼容性、性能优化上需要不断的测试。接下来会进行详细的介绍：

多中心多活

在整个实践过程中，我们要求腾讯云数据库TDSQL实现多中心多活这个基础要求。

第一点尽可能做到多中心要互联互通。在两地三中心方案的真实实践过程中我们发现，同城中心和异地灾备中心之间带宽资源不足时，会导致同城切换方向有所偏差。

第二点，同城中心要万兆带宽以上。因为同城中心在我们的业务系统上线的时候，会有大批量的数据同步，包括了数据复制、数据库多副本同步、备份节点数据同步等。为满足基本的业务需求，至少需要万兆带宽。

第三点，中心内部也需要万兆带宽，尤其是应用端、Proxy、DB节点之间的链路。

第四点，最好配备域名解析系统。因为在高可用切换测试的过程中，我们发现配备了域名解析系统后，能够实现无缝监控切换。

经过网络故障推演，我们发现基于TDSQL的跨IDC强同步，同IDC异步、同IDC可提升为强同步、管控主节点在主中心的要素设置下，可避免批量数据更新导致延迟的情况以及在极端情况下出现分布式数据库脑裂的场景。可能出现脑裂的场景在于主中心与同城灾备中心之间的网络异常断开，紧接着主中心与异地灾备中心的网络出现异常，主中心形成网络孤岛。

合适的硬件选型

合适的硬件选型是非常重要的。我们在同等的CPU、内存资源场景下进行过压力测试，其结果显示PCLe接口（NVMe协议）固态硬盘性能优于SATA接口的固态硬盘，在大部分场景下TDSQL在PCLe接口固态盘上吞吐量要比SAS接口盘高100%。

在服务器选择上面，我们需要高性能网卡，避免网卡性能成为瓶颈点。TDSQL的proxy这一层会有SQL解析的过程，如果能够将SQL解析直接下发到DB层去执行得到汇总结果，再返回应用端。这样对网卡的性能要求就不会太高。但是也存在一种情况，SQL下发到各个节点上无法执行，需要DB节点把数据传输到计算节点上，这时候计算会出现大批量的数据载入，网卡的性能将成为一个关注点。

在测试过程中，我们也发现了在联机交易和夜间批处理交易过程中，交易重叠的时候，会出现联机交易时长会大幅度提升。总的来看，网卡性能是不太容易被发现的点。

对于数据存储节点，尽可能配置NVME协议的固态硬盘和大容量内存服务器。

对计算节点要选择高性能CPU，同时对内存的要求也比较高，因此也要选择大容量内存服务器。

运营管理

在运营管理这一部分，分布式数据库的组件多、服务器多、节点跨中心。对分布式数据库来说，需要快速的故障隔离和恢复，这就需要多层级的高可用机制、良好的运行监控体系、自动化运维体系，带来比较好的运营管理体验。

我们在实践过程中也在不断的结合TDSQL本身的特性做优化。比如说借助TDSQL自身的监控平台，对接行内的统一监控告警进行实时监控，做到实时监控、实时告警，及时处置。在通过自动化运维平台预设置一些TDSQL组件快速修复预案。在这两年的运营过程中，我们也内部优化了TDSQL的运行监控脚本，内嵌快速收集现场日志优先恢复服务的脚本，做到不影响交易、不影响业务。TDSQL本身的运行机制也能够快速告知我们本身存在哪些问题，有哪些问题可以尽早攻坚。

在运营管理中最重要的一点是，避免大批量数据更新查询操作，尽可能将此类操作进行分解，大化小。我们在测试过程中出现过大批量数据的更新操作，发现这带来了主中心和同城中心之间的数据延迟，同步延迟非常大。这时就需要重做备机操作来降低同步延迟恢复时间。于是我们对这一操作进行了拆解，也就是大化小，从而能够进行快速的事物同步，避免了主备延迟的场景。

标准化

标准化有两个要求，一个是版本统一，另一个是字符集编码统一。

版本统一，例如开发环境、SIT环境、BAT环境、准生产环境、生产环境等，我们需要都要做到所有环境的版本都是一致。可能不同银行的版本要求会有所不同，但海峡银行是这样要求版本统一的。在新核心建设过程中，经历了3次版本升级。从最初的TDSQL10.30161401 升级到了10.3016.1的版本，这次TDSQL内核引擎的升级是为了支持MySQL8.0版本。去年8、9月份，应国产化改造需求，我们进行了又一次内核版本的升级。在今年的3、4月份，演练的阶段，针对演练中的问题又开始了一次升级。

字符集编码统一是非常重要的，当字符集没有统一规范时，会出现语句在同一套系统中查询出来的结果不相同，例如大小写可能出现区分了。

语法差异性

传统集中式数据库与分布式数据库必然存在语法上的差异或者功能上的限制。在每个项目的启动阶段，我们都要对数据库相关的开发人员进行规范培训，同时也在不断的更新规范，根据代码走查和多方沟通，我们会不断完善业务流程，进行重构设计等工作。

优化方向成效比

从优化成效比上来看，SQL语句和索引的成本最低，效果最强，成效比最高。因此这里可以看出制定规范的必要性，以及遵循规范需要强制性。

性能优化思路

总的来说，在使用TDSQL过程中性能优化的总体思路体现在四个方面，分别为硬件资源、系统配置、库表索引设计、SQL语句及业务架构。

在硬件资源上，我们要适当的提高硬件资源配置，调整网络带宽；在系统配置方面，例如优化系统主机、X86架构的服务器，在参数配置上要合理调试。最重要是库表索引设计方面，在项目开发设计阶段，就需要介入其中，调动开发人员在库表索引设计方面的评审沟通上更加积极主动，使得数据的分散在合理范围内，并采用适当的冗余机制来避免多表查询带来大批量数据的开销。SQL语句及业务架构也是在实践中的优化重点。

﹀

﹀

﹀

-- 更多精彩 --

↓↓点击阅读原文，了解更多优惠