行业背景
1、银行业为什么需要采用分布式数据库？
背景及现状：
在传统数据大集中的环境下，银行核心系统很容易发生故障，而且一旦发生故障，影响面将特别广，带来很大的舆论压力和监管压力，历史上大型商业银行核心系统故障的例子不在少数。而且传统的集中式架构不易扩展，各模块间高度耦合，最终造成核心系统体量太过庞大、业务太过繁重。
分布式数据库优势：
企业采用分布式数据库，我觉得有多方面原因：
① 传统的数据库是否已经难以承受当前的负载
② 是否需要规避全局风险
分布式数据库天然可扩展的架构正好解决了上述问题。分布式数据库项目既可以避免将鸡蛋放在一个篮子里，又可以水平扩展，提高吞吐量。但是目前分布式数据库总体还不是很成熟，因此需要全面的评估测试后才能决定。
2、如何评估银行分布式数据库项目的整体成本？
成本可以分为开发测试成本、数据库的软硬件成本、运营维护成本等。开发测试成本主要是开发该项目的人力成本，这个因项目而异。分布式数据库的硬件成本主要包括PC服务器加本地SSD盘，软件成本因厂商而异。大致如下：
3、银行行业中用分布式数据库的多吗？现在是什么形势？
目前银行业对分布式数据的使用还是持一个比较谨慎的态度，但是各大银行都在进行分布式数据库的探索，包括选型测试等。目前有些银行已经在核心系统上线了开源的分布式数据库，其他还有些银行在和一些企业进行联合创新研发，我行目前也在积极探索中。
4、在银行业中，分布式数据库的供应商有哪些？
目前市面上分布式数据库产品很多，比较流行的主要有pingcap的tidb，巨杉的sequoiaDB，阿里的OceanBase、polardb，腾讯的Tbase、tdsql，华为的gaussdb，亚信的antdb等。各个产品大致特点如下：
方案设计
5、在分布式数据库项目中，如何进行技术路线的选择？
分布式一般分为三条技术路线：分布式访问客户端、分布式中间件模式、分布式数据库模式。其中分布式访问客户端对应用侵入性大，改造难度很高；分布式中间件则类似mycat等产品，在数据库和应用间架一层proxy，这种方案无法支持分布式事务、也无法支持跨库关联，分布式数据库方案则将分库分表等中间件实现的功能下推到数据库层面来做，对应用透明，应用就像使用单机数据库来使用分布式数据库，同时天然地支持分布式事务。
6、如何进行分布式数据库项目的系统方案设计？有哪些具体的设计内容？
系统方案主要包括：
①如何进行服务器选型：
一般分布式数据库都会采用廉价x86 pc服务器，搭配本地ssd固态盘、万兆网卡，硬件成本较低。
②软件规划和部署方案：
分布式数据库组件众多，而且每个组件都有高可用备份，所以在有限数量的服务器下进行组件的分配要尽量考虑达到各个服务器负载的均衡，gtm作为分布式数据库的瓶颈尽量和他们组件分开部署。
③监控方案：
监控一般可以采用开源的zabbix进行定制化开发，当然也可以基于grafana+prometheus的方案做监控。
④如何进行调优：
因为不同厂商研发的数据库sql优化器及执行计划都有所不同，所以要根据不同产品进行学习。
⑤备份方案：
分布式数据库如何做一致性备份也是研发难点，要做到真正意义上的pitr就需要做到分布式环境下每个全局事务的“barrier”操作。
⑥应急方案：
因为分布式数据库还处于发展阶段，还不成熟，技术比较复杂，所以生产环境下要制定详细的应急方案，让不了解分布式数据库的同事也能够在出现问题时按照手册操作。
7、在分布式数据库项目中，为进行系统规格设计，如何进行定量需求分析？需要收集哪些需求数据信息？
主要考虑以下几个方面：
①系统的最大并发数：
为了节省成本，多套小系统可以共用一套数据库，但是负载很大的高并发场景还是独立搭建。
②系统的最大数据量：
多租户系统下需要考虑各个系统的数据量之和。
③系统最大可容忍的业务中断时间：
分布式数据库节点宕机并不是对业务没有任何影响，主节点宕机都涉及到一个切换的问题，切换就是影响业务的时间，要充分评估业务能否忍受这么长时间的中断。
④系统的迁移成本：
分布式数据库不可能做到oracle、db2、mysql所有数据库的百分之百兼容，所以不同类型的数据库在迁移上都会或多或少的涉及到应用的改造。
8、如何解决分布式数据库项目中的某个难点问题？
我觉得分布式数据库主要有以下几个难点：
①分布式事务：分布式事务的实时一致性是分布式数据库研发的难点，cap理论中分区容错性是一定要保证的，那么在c和a中我相信对于银行用户应该会牺牲可用性来保证一致性。
②性能：为了保证事务全局一致，分布式数据库都需要一个全局事务管理器gtm，用于分配全局事务id，任何一个事务开启都需要先去gtm申请事务号，这样gtm就会成为分布式数据库的性能瓶颈，厂商所宣称的性能和机器数量成正比就要打个问号了。
③备份恢复：如何进行全局一致性备份，如何支持全局的前滚恢复。
④高可用：分布式数据库宕掉节点或多或少的都会造成数据库hang一段时间，对标成熟的互联网主备架构的切换时间，这个还需要优化。
9、在分布式数据库项目中，什么模块如何进行设计？
分布式数据库一般包括如下几个重要模块：
① 访问层：也叫SQL转发层。这一层定位在SQL执行计划的生成和下发，多个访问层节点理想情况下要进行无状态设计，使用负载均衡技术统一对外提供服务；负责数据的排序、归并等集合操作；负责分布式事务的控制。
② 数据层：数据经过分片后存储在不同的数据节点上，数据节点根据协调节点的请求进行读写数据文件，对数据进行节点内的预处理，同时通常具有一主多从的多副本数据复制能力。
③ 全局事务管理器：处理全局事务，为各协调节点生成唯一的全局事务编号和全局序列号。因为是分布式数据库的瓶颈，为了减小gtm的网络交互，可以设计为事务id批量分配，一次分配一段事务号。同时也可以将事务号存储在分布式存储中，比如etcd，这样能避免一些性能和高可用问题。
10、分布式数据库上线后，如何对运维工作进行管理安排？
分布式数据库类的运维工作主要包括如下几类：
① 准备常用运维脚本、应急手册、运维手册等。
② 做好监控，通常要与监控工具进行对接和整合。
③ 做好相关技术手册培训。
④ 做好生产演练，如定期的重启、切换等。