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

分布式数据库（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的速度。关键还是看场景，如果是基于时序的聚合处理，不妨选择专门的时序数据库，比如 InfluxDB

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

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

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

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

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

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

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

4、分布式数据库（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 较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。为避免这一问题，运维人员在系统上线时必须确保有足够的空间，这对资源造成了很大的浪费 。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

原作者：顾黄亮

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。