一、行业现状

随着互联网金融的兴起，商业银行不管从业务还是技术层面都面临着巨大的冲击，数据库作为银行重要的基础设施，一直承担着压舱石的角色。传统商业数据库依靠着稳定可靠的硬件被应用于数据大集中的环境中，这种现状一直持续到现在。随着数据量越发庞大、数据模型越发复杂、应用迭代速度加快、并发量的激增，传统商业数据库面临着前所未有的考验。在这种形势下，各大商业银行也在积极探索数据库的新技术，因此分布式成为新的发展方向。

在此背景下，分布式NEWSQL数据库得到了飞速的发展，产生了一系列数据库新技术新理念，包括分布式事务、分布式计算、分布式存储、云数据库等新思想。虽然传统数据库厂商也在探索相关的sharding（分片）技术，但这并不是彻底的分布式，真正彻底的分布式应该是具有数据独立性、应用透明性、逻辑整体性等鲜明特点的。分布式NEWSQL数据库专为应对高并发海量数据而生，该数据库一般具有以下特点：水平扩展、高可用、高吞吐量、高容错等。诞生了诸如OceanBase、TiDB、SequoiaDB、华为高思等优秀的分布式数据库，其中很多在支持实时交易的同时也支持实时分析，做到了真正的HTAP（Hybrid Transaction and Analytical Processing）。

因为分布式架构的原因，原本在单机数据库上很容易实现的事情变得尤为复杂，主要有以下几个难点：

• 如何做到SQL语法的百分之百兼容；
• 如何在分布式的环境下保证数据一致性、可用性；
• 如何保障数据库性能；
• 如何在CAP中进行取舍。

二、分布式数据库关键技术介绍

传统余数分布法 vs 一致性哈希

在线扩容是分布式数据库的一项巨大优点，而扩容数据节点必然涉及到数据向新节点的迁移，目前市面上的分布式数据库基本上都做到了自动的数据重分布。但是做到数据库自动重分布还不够，如何做到只迁移少部分数据以降低服务器IO压力成为关键问题。

传统的散列方式是根据分区键哈希值对分区数量进行取模操作，得到的结果就是数据应该落入的分区，但是这种分布方法在增加删除节点时会造成大量的数据重分布，而一致性哈希的核心思想是每个分区不再是对应一个数字，而是对应一个范围，对计算的散列值进行范围的匹配，大体思路是将数据节点和键的hash值都映射到0~2^32的圆环上，然后从映射值的位置开始顺时针查找，将数据保存到找到的第一个节点上。

如果超过2^32仍然找不到服务节点，就会保存到第一个节点上，如下图增加node5节点时，影响的其实只有node2到node5之间的数据。一致性哈希最大程度解决了数据库重分布问题，但是可能会造成节点数据分布不均匀的问题，当然针对这个问题还有一些改进，比如增加虚拟节点。

一致性协议paxos vs raft

保证事务在分布式架构下的一致性一直是分布式数据库研发的重点和难点，paxos和raft是目前主流的两种共识算法。Paxos诞生于学院派，是基于消息传递的共识算法，它设计之初是考虑一个通用的模型，并没有过多的考虑实际的应用，所以难以理解，这一点一直遭人诟病。因为paxos的难以理解，斯坦福的两名大学生设计了raft算法，相比来说，raft是工业派，实现起来也更加简单，因此在分布式环境上有着广泛的应用，例如TiDB、RadonDB、etcd、kubernetes等。

如果读过raft算法论文的话，就能发现raft算法将共识问题分解为三个子问题分别解决：leader选举、日志复制、安全性。Leader选举解决了领导者、追随者、候选者三种角色之间转换状态机的问题，反映在生产系统上即主节点宕机如何进行选主的问题；日志复制解决了主备之间同步的问题，leader接收到的指令序列需要保证传输到follower并且大部分follower提交成功后主机才能进行提交并返回结果给客户端，这个思想有点类似两阶段提交，它允许少部分节点的宕机或者网络不可达，相比传统的主备同步的最大保护模式风险更低；安全性指的是每台复制状态机都需要按照同样的顺序执行相同的指令，以保证每台服务器数据的一致性。至于具体的算法细节这里不再详细讨论。

三、民生银行分布式数据库测评模型

目前很多商业银行都开启了对NEWSQL数据库的探索测试工作，有些银行已经在生产系统正式上线。民生银行对这方面也一直在积极的探索，我们调研了市面上的主流分布式数据库，对它们各自的特点进行了分析比较，随着对分布式数据库特点的深入了解，我们总结了一套分布式数据库的测评模型。测评模型主要分为非技术场景和技术场景，既有测也有评。对于一些主观的非技术场景主要通过对产品进行调研形成一个主观的评判，对于一些通用的技术场景，我们对场景进行细化，对共性场景进行自动化，并且未来计划作为服务发布到数据库PAAS平台中，做到特定场景的自动化测评，并对测评结果进行打分，得到数据库产品的最终得分。下图是民生银行分布式数据库整体的测评体系模型：

非技术场景

非技术场景主要通过调研产品的发展现状、使用情况、社区生态、监控、周边配套工具及功能满足度等进行初步的评判和打分，是偏主观的场景。各场景的分值分配情况如下图所示：

银行对于一套新技术新系统的使用和上线都是抱着十分谨慎的态度，成熟度是主观衡量产品的重要指标，互联网应用案例特别是大型商业银行应用案例对于决策者进行决策有着指导意义，此外产品出现时长、是否经过长时间的考验等方面也是评判产品成熟度的指标。活跃度主要通过调研产品的社区生态、是否有大量的contributor维护代码、国内是否有成熟的公司进行产品的代理或维护、产品的迭代速度、bug修复速度等方面进行评估打分。监控方面主要是产品是否有完善的监控体系、监控界面是否直观方便、监控项是否齐全等。此外周边工具对于数据库的可运维性有着重要意义，包括但不限于：详细的运维文档、数据导入导出工具、备份恢复工具、集群管控平台、数据库实时备份/同步工具等。

技术场景

技术场景主要通过运用技术手段对产品进行测评，通过对测试项进行细化，为每个测试项设计测试场景和案例，采用工具或命令来自动化或半自动化的完成测评。同时还可以将一些能够自动化的场景集成到数据库PAAS平台中，发布成服务来供其他人使用。技术场景主要包括六大模块：SQL兼容性、性能测试、高可用测试、在线扩容、分布式事务、隔离级别，其中大部分模块可以实现自动化。各场景的分值分配情况如下图所示：

数据库经历了从SQL到NOSQL再到NEWSQL的发展历程，发展到后来才发现数据库离不开SQL，SQL语言极大地方便了数据的查询和修改，因此虽然有些高级的功能支持起来难度较大，但是各种分布式数据库都非常重视对SQL语法协议的支持。我们参考SQL92标准总结了一套完善的SQL语法测试案例，并进行了标准化和自动化的实现：包括数据类型测试（数值、日期、字符、枚举、集合、JSON等）、数据库管理语法测试、数据表管理语法测试、事务相关语法测试、执行计划相关语法测试以及一些高级特性测试，包括存储过程、触发器、视图、自定义函数、外键等。这些案例的测试结果基本能够反映分布式数据库产品对SQL语法的支持力度。

数据库在分布式集群的架构下性能可能受到较大的影响：包括执行计划的下发、分布式事务的两阶段提交、集群的调度、节点间的通信、网卡带宽、磁盘性能等都会使数据库性能大打折扣。一个事务提交在分布式的环境下需要大多数节点进行协调，这是缺点，但分布式执行计划下发后可以在多台节点上并行执行，这又是优点。所以对分布式数据库性能的测试尤为重要，性能高低也更能反映产品设计的优劣。性能测试基本都能做到自动化，主要分为四个方面：基本SQL性能测试、TPCC基准性能测试、TPCC复杂SQL性能测试、转账场景性能测试。为了做到多种数据库的兼容，我们在结合一些开源的性能测试工具（sysbench、benchyou等）的同时也自研了压力测试工具，该工具支持多种数据库、可以自定义并发数、表数以及增删改查的比例等，最后对TPS进行记录，观察数据库的压力峰值拐点，对数据库入侵小。同时我们使用业界广泛使用的联机交易系统测试模型TPCC进行数据库性能测试，根据流量tpmC、交易响应时间等指标来进行评分，我们还会根据复杂SQL的执行时间等进行评分。除了这些，我们还会针对金融行业的典型场景如转账场景进行性能测试。

分布式数据库的在线扩容是必不可少的功能，可扩展性是分布式数据库设计的目标，也是应对海量数据的利器。扩容主要指数据节点的扩容，因为不同数据库扩容方法不一，通过评估这些节点扩容是否简易、观察扩容过程中IO负载情况、交易影响情况等对该项进行评定。

高可用测试用于评判数据库是否具备金融级安全性，通过模拟一系列不可靠场景，测试数据库在硬件、操作系统、数据库等层面在异常场景下的应对能力。硬件层面异常主要包括服务器宕机、磁盘故障、网卡故障等；操作系统层面异常主要包括CPU利用率高、内存利用率高、容量异常、文件系统不可用、突发流量等；数据库层面异常主要包括数据文件损坏、数据库进程宕机、数据文件只读等。

银行账务交易对事务差错的零容忍使得分布式数据库对事务的支持尤为重要，不支持分布式事务的分布式数据库是伪分布式。jepsen工具是业界使用最广泛的分布式系统测试工具，ZooKeeper、MongoDB、Redis等都被它找出了bug，它是clojure语言编写的，使用难度较大，于是一些程序员使用go语言进行重写和改造，开发了go-jepsen工具。go-jepsen会测试在分布式环境下进行多线程更新后数据是否一致，使用该工具进行测试时还需要随机模拟一些异常场景，检测事务是否统一提交或统一回滚。金融行业最常见的场景是转账交易，因此在测试模型中，我们单独设计了转账交易场景，同时在测试过程中结合异常情况，通过对最终账户的交易余额进行比对，来评价该分布式数据库在保障数据一致性方面的能力如何。除了以上这些我们还会测试数据库对几种隔离级别的支持情况，来评价该分布式数据库在处理事务隔离性方面的能力如何。

总结

NEWSQL数据库的发展虽然经过了一定时间的检验，但银行业在使用分布式数据库时仍需谨慎，探索的过程还很漫长。现在已经有一些分布式数据库在银行交易场景中使用的案例，也相信未来银行业使用分布式数据库的优秀案例还会不断增多，我们会始终抱着开放、审慎的态度继续在这条路上不断地摸索前行。

参考文献

Diego Ongaro，John Ousterhout：《In Search of an Understandable Consensus Algorithm》
什么是一致性哈希？-简书：https://www.jianshu.com/p/49e3fbf41b9b
TPCC模型：http://www.tpc.org/tpcc/
Jepsen：distributed systems safety analysis：http://jepsen.io

作者简介：

朱彬
多年数据库的运维管理经验，目前正带领民生银行数据库团队，完成从传统数据库向开源、分布式数据库领域的转型。

张小海
毕业于北京邮电大学计算机系，具有四年金融从业经验，2018年4月加入民生银行信息科技部数据库团队，目前致力于oracle及开源数据库
的研究。

转自微信公众号：民生运维