分布式数据库在商业银行设计与实践的 8 个难点
作者：互联网
在前不久的社区交流活动中，我们邀请行业专家分享了《分布式数据库 TiDB 在商业银行的设计与实践》（点击标题可阅读），并与会员共同探讨了在商业银行中，分布式数据库应用的相关问题，获得了广泛关注。在此，由活动嘉宾wanglaye根据活动探讨总结分布式数据库在商业银行设计与实践的 8 个难点和相应解析，供大家参考。
【Q1】分布式数据库适用场景有哪些？和传统的数据库有哪些不同？
@匿名用户：
分布式数据的使用场景，依赖于数据库产品本身的特点来说的。如果非要说一些它的场景的话，哪就是两个量大（数量量大，请求量大）共存的业务。
和传统数据库的区别有几点：
1.分布式。传统数据库基本上单机版。
2.能支撑更大量的数据，和请求量（或事务量）。
3.因数据的分片方式不同，要结合应用场景进行选择和应用适配。传统数据库不需要
@mornsky：
互联网时代，数据量、并发量剧增，传统单节点数据库方式很难适应，这就是分布式数据库的用武之地。今后，不管是互联网企业还是金融业或传统企业，分布式数据库是趋势，或者传统数据库也将走向分布式升级改造。
@wanglaye：
分布式数据库针对的是海量数据、高并发交易的应用场景。
传统事务型业务场景在选择数据库时，也要考虑分布式数据库是否支持分布式事务。
【Q2】当前金融环境下分布数据库选型？
目前分布式数据库各式各样，要想选择一个靠谱的分布式数据库是特别的难。特别对于金融行业，对数据的一致性、可用性要求这么高。市面上的分布式数据库该如何选择？
@p14159：
目前很多金融公司都开始使用多云的环境，对应的数据库也开始向着分布式发展，OLTP OLAP的界限不再明显。 市场上有很多类似的产品，商业的如阿里的DRDS、亚马逊的Aurora等，开源的如CockroachDB 、TiDB 、 巨杉、 RadonDB 等。
更多的选择，更多的学习成本，给技术人员带来了更多的挑战。
在分布式数据库的选择上，大家重点要考虑哪些因素？
个人认为有如下几点：
1 大厂/社区的支持
2 庞大的用户规模，丰富的生产使用案例
3 开发团队更重视用户的声音，能够及时调整设计思路。
4 对原生的SQL完全支持
5 完整的生态，如备份迁移工具，优化分析报告、监控与自动化管理等
@gaolyang：
还有一点很重要，公司的技术支持态度及能力。
@wuwenpin：
自身的技术力量更重要。
@匿名用户：
我个人觉得从几个地方去看：
1.产品成熟度。数据库是个非常重要的系统，对系统的稳定性要求非常好，产品成熟度高代表着稳定性会好一些。
2.使用广泛。使用广泛也是为了稳定性，同时遇到问题，有响应的社群交流。
3.技术实力。公司是否具有很高的技术实力和知名度。
4.针对这些产品结合自己的金融场景来选择，其实上面的不是都适合金融的OLTP场景。
5.成本。这里包括购买成本，以及维护成本，这个需要自己去测试一下。
【Q3】选择分布式数据库所注重的数据库特性有哪些？
@匿名用户：
我个人觉得有几点需要关注：
1.是OLTP还是OLAP
2.在具体的场景下性能如何
3.数据分布的策略是什么
4.增删节点是否比较容易
5.后续在使用过程中如果遇到问题，它支持是否给力
【Q4】传统数据库如果要改造成分布式数据库，有哪些技术难点？
@韩成亮：
个人觉得主要是思维模式的转变，毕竟分布式数据库就目前而言，在事务而言，采用的分布式事务，还有就是分布式数据库主要有调度节点，计算节点和存储节点构成，这个跟传统的其实是个很大的差别，对于问题的排查可能需要更加准确的认知，还有一些分布式数据库的特性，分布式数据库的使用习惯，跟传统的有很大差别，比方说一件扩容，弹性扩展，在线迁移，还有就是高可用等，其次是传统意义上的备份方式就不是很实用了。
至于传统数据库的改造，说到底就是业务的改变，简单点而言，无论是传统数据库还是分布式数据库说到底的本质上而言是存储数据，并进行相应的业务逻辑处理，存储数据库大体是一致的，对于业务的处理部分就会牵扯到事务了，乃至于性能响应了，这部分的难点不言而喻，事务的一致性跟性能的可用性就是一个取舍，当然也可以使用事务的最终一致性来解决，而这个也是常规的分布式数据库所推荐的方案。
@gaolyang：
首先从业务系统角度来说，该系统所使用的数据库对象构成方面，最好只有简单的SQL语句，而无存储过程等传统数据库中的复杂对象，也就是数据迁移成本；
其次，对于所创建的分布式数据库集群，由于集群有一定的服务器规模，所以要平衡硬件成本问题；
最后我认为，业务系统的类型除了应满足高并发等OLTP数据库的特性之外，还有海量数据存储的需要。
【Q5】贵行做的分布式数据库的多活如何保证网络的延时？
@wanglaye：
集群内部使用万兆网络通讯最佳，多数据中心之间使用裸光纤+波分设备是最佳选择，如果是异地，在条件允许的情况下，用光纤最佳，但要考虑高昂的成本。最好是从架构层面设计多活，从业务层面考虑异地网络的延时。
@chrislay：
多数据库中心，租用运营商的带宽，一般是波分设备，有的是拉裸纤，成本就高了，还有就是业务架构上的优化。
【Q6】单数据中心，多 TiKV 进程终止、TiKV 服务器宕机、TiDB 服务器宕机、PD 服务器宕机，集群是否仍然可以对外服务？
@匿名用户：
单数据中心下，出现一定程度（每个产品有一定的最大宕机数）宕机，集群是可以对外提供服务的。
如果是多IDC下，目前很多分布式数据库是做不到的，除非考虑IDC之间做专线。
@wanglaye：
这个要考虑整个集群的架构设计。
TiKV 是一个集群，通过 Raft 协议保持数据一致性，并通过 PD 做负载均衡调度。单个TiKV节点失效时，会影响这个节点上存储的所有Region。对于 Region 中的Leader 结点，会中断服务，等待其他TiKV上的Region重新选举Leader，待Leader选出了可继续对外提供服务，这个过程非常短；对于Region 中的Follower节点，不会影响服务。
TiDB 是无状态的，通过前端的F5对外提供服务。当单个TiDB实例失效时，仅仅会影响正在这个实例上进行的会话，从应用的角度看，会出现单次请求失败的情况，应用重新连接至其他TiDB实例后即可继续获得服务。单个TiDB实例失效后，可以重启这个实例或者部署一个新的实例。
PD 是一个集群，通过 Raft 协议保持数据的一致性。单个实例失效时，如果不是leader，那么服务完全不受影响；如果是leader，那么PD集群会重新选出新的leader，自动恢复服务。
在实际测试和应用过程中，单数据中心，TiKV 服务不可用、TiKV 主机故障、TiDB 主机故障、PD 主机故障，数据库均能正常提供服务。
【Q7】集群中单台TiKV出现故障，如tikv进程终止、TiKV 主机万兆网卡断开、TiKV 主机服务器宕机，集群是否仍然可以对外服务？
@wanglaye：
只要集群中剩余可用副本数仍占大多数，集群就可以对外服务。
@tshqin：
在部署集群的时候可以为集群中的 tikv 添加 label 信息，PD 会根据 label 信息进行副本调度，根据所配置的 label 级别的不同，可以避免将同一个 region 的两个 replica 调度到：
同一台服务器的两个 tikv 实例上
同一个机架的几个 tikv 实例上
同一个机房的几个 tikv 实例上
据此可以实现服务器级/机架级/机房级的容灾，因为集群中还存活大多数的副本就有能力对外提供服务。
详情参考官方手册：https://www.pingcap.com/docs/op-guide/location-awareness/
【Q8】OLTP型分布式数据库跨节点事务性能问题？
金融银行传统业务采用分布式数据库的话，业务场景复杂，例如对账户表的拆分，转账交易的话可能会导致大量的分布式事务，影响整体数据库性能，或者无法发挥分布式数据库的优势，针对这个问题，有没有比较理想的解决方案？
@刘诚杰：
CAP就占有技术本身就无法兼得，在银行场景只能牺牲速度，保证事务执行。除了核心的资金场景，少用事务可以更合理使用分布式数据库。
@韩成亮：
针对这个问题，首先我们需要了解事务的一致性，分布式数据库不可避免的或多或少存在这样的问题，简单点而言，我们有些时候并不需要保证单个事务的一致性，我们可能通过最终一致性来解决，而这个也是分布式数据库设计的一个因素，因为往往有些时候可用性和一致性很难平衡，这就有了保证最终一致性的各种措施比如消息队列，全局事务表，二阶段提交，三阶段提交等
标签：难点,事务,场景,数据库,TiKV,集群,分布式 来源： https://blog.51cto.com/u_15127582/2757019