分布式数据库（Elasticsearch、Redis、MySQL分布式集群等）场景选型和应用难点
随着互联网金融业态不断的发展，数据的交互和存储也呈现指数级增长，在此形势下，在分布式数据库的选型上，根据不同的业务场景和关键系统中选择不同的开源产品，通过对开源数据库的深入研究和应用，满足了企业业务场景的事务处理和数据处理的要求。本文针对几个分布式数据库的场景选型和应用难点进行了解读，整理自社区交流活动，供大家参考。
结合此文阅读有更多干货：《四种分布式数据库场景选型、优缺点对比分析和未来展望》（点击标题可阅读） 作者：顾黄亮 互联网金融专家。1、哪个分布式数据库适合处理返回的数据集很大(几兆几十兆)的并发场景？
【问题描述】我有一批实时的时间序列数据，需要按时间来查询，并做聚合及复杂处理(不止是sum、avg、max这种)。我这边主要使用的分布式数据库是Elasticsearch跟Redis，但是它们两个都不是特别适合。Redis是单线程的，返回大数据集会卡住，阻塞其他查询请求；Elasticsearch的search返回的数据集上限是10000，超过这个就得用scroll了，而且总感觉Elasticsearch来做这种简单的检索，有点浪费了。有什么好的分布式数据库适合做这个吗?
@顾黄亮 苏宁消费金融有限公司 技术总监：
命题中两个需求，1：海量数据；2：时效性
如果是单纯考虑1，基本上绝大部分的分布式数据库都适合，无非考虑到海量到什么程度，但是每个分布式数据库的优点不一样，比如说Redis的场景是缓存和订阅，es的场景更多的是搜索数据分析。如你所说，Redis和es都有缺点，Redis是单线程的，一个查询慢了会导致整个查询超时，es没有事务的概念，查询批量的数据集会有限制。
如果是2：其实绝大多数的分布式数据库也是适合的，关键还是看你时效到什么程度，拿hbase来说，写入性能能达到每秒1W的速度。
关键还是看场景，如果是基于时序的聚合处理，不妨选择专门的时序数据库。
2、在选择分布式数据库的时候如何解决后续的维护问题？
【问题描述】大多数分布式数据库都是开源的，如何来确保自己选择的数据库是稳定的呢？一旦出现问题如何解决呢?
@顾黄亮 苏宁消费金融有限公司 技术总监：
分布式数据库运维中，整体来说有几个地方的挑战：1. 是运维的复杂度会提升不少。譬如：异常故障的处理等。 2.备份和恢复会复杂一些。这些的恢复是指产生逻辑错误导致的问题恢复。
稳定都是基于保证基础设施的架构合理性；保证数据库集群自身的健壮性；保证应用层架构的合理性。
3、分布式数据库在跨机房数据同步需要考虑哪些因素？
@顾黄亮 苏宁消费金融有限公司 技术总监：
第一：考虑数据同步的场景；
第二：你分布式数据库的类型；
第三：你的业务架构；
第四：也是最重要的，对数据一致性的容忍性。
跨机房的数据复制方式一般是专线网络 + DB复制 来保障，终端服务实现跨机房的话 就需要系统相关的所有组件都支持跨机房高可用，并且需要实现自动化切换。补充一点， 跨机房服务部终端，会牺牲一定的数据一致性。这是数据级的，如果是业务级别的，还得有数据入口的路由， 应用与依赖组件多机房高可用部署(MQ、Hbase、对象存储服务等)，部分组件需要应用双写多机房，比如Hbase、对象存储的写入，诸如此类的细节也要考虑到。
@508mars 华泰证券 数据库管理员：
1）对数据同步延迟的要求，跟业务系统等级相关，高等级业务系统通常采用同步复制，反之采用异步复制
2）对性能的要求，数据同步延迟越低，对主节点性能影响越大
3）跨机房网络质量，直接影响数据同步延迟
4、金融业务场景，分布式数据库一个事务的数据分别在不同的数据库，如何实现事务一致性控制？
【问题描述】金融业务场景，假如分布式数据库一个事务的数据分别在不同的数据库，如何实现事务一致性控制？通过数据库层还是应用层进行控制？应用层如何实现？如果数据库层控制的话如何控制？
@顾黄亮 苏宁消费金融有限公司 技术总监：
你想问的应该是多数据源情况下事务一致性问题。
简单说一下解决办法：
（1） 配置多个数据源，不同的 sessionFactory控制，在dao层根部不同的业务场景和需求路由到相应的数据源
（2）dao层可进行封装，将不同的sql sessionFactory注入到 sessionFactory，建立session对象，这样dao就实现基于basedao的集成
（3）最关键的是一个事务涉及多个数据源，当异常需要回滚
（4）接着3继续说，service添加事务发生异常，A库进行回滚，B库没有回滚怎么办，通过分布式事务，atomikos来处理。
@508mars 华泰证券 数据库管理员：
数据库层控制：一般会由数据库计算节点通过“两阶段提交+悲观锁/乐观锁”来实现跨节点事务一致性，其中还涉及到全局事务id等概念。
应用层控制：两阶段提交、本地消息表、TCC补偿模式等，网上有很多介绍。
5、Mongodb数据库v3.0强一致性事务能力怎么样，生产环境有坑吗？
【问题描述】听说mongodb数据库最新版本增加了事务功能，在银行业有落地案例吗？相比传统数据库，这类nosql未来的SQL能力能否满足业务需求，稳定性和性能如何？
@顾黄亮 苏宁消费金融有限公司 技术总监：
Mongo3.0自身是不提供事务处理的。如果要实现事务操作，必须自己写实现代码。在为你的项目选定数据库的时候，要根据你的项目来量身选择。如果需要强事务操作的和数据一致性很高的地方，最好选择健壮的关系行数据库。如果对事务处理要求不高，而对数据存取要求很高的，则选择非关系型数据库。
貌似4.0提供文档事务支持。说说坑，其实Mongo最大的坑是锁，一般遇到的延迟问题，尤其涉及用户名密码访问的方式，mongo从最开始的全局锁，到库锁，一直到3.0的表锁，无处不是坑，4.0不知道又到什么级别的锁。
6、MySQL分布式数据如何同步与备份？
【问题描述】目前公司作了MySQL集群，同时也作了主备，但由于每次备份时采用全量备分，出了问题时恢复麻烦。如果采用增量备份，维护数据一致性又很复杂。 有没有实践中将二者处理得很较好的案例。
@顾黄亮 苏宁消费金融有限公司 技术总监：
MySQL其实只有一种复制方式，就是基于binlog的复制，但是基于binlog的复制又分三种，一种是基于sql的复制，第二种是基于行的复制，第三个就是混合复制，第一种是使用最多的。我不知道你描述的全量和增量是什么方式，继续说下binlog，如果是基于sql的复制，它的binlog文件比较小，而且可以用于实时的还原，但是有一些更新语句不能使用，复杂一些的语句对系统的开销比较大。如果基于行的复制，顾名思义，那就是binlog文件会很大，任何情况都会被复制，更加安全可靠，且速度会快很多。鉴于以上，mysql还提供混合模式，可以试一试。
7、分布式数据库如何解决理论上的备节点脏读问题？
@顾黄亮 苏宁消费金融有限公司 技术总监：
脏读的情况很常见，一般是在并发事务的时候出现，类似的还有幻读和不可重复读。这种场景在金融中非常常见，比如还款和取款。
解释下脏读，一个事务读取另一个事务的数据，另一个事务的数据存在更改没有提交，如果出现被读取事务出现回滚，那这个被读取的数据是不合法的，这就是脏读。基于数据库来说，并没有更好的处理方式，无论读取还是写入都是合法的，一般只能应用通过锁来控制，锁用了越多，效率就越低了，这是需要一个平衡。
8、对于各个已有老的应用，我们想平滑过度过分布式数据库，需要做哪些工作？
@顾黄亮 苏宁消费金融有限公司 技术总监：
1：充分的测试，评估时间，总结经验，提升性能在生产中进行数据的大批量迁移时，充分的测试时必须的。一方面可以根据这些测试积累一些必要的数据作为生产中使用参考，另外一方面可以基于之前的测试，总结经验，总结不足之处，加入改进，在生产中每一分钟的改进都是很重要的。这部分包括你说的代码的修改，sql的适配。
2：完整的备份
3： 迁移前期进行精密的规划，无论是迁移时间、事先准备、操作过程、事后处理等等
4： 迁移结束后需要验证新库，比如序列，重编译新库失效的对象，检查新库是否需要重建索引，用事先准备好的脚本验证新老库之间的数据是否有差异。
这种大级别的迁移，是很难做到无感知的。
原题：分布式数据库（elasticsearch、redis、mysql分布式集群、mongodb等）场景选型探讨 如有任何问题，可点击文末阅读原文，到社区原文下评论交流 觉得本文有用，请转发或点击“在看”，让更多同行看到
相关推荐：
分布式数据库产品关键功能技术探索
http://www.talkwithtrend.com/Article/245341
分布式关系型数据库需求及选型分析
http://www.talkwithtrend.com/Article/244321
欢迎关注社区 "分布式数据库"技术主题 ，将会不断更新优质资料、文章。地址：
http://www.talkwithtrend.com/Topic/37323
下载 twt 社区客户端 APP
与更多同行在一起
高手随时解答你的疑难问题
轻松订阅各领域技术主题
浏览下载最新文章资料
长按识别二维码即可下载
或到应用商店搜索“twt”
*本公众号所发布内容仅代表作者观点，不代表社区立场