OceanBase分布式系统负载均衡案例学习

        一个集群若是出现了负载不均衡问题，那么负载最大的机器每每将成为影响系统总体表现的瓶颈和短板。为了不这种状况的发生，须要动态负载均衡机制，以达到实时的最大化资源利用率，从而提高系统总体的吞吐。

OceanBase架构介绍

OceanBase是一个具备自治功能的分布式存储系统，由中心节点RootServer、静态数据节点ChunkServer、动态数据节点UpdateServer以及数据合并节点MergeServer四个Server构成，以下图所示。

• Tablet：分片数据，最基本的存储单元，通常会存储多份，一个Table由多个tablet构成；
• RootServer：负责集群机器的管理、Tablet定位、数据负载均衡、Schema等元数据管理等。
• UpdateServer：负责存储动态更新数据，存储介质为内存和SSD，对外提供写服务；
• ChunkServer：负责存储静态Tablet数据，存储介质为普通磁盘或者SSD。
• MergeServer：负责对查询中涉及多个Tablet数据进行合并，对外提供读服务；

在一个集群中，Tablet的多个副本分别存储在不一样的ChunkServer，每一个ChunkServer负责一部分Tablet分片数据，MergeServer和ChunkServer通常会一块儿部署。

图1.Tablet在三台ChunkServer上的分布

图2.加入一台机器Tablet迁移后的分布

客户端链接到OceanBase以后一次读请求的读流程以下图所示:

1. Client 从RootServer获取到MergeServer 列表；
2. Client将请求发送到某一台MergeServer；
3. MergeServer从RootServer获取请求对应的ChunkServer位置信息；
4. MergeServer将请求按照Tablet拆分红多个子请求发送到对应的ChunkServer；
5. ChunkServer向UpdateServer请求最新的动态数据，与静态数据进行合并；
6. MergeServer合并全部子请求的数据，返回给Client；

     分析以上的流程可知，在第2步客户端选择MergeServer时若是调度不均衡会致使某台MergeServer机器过载；在第4步MergeServer把子请求发送到数据所在的ChunkServer时，因为每一个tablet会有多个副本，选择副本的策略若是不均衡也会形成ChunkServer机器过载[下面为按照此处存在负载不均衡分析]。因为集群部署会在同一台机器会同时启动ChunkServer和MergeServer，没法简单区分过载的模块。

ChunkServer是存储静态Tablet分片数据的节点，分析其负载不均的缘由包含以下可能：

1. 数据不均衡： ChunkServer上数据大小的分布是不均衡的，好比某些节点由于存储Tablet分片数据量多少的差别性而形成的不均衡；
2. 流量不均衡：数据即便是基本均衡的状况下，仍然会由于某些节点存在数据热点等缘由而形成流量是不均衡的。a.存在访问热点：好比热销的商品，这些热点数据会致使ChunkServer成为访问热点，形成了负载不均； b.请求差别性较大：系统负载和处理请求所耗费的CPU\Memory\磁盘IO资源成正比，而资源的耗费通常又和处理的数据量是成正比的，便可能是由于存在某些大用户而致使没有数据访问热点的状况下，负载仍然是不均衡的。

负载均衡算法设计

若是把热点ChunkServer上非热点Tablet的访问调度到其余Server，是能够缓解流量不均问题的，所以咱们设计了新的负载均衡算法为：以实时统计的ChunkServer上全部tablet的访问次数为Ticket，每次对Tablet的读请求会选择副本中得票率最低的ChunkServer。

同时考虑到流量不均衡的第二个缘由是请求的差别较大问题，ChunkServer对外提供的接口分为Get和Scan两种，Scan是扫描一个范围的全部行数据，Get是获取指定一行数据，所以两种访问方式的次数须要划分赋予不一样的权重(α,β)参与最终Ticket的运算：

除此以外，简单的区分两种访问模式仍是远远不够的，不一样的Scan占用的资源也是存在较大差别的，引入平均响应时间（avg_time）这个重要因素也是十分必要的：

负载均衡算法要求具备自适应性和强的实时性，一方面新的访问要实时累积参与下次的负载均衡的调度，另外一方面历史权重数据则须要根据统计周期进行非线性的衰减（y 衰减因子），减小对实时性的影响：

本文摘自：

http://www.csdn.net/article/2013-02-28/2814303-sharing-OceanBase-distributed-system-load-balance-case