应用分布式数据库常见的 5 个顾虑和难点

以下内容来自社区交流活动。分享者：顾黄亮 互联网金融专家

1、大多数分布式数据库都是开源的，如何确保自己选择的数据库是稳定的？一旦出现问题如何解决呢?

分布式数据库运维中，整体来说有几个地方的挑战：

1. 是运维的复杂度会提升不少。譬如：异常故障的处理等。 

2.备份和恢复会复杂一些。这些的恢复是指产生逻辑错误导致的问题恢复。

稳定都是基于保证基础设施的架构合理性；保证数据库集群自身的健壮性；保证应用层架构的合理性。

2、分布式数据库在跨机房数据同步需要考虑哪些因素？

第一：考虑数据同步的场景；

第二：你分布式数据库的类型；

第三：你的业务架构；

第四：也是最重要的，对数据一致性的容忍性。

跨机房的数据复制方式一般是专线网络 + DB复制 来保障，终端服务实现跨机房的话 就需要系统相关的所有组件都支持跨机房高可用，并且需要实现自动化切换。补充一点， 跨机房服务部终端，会牺牲一定的数据一致性。这是数据级的，如果是业务级别的，还得有数据入口的路由， 应用与依赖组件多机房高可用部署(MQ、Hbase、对象存储服务等)，部分组件需要应用双写多机房，比如Hbase、对象存储的写入，诸如此类的细节也要考虑到。

3、金融业务场景，分布式数据库一个事务的数据分别在不同的数据库，如何实现事务一致性控制？

你想问的应该是多数据源情况下事务一致性问题。

简单说一下解决办法：

（1） 配置多个数据源，不同的 sessionFactory控制，在dao层根部不同的业务场景和需求路由到相应的数据源

（2）dao层可进行封装，将不同的sql sessionFactory注入到 sessionFactory，建立session对象，这样dao就实现基于basedao的集成

（3）最关键的是一个事务涉及多个数据源，当异常需要回滚

（4）接着3继续说，service添加事务发生异常，A库进行回滚，B库没有回滚怎么办，通过分布式事务，atomikos来处理。

4、分布式数据库如何解决理论上的备节点脏读问题？

脏读的情况很常见，一般是在并发事务的时候出现，类似的还有幻读和不可重复读。这种场景在金融中非常常见，比如还款和取款。

解释下脏读，一个事务读取另一个事务的数据，另一个事务的数据存在更改没有提交，如果出现被读取事务出现回滚，那这个被读取的数据是不合法的，这就是脏读。基于数据库来说，并没有更好的处理方式，无论读取还是写入都是合法的，一般只能应用通过锁来控制，锁用了越多，效率就越低了，这是需要一个平衡。

5、对于各个已有老的应用，想平滑过度过分布式数据库，需要做哪些工作？

1：充分的测试，评估时间，总结经验，提升性能在生产中进行数据的大批量迁移时，充分的测试时必须的。一方面可以根据这些测试积累一些必要的数据作为生产中使用参考，另外一方面可以基于之前的测试，总结经验，总结不足之处，加入改进，在生产中每一分钟的改进都是很重要的。这部分包括你说的代码的修改，sql的适配。

2：完整的备份

3： 迁移前期进行精密的规划，无论是迁移时间、事先准备、操作过程、事后处理等等

4： 迁移结束后需要验证新库，比如序列，重编译新库失效的对象，检查新库是否需要重建索引，用事先准备好的脚本验证新老库之间的数据是否有差异。

这种大级别的迁移，是很难做到无感知的。

如有任何问题，可点击文末阅读原文，到社区原文下评论交流

觉得本文有用，请转发、点赞或点击“在看”，让更多同行看到

 相关推荐：

欢迎关注社区 "分布式数据库"技术主题 ，将会不断更新优质资料、文章。地址：

http://www.talkwithtrend.com/Topic/37323

下载 twt 社区客户端 APP

长按识别二维码即可下载

或到应用商店搜索“twt”

长按二维码关注公众号

*本公众号所发布内容仅代表作者观点，不代表社区立场