2.5　GoldenDB数据库应用开发和运维实践

以中信银行GoldenDB所代表的新一代原生分布式数据库，具有强一致性、线性扩展和高可用性，可以更好地满足商业银行应用开发和运维发展的需要。

但是，转型到分布式数据库后，并不是一帆风顺的，还会面临很对挑战。一方面，应用人员和开发人员需要正视挑战并采用具体举措，才能真正驾驭好GoldenDB数据库；另一方面，商业银行要遵守人民银行相关规范，以推动分布式数据库开发和运维的标准化。

2.5.1　分布式数据库带来的挑战

分布式数据库实现了数据去中心化，但是由于其自身特点，也给应用开发和运维带来了一些挑战，下面分别阐述。

1．应用开发方面的挑战

GoldenDB数据库实现了对应用透明，从功能角度，应用开发人员只要按照ANSI SQL标准语言去编写SQL语句完成业务逻辑。但从性能角度，还要注意在联机交易负载下，低效的应用程序将会对分布式数据库带来以下挑战。

（1）应用程序中过于复杂的SQL语句将会影响数据库性能。

例如这样的SQL语句：超过3张以上的大表关联、返回大结果集等，这些都会消耗数据库过多的处理资源，导致响应时间变慢。

（2）应用程序中不带分片键的SQL语句将会影响数据库性能。

例如，不带分片键的SQL语句，将会导致DBProxy将应用请求发给所有分片，将会导致查询时间变慢。

（3）过多的跨节点分布式事务将会影响数据库性能。

例如，一个跨节点转账的应用程序被并发方式执行，将会发起大量的跨节点事务，这将消耗数据库的处理资源，有可能导致事务执行时间变长。

2．运维方面的挑战

相较于应用开发，运维方面的挑战更多。从集中式到分布式数据库，对整个传统的运维体系有较大冲击，带来了很大挑战，具体包括以下内容。

（1）节点多且关联复杂。

集中式数据库运行在少数几台服务器上，但分布式数据库的各种节点运行在数百台服务器上，节点关系复杂，运维复杂度高，靠人工运维不现实，需要通过平台化运维的新思路，统一上报告警及统计信息、统一日志中心、自动化监控、自动化运维、自动化巡检等。

（2）x86服务器可靠性低，稳定性弱。

集中式数据库通常运行在小型机上，小型机故障率低。但是分布式数据库运行的x86服务器稳定性低于小型机，单机故障率增加。这就要求对所有节点的服务器和数据都进行冗余配置，当出现节点故障时，启动自动化应急，通过主备切换保证服务的持续可用性。

（3）部署结构复杂。

一个分布式系统不仅包括数据库，还包括应用多活集群、Redis缓冲集群等，部署架构复杂，这就意味着当出现软件或者硬件问题时，很难定位故障节点。因此，需要一套多维立体化监控手段，准确定位故障节点，并通过自动化应急在规定时间内解决故障。

上面探讨了分布式数据库引入对应用开发和运维方面的挑战。实际上，目前商业银行的应用开发和运维之间的界限已经相当模糊，开发人员和运维人员都需要掌握操作系统和数据库相关技能，还要掌握Java、Python等开发技能。建议引入DevOps流程，实现开发和运维一体化。

2.5.2　应用开发方面的应对措施

针对应用开发方面遇到的上述挑战，根本上是性能问题，但引起性能问题的根源却有多种。这是因为分布式架构下表数据被切分到多个数据节点，查询语句需要考虑语句如何拆分、分片之间数据如何移动、结果如何计算与合并的问题。下面分场景给出应对措施。

场景1：SQL兼容性问题。

GoldenDB完全兼容MySQL语法。但部分语句在分布式环境下执行代价过大，暂不放开这些执行代价过大的语句。解决方案如下。

通过产品迭代，完善执行效率、逐步放开代价过大的SQL语句功能。

场景2：SQL语句执行效率低。

由于数据切分到多个数据节点，查询操作涉及网络通信的交互次数和交换的数据量较多时，会造成SQL语句性能变慢。此时需要根据执行计划进行针对性优化。解决方案如下。

（1）产品通过迭代，给出更好的执行计划和查询性能。

（2）提供增强型EXPLAIN命令分析SQL语句从计算节点到数据节点完整的执行计划，原生MySQL的EXPLAIN命令仅可以查看数据节点自身的执行计划。

（3）增强型慢查询日志功能，可更详细地看到各个阶段耗时。

（4）针对不同的业务场景提供多种隔离级别，如果业务允许脏读，可使用UR隔离级别，提升性能。

（5）提供多种HINT语句，可以指定SQL语句到某个分片上执行。

场景3：由于锁冲突导致性能低下。

解决方案如下。

（1）增加数据节点锁冲突信息日志功能，记录所有锁冲突超过设定时间的记录。

（2）调整锁等待时间参数：根据最佳实践，将应用的查询超时时间设定为合适值（例如10 s），数据库的行锁等待时间调整为合适值（例如8s），减少由于行锁等待导致的查询超时概率；元数据锁等待时间调整为合适值（例如5s），减少长时间的DDL语句执行期间，查询语句由于元数据锁等待导致语句卡住较长时间的情况。

场景4：多分片不均匀问题。

分布不均匀问题主要是数据分布不均匀和数据访问不均匀。解决方案如下。

（1）使用数据重分布功能重新分布数据。

（2）引入技术分片键，例如，表中有字段A存储客户号，引入字段B，字段B初始存储的内容和字段A完全一致，字段B为分片键，若其中某个节点的客户号访问量较多或客户号存储较多，可将该节点的部分数据导出，修改字段B的内容，再重新导入，人为将数据分布均匀。

2.5.3　生产运维方面的应对措施

针对分布式数据库运维，应对措施的关键是要建立一套“监、管、控”的运维体系，以向智能化、数字化迈进。整个运维体系主要涉及监控、巡检、性能优化、应急处置、扩展性等问题，下面具体阐述。

1．监控

相较于集中式数据库，分布式数据库组件众多，通过单一种类的监控或使用现有的手段定位问题比较困难，需要一套或者多套监控体系配合来帮助运维人员精准确定位到故障节点。

GoldenDB数据库提供了一套心跳监控机制以及告警系统，在网络出现波动或者问题时能够第一时间发现并且上报。为满足实际运维需求，某商业银行采用了如下告警系统。

（1）通过IBM ITM监控工具对服务器上的进程、端口号、关键字等基础项进行了监控。

（2）通过NPM监控，对所有组件节点进行网络流量变化进行实时监控，并能够针对性抓包分析。

（3）通过交易监控系统，对业务响应率、业务成功率和交易耗时等进行监控，以便实时发现并定位分析。

（4）通过普罗米修斯软件，对各个组件的服务器资源（CPU、I/O、内存等），以及DB节点相关资源监控（主从状态、主从延迟、缓冲池命中率、写挂起等）进行实时监控。

（5）将分布式数据库各个节点产生的日志定期上传到日志中心，通过ELK平台对日志进行汇总和筛选，方便问题排查。

2．巡检

分布式数据库集群中各个模块均为多节点，模块间关联性较大，这就要求分布式数据库巡检工具按照以下要求设计。

（1）能够满足系统日常基本项巡检。例如，服务器资源型通用巡检CPU、I/O、内存、存储空间、内存交换空间、文件描述符使用情况等。

（2）能够满足各组件特性巡检。例如，对DB节点缓冲池命中率、表碎片化等数据库相关指标巡检；对DBProxy的连接数、消息积压等情况的巡检；对管理节点中各个管理进程的连接状态、集群切换状态等情况的巡检等。

（3）能够对各个组件的巡检进行判断和分类，进行巡检控制。例如，应该在DB上进行的巡检就不要在DBProxy上进行。

（4）能够对所有节点的巡检结果进行汇总收集，归类，将问题精确定位到节点IP、巡检内容、报错信息等，方便运维人员进行快速定位和查询。

分布式数据库的巡检，在一定程度上展示了分布式数据库运行情况的发展趋势，可以配合监控数据更早地定位出系统的潜在问题。

3．应急处置

分布式数据库涉及的组件多，不能依赖DBA手工应急，必须实现自动化应急，真正做到“预防为主，处置高效”。建议商业银行采用以下方案进行。

（1）编写分布式数据库应急手册。

（2）根据分布式数据库应急手册开发自动化应急脚本，以实现自动化应急功能。

4．性能分析和优化

分布式数据库出现性能问题，如整体性能偏低、交易出现波动等，需要及时发现问题，在此不再赘述，仅列举两个场景的例子。

场景1：慢查询问题。

解决方案：检查计算节点和数据节点慢查询日志，根据慢查询日志判断原因，例如SQL语句需要优化、磁盘繁忙等。

场景2：计算节点、数据节点出现资源使用高、响应慢等问题。

解决方案：根据分布式数据库应急手册处置，打印当前组件状态、内存信息、内部调度信息等，随后进行针对性优化。

5．扩展性

扩展性包括纵向扩展和横向扩展，纵向扩展通过增加机器硬件资源实现，横向扩展通过增加数据节点实现。通过横向扩展增加数据节点之后，数据需要进行重分布操作，操作期间会因数据传输导致磁盘繁忙。建议可以采用以下方案。

（1）重分布之前规划磁盘空间，确保空间足够。

（2）重分布变更需要在业务交易较少的时间段执行。

6．备份和恢复

分布式数据库数据节点多，对数据备份和恢复的要求很高，建议采用集中备份软件，例如NBU，进行多节点数据备份。

（1）为了不影响交易，建议在备机上备份。

（2）多节点同时备份，提升备份效率。

2.5.4　技术规范的制定和落实

当前阶段，各大商业银行都在逐渐引入分布式数据库，可谓如火如荼。为了推进分布式数据库研发和运维的标准化，中国人民银行发布了指导性的分布式数据库技术规范。

2020年11月26日，中国人民银行发布了三项金融行业标准：《分布式数据库技术金融应用规范——技术架构》（JR/T 0203—2020）、《分布式数据库技术金融应用规范——安全技术要求》（JR/T 0204—2020）、《分布式数据库技术金融应用规范——灾难恢复要求》（JR/T 0205—2020）。

《分布式数据库技术金融应用规范——技术架构》规定了在金融领域分布式事务数据库的架构要求，涵盖技术框架、功能特性和运维管理，旨在保障金融服务高可用、数据高可靠、弹性可扩展、产品高适配和数据易迁移。

《分布式数据库技术金融应用规范——安全技术要求》规定了在金融领域分布式事务数据库的安全要求，涵盖基础支撑保障、用户管理、访问控制、数据安全、监控预警、密钥管理、安全管理和安全审计等内容，旨在保障金融业务安全稳定运行。

《分布式数据库技术金融应用规范——灾难恢复要求》规定了在金融领域分布式事务数据库的灾难恢复要求，涵盖容灾能力分级、灾备技术要求和灾备管理流程，旨在引导金融机构建立健全容灾机制，保障金融业务连续性运行。

分布式数据库金融应用系列标准适用于金融领域分布式事务数据库的研发、测试、评估和应用，为分布式数据库金融应用标准体系夯实基础。

针对中国人民银行发布的上述技术规范，各大商业银行在分布式数据库的开发和运维中，需要抓紧落实并实践；也建议商业银行之间多开展技术规范方面的同业交流，通过交流提升运用分布式数据库的水平。