银行分布式数据库建设路径探讨？

银行传统数据库在应对互联网金融场景时遇到了明显瓶颈，在面临交易复杂度和交易频率的大幅提升时，传统数据库能够采取的优化方案非常有限，若仅依靠软硬件升级来提升性能的话，成本非常昂贵。另外，在应对双十一这类特殊交易日时，需要在短期内提升数据库的能力，传统数据库缺乏这方面的灵活性。若仅仅为了应对有限特殊日的流量，而配置很高的性能，又会造成资源的极大浪费。基于能力、可控、弹性、成本等方面的考虑，引入具有高可用、高性能、高可扩展性的分布式数据库成为优先选择方案。
分布式数据库设计阶段需要考虑很多方面，比较重要的像是高可用方案、存储方案、灾备方案、安全、监控、运维等，这些在前期都要规划好。还有一点很重要，分布式数据库最终是为应用服务的，要充分考虑应用从传统数据库迁移至分布式数据库的难度，尤其在测试阶段，要充分考量分布式数据库的兼容性。
在分布式数据库选型时，最好结合具体的应用场景，如OLTP和OLAP。另外，数据库厂商的技术服务支持能力和案例成熟度也要充分考虑。
以上是本人的一些小经验，供大家讨论。

关于诉求和为什么一定要上分布式数据库，不想多说，因为这些问题是仁者见仁智者见智的问题，近期我们做了一些分布式数据库的验证测试工作，其中还是碰到很多问题的，通过测试，发现分布式基础问题21个，分布式和ORACLE兼容性问题28个，分布式和应用兼容性问题2个，分布式性能问题8个，以上问题都的到了厂商的确认，并进行了底层的修复。发现以上问题，都是通过大量的业务测试、场景测试和压力测试发现的，并进行了分析提交BUG修复。因此所谓的坑不是能避免的，而是要通过大量的测试去发现BUG，解决BUG，才能避免上了生产后踩坑。

目前我们通过认真讨论，也制定了大量异常场景进行破坏性测试，例如硬件问题场景、网络问题场景、业务问题场景（异常SQL）及极端场景进行了测试，通过以上大量的测试，技术人员自行编制了健康检查和健康巡检方案、慢查询SQL优化指南、分布式数据库异常问题解决案例手册、各异常场景测试报告及处理方案及总体测试报告等文档。

所以我们认为一个好的数据库是用时间、应用场景磨合出来的，只是我们在走之前ORACLE、DB2已经走过的磨合道路罢了。

核心诉求我觉得有以下几个：
1）一些数据库越来越大，访问量越来越高，单机已经无法承载，或者纵向扩容的成本太高，这时候就需要通过支持横向扩展、支持廉价x86服务器的分布式数据库技术来解决
2）现在很多行都开始微服务以及数据中台的建设，如果采用传统数据库技术，数据库实例的数目将会非常恐怖，DBA的运维工作将会受到极大挑战，解决这个问题我们就需要一个既能很方便的弹性伸缩，又能资源隔离（多租户）的数据库来存储数据，很多分布式数据库都提供了这样的能力

市面上的分布式数据库技术分为两个流派：
1）采用中间件的分库分表方案，比如使用mycat
2）原生分布式数据库，比如国产的有tidb、oceanbase、巨杉数据库等等

分库分表方案在市面上使用很多，尤其在互联网。这种方案的优势是底层采用成熟的传统数据库，所以数据库层面比较稳定，缺点是对应用的侵入性比较强、限制比较多，同时运维非常不方便。

而原生分布式数据库对应用非常友好，在应用看来就是一个单库，无需关心分布式事务、数据存储在哪个节点等一系列问题，同时运维也非常方便，一个DBA可以轻松管理100多台机器构成的集群。因此它的诞生其中一个目标就是替代分库分表方案，而且全球技术评级机构像Gartner、Forrester都从来不会把分库分表方案放到他们的评估列表中。原生分布式数据库同时还提供了良好的弹性伸缩容能力、高可用甚至容灾能力，这也是业界对其比较看好的重要原因。当然目前原生分布式数据库的缺点也很明显：
1）太年轻，与传统数据库相比无论从稳定性（主要指性能，发生bug的概率）和功能性上来说都有一定差距
2）对存储过程、外键、触发器等特性基本不支持

需要避免的坑，我想到的主要有：
1）如果应用大量使用oracle PL/SQL存储过程，迁移会很痛苦，个人不太建议拿这些系统做试点
2）分布式数据库一般都采用两阶段提交，因此效率上会不如单机数据库事务，为了提升两阶段提交的性能，有些数据库会采用乐观锁，乐观锁会出现一些跟悲观锁不一样的行为，因此应用逻辑可能需要调整来适应
3）在分布式数据库上跑中间结果集很大但最终结果集很小的查询效率可能不太好，主要是跨节点传输大量数据导致耗时较长，而传统数据库顶多就是从磁盘到内存这个过程，没有网络IO
4）分布式数据库和传统数据库之间如何做容灾的问题，比如分布式数据库作为主库上线运行了，但是我们担心它会出问题，想利用传统数据库做备库，两者之前的数据同步如何进行，这目前也是我们想要解决的事情

现在所有的大行都在实践分布式数据库。
分布式主要解决两个问题。一是性能扩展，弹性伸缩。单机数据库的处理能力是有上限的，尤其是纵向扩展有极限，也不能解决单库的瓶颈。分布式数据库的横向扩展几乎是唯一的解决途径。二是高可用性，单节点的异常不会导致整个集群的损坏，不会影响全局。异常节点的数据和任务能动态漂移，恢复时间短。
然而分布式数据库也存在很多挑战，并不是那么容易实现。分库分表对应用是否透明? 如果从应用角度就开始分，合理开发应用，对于性能来说是最好的方式，但是需要很高的设计开发成本。 如果对应用透明，完全由数据库来做，那么性能可能会成为问题，因为应用会存在夸库事务，存在两阶段提交等。 分布式事务是否支持? 我们会看到接触的大多数分布式产品都支持，然而性能呢，都是问题。在测试的很多分布式数据库，都存在gtm这样的设计，用来协调数据库节点的事务。测试过程中，性能的瓶颈也基本出在这个核心功能上。
因此在上分布式数据库的时候，一定要关注这些点。挑选合适自己的数据库。从性能，高可用，管理性等方面全面评审才行。

一、分布式数据库能解决什么问题？
首先，分布式数据库主要用于解决单机存储上限的问题。如今每天产生各类的数据量非常巨大，如果使用传统方案，要么不便于管理，要么成本过大。
其次分布式数据库可以一定程度分散单节点数据库压力，如读写分离、多节点并行运算等。
最后，某些分布式数据库有多数据中心方案，可以以较低的成本实现数据库层面的多活方案
二、银行在分布式数据库有什么核心诉求？
主要还是看用在什么业务场景,不同的分布式数据库有不通的优缺点和适用场景,这里只讨论厂商原生的分布式数据库。比如有的需要强事务可以考虑tidb，大量的写可以考虑hbase/cassandra，结构常变快速迭代可以考虑mongodb，搜索为主可以考虑es/solr，大量数据缓存可以考虑redis(cluster)等
三、为什么一定要上分布式数据库？
大多数情况是因为单机无法满足存储或性能要求，参考第一问
四、有没有其他的技术路线可以满足需求
公司研发团队自行编写中间件，可以满足需求，只是对研发能力要求较高，需要考虑到各类所需的场景。目前有不少大型互联网公司有采用此方案。
五、如果上分布式数据库，需要避免哪些坑？
1、出于稳定性考虑，最好用官方原始的分布式方案，谨慎选择使用第三方中间件。
2、因为分布式技术要求较高，建议有专人或者供应商进行维护。
3、使用主流的且经过时间考验的分布式方案，某些厂商为了分布式而分布式反而有不少问题。
4、对研发进行相关使用培训，否则性能损耗明显。
5、分布式架构时，某些特性会不支持，需要提前调研。
6、分布式场景下一致性的备份是个难点，不同数据库有不同解决方案。
7、重要数据各分片节点至少有2份或以上冗余，避免数据丢失

一、 采用分布式系统架构是由于业务需求决定的，若系统要求具备如下特性，便可考虑采用分布式架构来实现：

1. 数据存储的分区容错，冗余
2. 应用的大访问、高性能要求
3. 应用的高可用要求，故障转移

二、 分布式系统遵循几个基本原则

1、CAP 原理

CAP Theorem ， CAP 原理中，有三个要素：

一致性 (Consistency)
可用性 (Availability)
分区容忍性 (Partition tolerance)

     CAP 原理指的是，在分布式系统中这三个要素最多只能同时实现两点，不可能三者兼顾。因此在进行分布式架构设计时，必须做出取舍。而对于分布式数据系统，分区容忍性是基本要求，否则就失去了价值。因此设计分布式数据系统，就是在一致性和可用性之间取一个平衡。对于大多数 web 应用，其实并不需要强一致性，因此牺牲一致性而 换取高可用性，是目前多数分布式数据库产品的方向。
    从客户端角度，多进程并发访问时，更新过的数据在不同进程如何获取的不同策略，决定了不同的一致性。对于关系型数据库，要求更新过的数据能被后续的访问都能看到，这是强一致性。如果能容忍后续的部分或者全部访问不到，则是弱一致性。如果经过一段时间后要求能访问到更新后的数据，则是最终一致性。
     但 web 应用也有例外，比如支付宝系统，就要求数据（银行账户）的强一致性，而且面对大量淘宝用户，可用性要求很高，因此只能牺牲数据的分区冗余。这一点也曾在和支付宝工程师交流时，得到验证。

2.C10K 问题

     分布式系统另一个理论是 C10K 问题，即系统的并发用户增加 1 万（ customer ten thousand ，过去一台服务器承载， 假设为 1 万用户，现在平均 3 ～ 5 万），是否意味着增加一台机器就能解决问题？答案通常是否定。
    因为这涉及到系统的应用架构问题 ---- 串行系统和并行系统的架构和性能提升的关系：
    串行系统一般设备越多，性能成一条向下弯曲的曲线，最差情况，可能性能不增反降；而并行分布式系统设备越多，性能是正比例线性增长的直线 3. 串行系统和并行系统的可靠性问题。
    一个大系统一般都有超过 30 个环节（串行）：如果每个环节都做到 99% 的准确率，最终系统的准确率是 74%; 如果每个环节都做到 98% 的准确率，最终系统的准确率 54% 。一个 74% 的系统是可用的（有商业价值的），一个54% 的系统仅比随机稍好一点，不可用。这就是做大系统的魅力和挑战！

     而以上描述只是各模块串行系统所遇到的问题，如果是并行系统，准确率 =1-(1-A)^B ，其中 A 是单个模块准确率， B 是并行模块个数。
    如系统中每个模块的准确率是 70% ，那么 3 个模块并行，整体准确率 =1-0.3^3=97.3%, 如果是 4 个并行，准确率 =1-0.3^4=99.19%, 我在想这就是负载均衡靠谱的数学原理。5 个 9 或 6 个 9 的 QoS 一定是指数思维的结果，线性思维等于送死。
     而对系统单一模块优化，准确性和可用性提升一个百分点，越接近 100% ，难度越大，投入成本越不可控（系统熵永不为零），因此可靠性系统必然选择并行分布式作为架构的基本方法。

现在我们行领导听到非常多人来沟通说分布式数据库如何好如何有价值，那银行在分布式数据库的核心诉求是什么？

回答：行里有安全可控的技术创新压力；也有业务转型的业务创新压力和合理控制试错成本。

为什么一定要上分布式数据库？

回答：创新就一定要控制试错的成本，及取得更大的行业影响力，要跟上时代的主流，避免技术路线上落后。

有没有其他的技术路线可以满足需求？

回答：不差钱的话，直接上IOE设备，实在不行就上AS400 或S390 ，

如果上分布式数据库，需要避免哪些坑？

回答：

（1）关键选对产品，选对厂商。产品一定要有生态链、行业应用案例和主流成熟的技术；厂商一定要专注做数据库产品研发和做到满足行里随叫随到的服务体验。

（2） 分布式事务数据库产品必须满足业务需求 和运维需求，例如：死锁、实时一致分布式事务、智能死锁检测、智能死锁解除、响应时间损耗足够小（包含网络时延控制在５％及以内）、吞吐量足够大（至少百万级QPS）、运维复杂度经过产品化后达到单机一样及以内的容易程度等。例如：OceaBase、热璞数据库HotDB、腾讯TDSQL。

1 为什么一定要上分布式数据库？
业务量大了，必须要分库分表。

2 有没有其他的技术路线可以满足需求？
if you know, pls tell me

3 如果上分布式数据库，需要避免哪些坑？
如何分库分表要根据自己业务、技术能力来做。 x轴拆分（水平复制数据库）、y轴拆分（按功能分）、z抽拆分（按用户分）。

在当前技术高速发展的背景下，用户选择分布式平台或任何平台方案时应该慎重！因此需要从多个维度对市场上众多的商业和开源产品进行全方位的评估。大致应包括功能、性能、高可用性、可扩展性、开放性、数据加载速度、跨云平台能力、与第三方工具的集成能力、监控管理特性、总体成本等因素。或根据自身需要选择 按 x 轴拆分（水平复制数据库） 按 y 轴拆分（按列功能分） 按用户分类参考选择 ，在分布式系统中，现有市场上有专业大厂提供的多种产品。大致如下：

IBM DB2 DPF
POSTGRESQL citus，greenplum
couchdb
HABSE
MONGODB
redis等
分布式系统产品 国内也有众多厂商如巨杉数据库等各有特点。

从技术角度看，选择分布数据库时，应该着眼于大数据分析和后继的 AI 处理等。因此建议参考以下因素：

1. 产品成熟度：成熟的产品可以避免用户走弯路。
2. 开发和运维的复杂度。
3. 标准兼容度。
4. 核心技术的特性（ SQL,NOSQL,NEWSQL) 。
5. 硬件跨平台。
6. 是否开放源代码。
7. 完善生态系统。
8. 数据源和数据格式是否支持常见关系数据库和半结构化的数据，以及非结构化数据库（文本， GIS 数据和图数据）。
9. 是否支持跨数据库链接构建联邦数据库 -- 便于跨数据库的数据抽取或数据虚拟化 -- 对用户屏蔽底层的数据读取细节，提供统一的管理和访问接口，无论外部数据存放在本地， S3 ，或某个 FTP 服务器上，还是存放在某个独立自治的数据库上，用户在使用时均不会感受到区别。
10. 高级分析能力：常见我们选择分布数据的后续应该有高级数据分析或者机器学习的需求，则应该考虑选择的数据库是否有内建的高级数据分析和机器学习能力的平台。而不时抽取数据库到业务应用或者第三方应用再做分析，可以大大简化业务的架构复杂度，提高开发效率，同时提高分析模型精度。
11. 与 ETL 等第三方工具的结合度。
12. 扩展能力。
13. 存储方式 SHARE everything 的共享存储还是 share nothing （一般分布式数据库偏向于后者便于水平扩展）支持多态存储。
14. 数据的压缩效果和支持可靠的 RUDP 通讯协议实现可靠的通讯流控和防阻塞通讯机制。对于分布数据库，因为业务的场景改变难免需要数据的重播 redistribute moving(redistribute motion) 或重放 broadcast moving or broadcast motion ，这块有时是分布式数据库最大也是容易失控的关键最短的部分。（本人以前选择一个数据库构建分布式环境，因为压缩和通讯机制额短板，造成过数据大数据量传输时，系统负载过大但又不能调优的尴尬经历）。
15. 是否提供细腻化弹性的系统资源的管理，对系统资源的管控调度，避免一些程序长时间不合理、不讲理的占用，以确保资源池或资源组 (CPU, 内存的共享）避免资源并行壁垒。
16. 是否提供 MPP 架构高效的并行加载数据，即允许数据从多个文件系统提供多个主机上的多个网卡进行加载，从而达到非常高的数据传输率。

对与分布式数据库的选择，就分布数据库集成数据库是一大亮点或特色。

通常不同的业务场景使用不同的数据库处理技术，如 OLTP 、联机分析 OLAP 处理、文本处理、流数据处理、科学计算等都具有不同的特点，

就当前的众多需求和硬件软件技术发展来看，集成数据库（ OLTP+OLAP 和其他文本、 GIS 、流数据）平台满足很多市场的需求和场景。

集成数据库的优势：

1. 数据整合容易，避免信息孤岛，便于共享和统一数据管理。
2. 基于 SQLDE1 数据集成平台可提供良好的数据独立性，开发专注逻辑，不用关心数据底层细节，平台能提供更好的实时性和更安全的数据，为业务提供更安全更准确的分析和决策。
3. 避免各种系统之间的耦合，总体技术架构简单，不需要复杂的数据导入和导出，易于管理和维护。

看了上面说的很多，其实讲到底，还是场景问题，核心诉求是满足压力其次考虑现在的瓶颈问题，或者将来可能遇到的瓶颈问题，此外没有说一点要上分布式数据库的说法，这个还是看你们的大致的规划和相应的投入，然后就是分布式讲究的AP/TP 分离或者混合部署，当然混合的往往的来自于业务的耦合情况，根据分布式的基本整体架构，目前的趋势是 计算、存储、调度，各个厂商都有各自的产品，需要进行对应的POC测试，只要经过POC测试才能准确的知道哪些坑，不能一概而论。