海量大数据分布式数据库解决方案思路

前言

　　随着互联网的发展，分布式技术的逐渐成熟，动态水平扩展和自动容灾备份、一键部署等技术方案不断成熟，各大中小互联网企业都在尝试切换将产品的技术方案到分布式的方案，可是分布式的技术方案有一个业内比较难以解决的问题，就是分布式事务的处理，大部分都是将业务尽可能限制在同库中，避免跨库事务，或者采用消息队列处理分布式事务，或者采用DTC来处理，可是性能都不是太理想。在阅读关于淘宝数据库OceanBase的一些文章时受到启发，想到一个不成熟的方案，也能够说是对OceanBase的一些思路的总结，在这里写出来给你们分享一下，也欢迎指出其中不合理或可改善的地方。

使用场景

　　1.海量数据；

　　2.读取压力大而更新操做的场景少；

　　3.保障高可用，最终一致性；

架构图

节点功能

1. Application Server 应用服务器，这里只画了一台，实际生产环境中多是几百上千个Host的服务，主要是业务服务；

2.Gate Gate中保持着数据中心各个功能节点的状态信息，Application Server从Gate中获取到须要操做的主机地址，而后再与数据中心指定的节点进行通讯；Gate中保留的节点信息会记录节点的路由ip和端口，节点的状态，另外记录节点的功能特色；Gate中会开一个守护进程负责与数据中心的各个节点进行通讯(每一个节点也有专门负责通讯的守护进程)，节点的可用状态经过心跳检测（节点是否拓机），节点是否处于busy状态由节点本身汇报到Gate守护进程，Gate守护进程再更新配置信息；

3.Update Master 负责数据库的更新操做，该节点并不保存全部数据，只是在须要更新时，将须要的数据从对应的查询库中获取到数据，而后在本机作事务更新，完成后，也是提交到本机。并经过某种机制(定时器或达到某个阈值)，就备份本机数据，并提交到Data Transfer Station，提交成功后，清空本地数据库。这里的难点是若是知道须要获取哪些数据，个人初步思路是，由应用服务本身告诉该节点，这是最简单的方式；

4.Update Slave:备用的Update服务器，当Master拓机时自动成为Master代替UpdateMaster的工做。守护进程实时监控Master状态；

5.Data Transfer Station 数据中转中心，负责收集变动数据，并备份存储，以防须要跟踪或恢复数据等。在Update Master提交备份数据后，查找空闲的Dispatcher，再由Dispatcher拉去须要的数据，分发同步到Query Server中；

6.Dispatcher 数据分发器，分发器从Data Transfer Station获取到数据，并从Gate中获取空闲的、未同步过该数据的Query Server，并将该Query Server标记为同步数据中，而后同步数据，同步完成后，将同步日志记录，返回给Data Transfer Station，接着继续下一个Query Server进行同步，直到全部都同步完成。完成后，Data Transfer Station将该份数据标记为全部节点已同步（同步过程当中Query Server仍是能够提供查询服务）；

7.Query Server 查询服务器，负责对外的数据查询。这里有一点还在考虑中，就是是否采用分片，由于数据量大，不分片确定会致使单机的查询效率降低，分片的话，如采用Hash算法计算分片，会增长查询的复杂度，最主要是，数据下发时，须要考虑该更新的数据是在哪一个分片上，相对会比较复杂；

 

查询数据请求流程图（未使用Hash MapReduce，若是使用，则须要在过程当中添加Hash计算数据所在的节点）

 

更新数据请求流程图

 

 

这里获取更新数据时，应该是全量的，即Update Master里的数据+Query Server的数据+Dispatcher未分发完成的数据；举例来讲，假设查询到的某个帐户余额100，000元，须要作一个转帐业务，须要转出10000元，而且以前已经作过一次转帐5000元，可是这笔5000元的转帐还未同步到查询服务器中，那么该次转帐应该是100,000元减去5,000元，而后再去作转出10,000元的操做。最终帐户余额应该是85,000元。另外，若是查询要作到强一致性，也应该这样作一个差别性数据合并，再转发给业务服务，这样就能作到信息的一致性和实时性。

 

以上仅提供一种思路，实现可结合本身的业务，对该解决方案作一些更改，具体选取技术。具体细节也考虑不是很周全，若有思路上的错误，请多指教。

 

本文原创，若有转载，请注明出处。