1、关于金融级分布式事务技术路线
银行核心业务系统最主要的技术特征就是数据一致性，对于分布式数据库而言，就是分布式事务一致性，在成熟分布式数据库产品出品之前，如何设计和实现分布式事务一致性，各家银行采用了许多不同的策略，从而产生了多个不同技术路线和技术流派，例如分布式柔性事务、分布式强一致性事务等等。
各位专家、各位同仁对自己了解的不同分布式事务一致性技术路线谈谈看法？深入讨论一下。（问题来自@周光明 People's Bank of China 软件架构设计师）
@孔再华 中国民生银行 数据库运维工程师：
对于金融级的分布式事务要求，其实算是比较明确的。首先是强一致性，这个是和互联网行业不一样的地方，也是分布式数据库的基本要求。
现在不建议金融行业继续掺和自研数据库的事情，因为市场上已经很多分布式数据库产品和案例了。所以现在银行有两种。一种是自己已经推出了分布式案例的，会在自己的选型基础上继续扩展。一种是尚未使用分布式的，会挑选国内的分布式数据库来部署。
那么现在主要谈谈这个第二种。分布式数据库该怎么选型？银行会在保证全局ACID的前提下，也就是强一致性前提下挑选分布式数据库产品。分布式事务的一致性现在已经不需要银行来设计保证了，数据库产品就已经涵盖这个能力。不过每个数据库在这点使用的技术确实不一样，有依赖生成全局事务号的，也有基于全局时钟的，可能还用很多其他全局的组件和服务。这些设计会影响事务的性能，因此需要详细测试才能比较出来。不过我个人认为这个是基础，挑选分布式数据库还有其他很多方面需要考虑。
@wanglaye 某大型金融机构 项目经理：
传统关系型数据库和分布式数据库所提到的“一致性”，个人觉得并不完全等同。分布式数据库一致性包含数据一致性、事务一致性两个维度。
分布式数据库的一致性，分为强一致性、弱一致性、最终一致性。属于哪个一致性等级，与数据库多副本状态下的读写成功所需的最小化副本数有关。银行账户类系统选择强一致性最为保险，互联网公司可能会倾向于选择最终一致性。
2、选择分布式数据库的担忧？
一直担心分布式数据库的原因如下【简单说几点】：
1、采用分布式数据库，解决了数据分布式存储，则数据的一致性如何保证？若是实时交易性系统，数据并发写访问量大的情况下，依然会出现性能瓶颈【没有办法或者很难将访问关系进行拆分】，故写数据大量集中，而数据要同步到其它存储上，会存在一定的时间延迟。若这是进行大量的读访问【此时可采用分布式】，会存在已存在的数据未同步完成，不能有效访问。故分布式数据库的应用场景在银行中是交易性型系统还是管理型系统？还是分析型系统？案例较少，故一致未确定采用。
2、采用分布式数据库后，系统架构变得较为复杂。首先是设备数量增多，其次数据拆分规则难以确定【技术与业务人员的口径难以得到统一】。还有分布式数据库第三方的技术支持困难。最后是目前市场上分布式数据库没有一个大家公认的领头羊。（问题来自@lyq6666 重庆农村商业银行 IT顾问）
@孔再华 中国民生银行 数据库运维工程师：
数据库的一致性一定是要强一致性保证的，金融行业的数据库这是必须的要求。分布式数据库的全局一致性一般通过两阶段提交的方式来实现，基本上就是要求全局一致的提交和回滚。如果有异常发生，数据库内部可以查到全局事务的残留，处理之后也能最终达到一致性。
分布式数据库的性能问题是个很重要的点。大家都知道分布式是为了解决单点的性能才被提出来的。但是他仅仅是为了解决单点的集中式高并发需求，而不是为了复杂查询或者是大查询。因此使用分布式数据库一定要把握好他的应用场景。实时交易系统这种写并发大的情况其实也适合分布式，前提是他们的写是能基于分布式进行分片，能把写操作分散到各自的分片上去完成。读也是一样。分布式不适合的场景就是复杂的关联查询，大量的分布式事务等场景。分布式适合交易型系统，不适合管理类分析类。
分布式最大的痛点就是怎么分片，数据拆分这个是不可避免需要花最大力气的地方。因为这个前提，这里控制不好，后面擦屁股的活儿根本干不完。目前没有领头羊，押注吧。
@wanglaye 某大型金融机构 项目经理：
1、一致性，分为强一致性、弱一致性、最终一致性。属于哪个一致性等级，与数据库多副本状态下的读写成功所需的最小化副本数有关。最常用的一致性协议有paxos、raft。
若采用强一致性，则又分为两种情况：读写分离、读写不分离。读写分离情况下，无论读或写都需要大多数副本成功才认为读写成功；读写不分离情况下，写需要大多数副本写成功才返回成功，读只能读主副本，也能保证读到的数据是最新的。
写并发高的情况，通过合理策略进行数据分片（甚至二次分片），把数据打散，避免热点盘。在主机配置和网络带宽有限的情况下，写数据量大到一定程度是无法避免性能瓶颈的，事先可以通过分片避免热点盘，事中可以扩容。所以一般建议根据应用系统的交易量来规划设计数据库，可以一定程度上避免高并发写带来瓶颈。
读并发高的情况，还是选择强一致性的数据库吧。
交易类系统我们选用的是高性能事务型分布式数据库。分析类系统对实时事务处理要求不高，会选择HBase这类建数仓。管理类系统，得看是哪类，如果是实时监控类的管理系统对性能要求高可以上，其他的管理系统为了节约成本可以选择普通数据库。
2、系统架构并没有很复杂，反而更利于运维管理，一般分布式数据库都有管理节点和计算节点，对于管理员来说维护复杂度反而下降了，不用每个业务系统维护一套了。
数据分片时，业务和技术听谁的，这个难以回答，每家企业有自己的做事策略。
领头羊当然是有的。
3、从应用和所需处理的数据角度，对银行的各种应用场景进行归类，哪类场景适合用哪类数据库？选型时要注意哪些关键特性？
（问题来自@fanyqing 厦门银行 系统架构师）
@wanglaye 某大型金融机构 项目经理：
对银行的各种应用场景进行归类，考虑从两个维度归类：
（1） 交易型or分析型：可以将银行的业务非常粗略地分为交易型场景、分析型场景。网银、手机银行等属于交易类，数据平台、报表系统属于分析类。
（2）交易规模大or小：并发量大的业务系统使用分布式数据库，并发量小的系统使用传统数据库（当然也可以使用分布式数据库，看贵行意愿）。
@Amygo 分布式事务数据库管理员：
（1）业务类型建议：分布式事务数据库适合实时关系交易型、业务峰值较大和并发较大的业务场景，从银行考核的角度推荐B类、C类先试点，再考虑A类和核心系统。
（2）具体的业务场景：以互联网核心中的网联系统、积分系统、理财产品、网贷系统等为主。
（3）选型关键特性：
A 、数据一致要求：支持高性能、透明、实时一致的分布式事务算法，保证事务实时全部提交或全部回滚，严格保障数据的一致性；支持事务隔离级别 Read Committed 、 Repeatable Read 、 Serializable ；支持悲观锁、智能实时死锁检测、智能实时死锁解除及记录相关日志信息。
B、 数据库功能要求：支持 CREATE 、 TRUNCATE 、 DROP 、 ALTER 、 RENAME 、 SELECT 、 INSERT 、 UPDATE 、 DELETE 等数据库基本操作；支持透明跨数据分片的 JOIN 连接；支持透明跨数据分片的分组计算、排序、分页、聚合函数、控制函数等。
C、 水平扩展要求：具有完备的动态扩容缩容能力，支持可视化在线一键扩容缩容，做到：在线增加 / 缩减从存储节点读操作扩容、数据节点跨物理服务器迁移扩容、增加 / 缩减数据分片的扩展等多种扩容缩容模式，数据节点扩展分布式集群的处理能力和数据容量，且扩容 / 缩容过程中做到不影响业务访问。
D、 业务键分片：支持智能算法按业务访问需要生成数据分片的分片键、分片类型等，这个涉及到如何确保业务系统性能最佳和数据架构设计最佳。
4、请教专家：贵公司在分布式数据库应用方面：主要解决了什么问题？使用的场景是怎样的？上线之前需要考虑的因素主要有哪些？
（问题来自@zhangjunpo CBIT 数据库运维工程师）
@孔再华 中国民生银行 数据库运维工程师：
民生银行的分布式核心系统是将直销银行核心系统搬迁上去了，未来会将真正的核心系统也做分布式改造。当前我行使用的是基于阿里开源的分布式中间件zdal基础上自研的分布式架构，底层采用了开源数据库mysql，通过一主多备实现高可用。
我行采用分布式数据库方案主要是为了解决集中式高并发交易存在性能瓶颈的问题。通过采用分布式，分摊数据和交易，解决了性能，也分摊了风险。合理的业务数据分片，严控事务分发，当前一直保持稳定高效运行。我们避免了分布式事务，从业务层面解决了这个问题。
因此对于其他希望采用分布式数据库的金融企业，上线前主要考虑的因素也是怎么让业务和数据做好分片，怎么避免分布式事务。然后考虑怎么运维分布式的环境。
5、目前有什么业内用的较多的成熟产品吗？
@孔再华 中国民生银行 数据库运维工程师：
分布式数据库我测试到现在，其实内心是觉得大家都不成熟。如果你仔细看业内的使用案例，你会发现大家用的产品都不一样。这也是和分布式数据库这几年遍地开花有关系。而且你会发现一个特点，主打分布式数据库好像都是国内的产品。国外也就一些开源的分布式产品，也都属于半成品。我们在测试的过程里发现，分布式数据库的瓶颈一般都会在全局事务管理器这类全局统一的集中点，所以哪个数据库能把这些做到轻量级，哪个数据库性能就好点。
6、分布式数据库如何具体实施？具体如何设计，最大程度避免风险？
（问题来自@feifei7412中信 数据库运维工程师）
@孔再华 中国民生银行 数据库运维工程师：
分布式数据库的实施我觉得分为两方面。一方面是数据库的对象实施，怎么设计表，怎么选分区键，怎么控制业务访问。另一方面是数据库架构实施，怎么挑选节点，怎么安排好组件，怎么做多中心部署。
从第一个方面来说，大表选择查询或者关联的条件列作为分布列，小表需要建立成复制表。减少非分布列条件的大表关联查询，减少分布式事务。也就是从前到后都要按照分布式的理念去设计。
从架构的角度来说，需要确定好多中心的部署方案，需要确认好集群内部的冗余机制，保证出现单机故障或者单中心故障的情况下，都有冗余措施能够保证数据服务可用，数据不丢失等。
最后做好检查和维护的方案。保障系统稳定运行。
@wanglaye 某大型金融机构 项目经理：
在设计分布式数据库架构时，要考虑高可用、负载均衡、网络、存储、监控与告警、备份与恢复、灾备、日常运维、应用适配和优化等多方面的方案规划。尤其需要特别注意网络延时、多应用数据隔离、分布式事务处理、数据归档等难点问题。
@GoldenDB 中兴通讯 产品经理：
分布式数据库分为横向数据分片分担负荷，纵向主从分片增加可靠性。
业务分片主要是根据业务表的实际规模或者设计规模进行设计，跟业务功能有关。
纵向分布主要是根据同城异地机房的分布来设计，一般一个机房部署1-2个节点，
如果有跑批类的需求，还可以增加分片专门用于跑批。
对于量不大的点，可以在同一个硬件节点部署2个分布式数据库实例来减少投资。
具体情况肯定还是要具体分析。
7、实施过程或者运维过程的痛点在哪来？
（问题来自@zhangjunpo CBIT 数据库运维工程师）
@孔再华 中国民生银行 数据库运维工程师：
实施过程主要是和业务开发的讨论更多，怎么实施好业务分片，怎么减少分布式事务。运维过程中主要还是分片多了，集群大了，故障明显多了，比较繁琐。
@wanglaye 某大型金融机构 项目经理：
最大的痛点不在于数据库本身的技术，而在于业务系统从原有系统向新数据库迁移的兼容性和改造难度。
对于运维人员而言，分布式数据库比原来各业务系统独立使用数据库更加易于运维，但是刚引入分布式数据库，难免碰到技术和人力跟不上的阶段。
@Amygo 分布式事务数据库管理员：
（1）数据分片设计：按照分布式数据库理论，则需要将数据分片后存储到不同的存储节点中，要是默认采用主键、唯一索引或隐含字段的三种方式不符合金融行业业务场景的要求，更多是依赖某个业务特性的字段作为数据分片键，所以唯一办法把这块的工作量转嫁给产品售卖方去承担。
（2）运维过程的痛点：性能优化，因为SQL语句会被计算引擎改写，则SQL语句优化、索引优化等不能完全基于人工的方式，必须具备相关的智能算法；业务系统吞吐量下降：是否有智能的死锁检测算法和死锁解除算法，必须需��������,��������要人工介入和如何避免性能下降；故障隐患，是否集群有相关的功能，做到智能发现故障或隐患，及智能告知那个环节出问题了、是什么愿意出问题了，避免人工到处分析日志的方式。