分布式数据库（Elasticsearch、Redis、MySQL分布式集群等）场景选型和应用难点

近年来，随着国际信息安全形式的日益严峻，国家信息安全策略逐步深刻。所以，一行两会连续针对金融业数据库技术受制于人的严峻形势出台了相关政策，以知足构建安全可靠可控的信息技术体系的要求。

纵观近年来普惠金融的发展，多用户、低额的客单价带来的主要挑战是数据量、交易额的大幅提升，并伴随着数十倍的交易高峰压力以及交易复杂度的增长。而传统数据库在处理此类应用场景的时，在扩展性、性能、吞吐量和可靠性等方面遇到了明显的瓶颈，只能经过业务拆分、升级硬件的方式来提高性能，形成设备投入和人员成本的不断攀升。面对着互联网金融业态不断的发展，数据的交互和存储也呈现指数级增加，这样的方式也没法保证业务连续性。在此形式下，在分布式数据库的选型上，根据不一样的业务场景和关键系统中选择不一样的开源产品，经过对开源数据库的深刻研究和应用，知足了企业业务场景的事务处理和数据处理的要求。

精彩回复

一、哪一个分布式数据库适合处理返回的数据集很大(几兆几十兆)的并发场景？

我有一批实时的时间序列数据，须要按时间来查询，并作聚合及复杂处理(不止是sum、avg、max这种)。我这边主要使用的分布式数据库是elasticsearch跟redis，可是它们两个都不是特别适合。Redis是单线程的，返回大数据集会卡住，阻塞其余查询请求；elasticsearch的search返回的数据集上限是10000，超过这个就得用scroll了，并且总感受elasticsearch来作这种简单的检索，有点浪费了。有什么好的分布式数据库适合作这个吗?

嘉宾：顾黄亮  技术总监 , 苏宁消费金融有限公司
命题中两个需求，1：海量数据；2：时效性
若是是单纯考虑1，基本上绝大部分的分布式数据库都适合，无非考虑到海量到什么程度，可是每一个分布式数据库的优势不同，好比说redis的场景是缓存和订阅，es的场景更多的是搜索数据分析。如你所说，redis和es都有缺点，redis是单线程的，一个查询慢了会致使整个查询超时，es没有事务的概念，查询批量的数据集会有限制。
若是是2：其实绝大多数的分布式数据库也是适合的，关键仍是看你时效到什么程度，拿hbase来讲，写入性能能达到每秒1W的速度。
关键仍是看场景，若是是基于时序的聚合处理，不妨选择专门的时序数据库，好比 InfluxDB

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

嘉宾1：顾黄亮  技术总监 , 苏宁消费金融有限公司
第一：考虑数据同步的场景；
第二：你分布式数据库的类型；
第三：你的业务架构；
第四：也是最重要的，对数据一致性的容忍性。
跨机房的数据复制方式通常是专线网络 + DB复制 来保障，终端服务实现跨机房的话 就须要系统相关的全部组件都支持跨机房高可用，而且须要实现自动化切换。补充一点， 跨机房服务部终端，会牺牲必定的数据一致性。这是数据级的，若是是业务级别的，还得有数据入口的路由， 应用与依赖组件多机房高可用部署(MQ、Hbase、对象存储服务等)，部分组件须要应用双写多机房，好比Hbase、对象存储的写入，诸如此类的细节也要考虑到。

嘉宾2：508mars  数据库管理员 , 华泰证券
1）对数据同步延迟的要求，跟业务系统等级相关，高等级业务系统一般采用同步复制，反之采用异步复制
2）对性能的要求，数据同步延迟越低，对主节点性能影响越大
3）跨机房网络质量，直接影响数据同步延迟

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

金融业务场景，假如分布式数据库一个事物的数据分别在不一样的数据库，如何实现事物一致性控制？经过数据库层仍是应用层进行控制？应用层如何实现？若是数据库层控制的话如何控制？

嘉宾1：顾黄亮  技术总监 , 苏宁消费金融有限公司
你想问的应该是，多数据源状况下事务一致性问题，若是不是，请另补充
简单说一下解决办法：（1） 配置多个数据源，不一样的 sessionFactory控制，在dao层根部不一样的业务场景和需求路由到相应的数据源（2）dao层可进行封装，将不一样的sql sessionFactory注入到 sessionFactory，创建session对象，这样dao就实现基于basedao的集成（3）最关键的是一个事务涉及多个数据源，当异常须要回滚（4）接着3继续说，service添加事务发生异常，A库进行回滚，B库没有回滚怎么办，经过分布式事务，atomikos来处理。

嘉宾2：508mars  数据库管理员 , 华泰证券
数据库层控制：通常会由数据库计算节点经过“两阶段提交+悲观锁/乐观锁”来实现跨节点事务一致性，其中还涉及到全局事务id等概念。
应用层控制：两阶段提交、本地消息表、TCC补偿模式等，网上有不少介绍。

四、分布式数据库（elasticsearch、redis、mysql分布式集群、mongodb等）

这四种分布式数据库的优缺点和应用选择注意点分别是什么？

嘉宾：顾黄亮  技术总监 , 苏宁消费金融有限公司
es优势：将你的文档分割到不一样容器或者分片中，能够存在单个节点或多个节点
复制每一个分片提供数据备份，防止硬件问题致使数据丢失。
对集群中任意节点的相互请求进行路由，保证获取的数据是你须要的，集群增长或者从新分配分片时，不停机让新节点恢复丢失的节点分片数据
redis优势：1速度快，由于数据存在内存中，相似于 HashMap ， HashMap 的优点就是查找和操做的时间复杂度都是;
2支持丰富数据类型，支持 string ， list ， set ， sorted set ， hash;
3支持事务，操做都是原子性，所谓的原子性就是对数据的更改要么所有执行，要么所有不执行;
4丰富的特性：可用于缓存，消息，按 key 设置过时时间，过时后将会自动删除

mongo优势：1弱一致性（最终一致），更能保证用户的访问速度;
2 文档结构的存储方式，可以更便捷的获取数据;
3内置 GridFS ，支持大容量的存储4在使用场合下，千万级别的文档对象，近 10G 的数据，对有索引的 ID 的查询不会比 mysql 慢，而对非索引字段的查询，则是全面胜出 。

es缺点： 没有用户验证和权限控制，没有事务的概念，不支持回滚，误删不能恢复，须要 java 环境 .
redis缺点：1具有自动容错和恢复功能，主机从机的宕机都会致使前端部分读写请求失败，须要等待机器重启或者手动切换前端的 IP 才能恢复;
2主机宕机，宕机前有部分数据未能及时同步到从机，切换 IP 后还会引入数据不一致的问题，下降了系统的可用性;
3主从复制采用全量复制，复制过程当中主机会 fork 出一个子进程对内存作一份快照，并将子进程的内存快照保存为文件发送给从机，这一过程须要确保主机有足够多的空余内存。若快照文件较大，对集群的服务能力会产生较大的影响，并且复制过程是在从机新加入集群或者从机和主机网络断开重连时都会进行，也就是网络波动都会形成主机和从机间的一次全量的数据复制，这对实际的系统运营形成了不小的麻烦;
4Redis 较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。为避免这一问题，运维人员在系统上线时必须确保有足够的空间，这对资源形成了很大的浪费 。

五、mongodb数据库v3.0强一致性事务能力怎么样，生产环境有坑吗？

据说mongodb数据库最新版本增长了事务功能，在银行业有落地案例吗？相比传统数据库，这类nosql将来的SQL能力可否知足业务需求，稳定性和性能如何？

嘉宾：顾黄亮  技术总监 , 苏宁消费金融有限公司
Mongo3.0自身是不提供事务处理的。若是要实现事务操做，必须本身写实现代码。在为你的项目选定数据库的时候，要根据你的项目来量身选择。若是须要强事务操做的和数据一致性很高的地方，最好选择健壮的关系行数据库。若是对事务处理要求不高，而对数据存取要求很高的，则选择非关系型数据库。
貌似4.0提供文档事务支持。说说坑，其实Mongo最大的坑是锁，通常遇到的延迟问题，尤为涉及用户名密码访问的方式，mongo从最开始的全局锁，到库锁，一直到3.0的表锁，无处不是坑，4.0不知道又到什么级别的锁

六、Elasticsearch、redis在数据中台中如何选型使用，如何让数据开发的数据快速生成API对外服务？

嘉宾：  顾黄亮  技术总监 , 苏宁消费金融有限公司
这个问题思考了好久，对于ES或redis来讲，针对数据中台不该该说选型，应该是数据集成的选择。
暂时不说选型，先说说数据集成的准备工做，在数据集成开发以前，应该准备数据源的分类、环境的梳理、数据内容、数据质量、数据的范围。而后进行数据集成的业务架构涉及，再进行数据集成、数据同步、数据处理的流程，肯定数据库的选型，最后才是API类数据的输出。
ES和redis的使用彻底参照这两种软件的使用场景，数据快速生产API对外服务是数据输出的一种方式

七、在选择分布式数据库的时候如何解决后续的维护问题？

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

嘉宾：顾黄亮  技术总监 , 苏宁消费金融有限公司
分布式数据库运维中，总体来讲有几个地方的挑战：1. 是运维的复杂度会提高很多。譬如：异常故障的处理等。 2.备份和恢复会复杂一些。这些的恢复是指产生逻辑错误致使的问题恢复。
稳定都是基于保证基础设施的架构合理性；保证数据库集群自身的健壮性；保证应用层架构的合理性

八、mysql分布式数据如何同步与备份？

目前公司做了mysql集群，同时也做了主备，但因为每次备份时采用全量备分，出了问题时恢复麻烦。若是采用增量备份，维护数据一致性又很复杂。 有没有实践中将两者处理得很较好的案例。

嘉宾：顾黄亮  技术总监 , 苏宁消费金融有限公司
mysql其实只有一种复制方式，就是基于binlog的复制，可是基于binlog的复制又分三种，一种是基于sql的复制，第二种是基于行的复制，第三个就是混合复制，第一种是使用最多的。我不知道你描述的全量和增量是什么方式，继续说下binlog，若是是基于sql的复制，它的binlog文件比较小，并且能够用于实时的还原，可是有一些更新语句不能使用，复杂一些的语句对系统的开销比较大。若是基于行的复制，顾名思义，那就是binlog文件会很大，任何状况都会被复制，更加安全可靠，且速度会快不少。鉴于以上，mysql还提供混合模式，能够试一试。

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

嘉宾：顾黄亮  技术总监 , 苏宁消费金融有限公司
脏读的状况很常见，通常是在并发事务的时候出现，相似的还有幻读和不可重复读。这种场景在金融中很是常见，好比还款和取款。
解释下脏读，一个事务读取另外一个事务的数据，另外一个事务的数据存在更改没有提交，若是出现被读取事务出现回滚，那这个被读取的数据是不合法的，这就是脏读。基于数据库来讲，并无更好的处理方式，不管读取仍是写入都是合法的，通常只能应用经过锁来控制，锁用了越多，效率就越低了，这是须要一个平衡

十、请问对于各个已有老的应用，咱们想平滑过分过度布式数据库，须要作哪些工做？

请问对于各个已有老的应用，集中式数据库，咱们想平滑过分过度布式数据库，须要作哪些工做？
是要对应用代码进行重构，好比代码的修改，包括sqk语句，仍是数据库的中间件是我无感知.

嘉宾：顾黄亮  技术总监 , 苏宁消费金融有限公司
1：充分的测试，评估时间，总结经验，提高性能在生产中进行数据的大批量迁移时，充分的测试时必须的。一方面能够根据这些测试积累一些必要的数据做为生产中使用参考，另一方面能够基于以前的测试，总结经验，总结不足之处，加入改进，在生产中每一分钟的改进都是很重要的。这部分包括你说的代码的修改，sql的适配
2：完整的备份
3： 迁移前期进行精密的规划，不管是迁移时间、事先准备、操做过程、过后处理等等
4： 迁移结束后须要验证新库，好比序列，重编译新库失效的对象，检查新库是否须要重建索引，用事先准备好的脚本验证新老库之间的数据是否有差别
这种大级别的迁移，是很难作到无感知的.

---

原做者：顾黄亮
原文连接： 分布式数据库（elasticsearch、redis、mysql分布式集群、mongodb等）场景选型探讨 - 顾黄亮 - twt企业IT交流平台
原出处：twt企业IT交流平台