中小银行在行内传统架构大前提下,进行分布式数据库方向转型,面临诸多难题与不可控因素。
1.引进分布式数据库后如何确保全局一致性
2.架构选型阶段,如何在高可用方面进行把关
个人认为,题主不用纠结于一致性和高可用这方面,因为现在比较知名的分布式数据库,如ob、TDSQL、TiDB等,对于题主这些问题已经解决的很好了。如果一定要考虑这些方面,那么可以在poc测试阶段增加相关的测试方案,比如一致性测试时对于ACID的验证,在高可用测试时设置单节点、单机柜故障等场景用于验证。
我认为,在分布式数据库选型时,更应该关注数据库的综合能力,不仅要测试对于数据库传统功能的支持度、分布式特性(如弹性伸缩、高可用、高性能),更要测试数据库运维管理能力和兼容性,后者是应用迁移最为关注的问题。此外,也要考虑成本,根据行里预算进行选型。
1.分布式数据库大致两种技术路径,一种是以分布式共识协议来保证副本数据一致,一种是采用主从复制模式并保证数据或日志强同步后才提交。
2.在选型阶段,需要对高可用能力进行评测,包括进程级、主机级、硬件级、同城AZ、异地多种情况下的可用性验证测试。
分布式数据库的高可用性针对不同的解决方案有不同的解决方式,对于share nothing架构的分布式数据库通常是通过数据库主从复制来达到节点间的同步,也有通过中间件proxy或者节点管理协调框架来实现同步, 在选择方案时候要根据运维规模,研发能力和业务需求做权衡。 运维规模越大,节点间同步开销越大,对网络和磁盘I /O 的要求会越高。
收起关于“ 引进分布式数据库后如何确保全局一致性 ”的问题,多数分布式数据库由于采用基于数据分片的 share nothing 架构,全局一致性问题是一个很大的挑战。业内一般的解决办法,一个是利用特殊的硬件设备如原子钟来确保个节点的时间戳全局有序,另一个是通过集中服务来获得全局一致的版本号。无论哪种方式,都需要分布式数据库原生支持。在部署时,按照相应的产品文档配置来确保全局一致性。
收起