【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 
一个集群如果出现了负载不均衡问题，那么负载最大的机器往往将成为影响系统整体表现的瓶颈和短板。为了避免这种情况的发生，需要动态负载均衡机制，以达到实时的最大化资源利用率，从而提升系统整体的吞吐。
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之后一次读请求的读流程如下图所示:
- Client 从RootServer获取到MergeServer 列表；
- Client将请求发送到某一台MergeServer；
- MergeServer从RootServer获取请求对应的ChunkServer位置信息；
- MergeServer将请求按照Tablet拆分成多个子请求发送到对应的ChunkServer；
- ChunkServer向UpdateServer请求最新的动态数据，与静态数据进行合并；
- MergeServer合并所有子请求的数据，返回给Client；
分析以上的流程可知，在第2步客户端选择MergeServer时如果调度不均衡会导致某台MergeServer机器过载；在第4步MergeServer把子请求发送到数据所在的ChunkServer时，由于每个tablet会有多个副本，选择副本的策略如果不均衡也会造成ChunkServer机器过载[下面为按照此处存在负载不均衡分析]。由于集群部署会在同一台机器会同时启动ChunkServer和MergeServer，无法简单区分过载的模块。
ChunkServer是存储静态Tablet分片数据的节点，分析其负载不均的原因包含如下可能：
- 数据不均衡： ChunkServer上数据大小的分布是不均衡的，比如某些节点因为存储Tablet分片数据量多少的差异性而造成的不均衡；
- 流量不均衡：数据即使是基本均衡的情况下，仍然会因为某些节点存在数据热点等原因而造成流量是不均衡的。a.存在访问热点：比如热销的商品，这些热点数据会导致ChunkServer成为访问热点，造成了负载不均； b.请求差异性较大：系统负载和处理请求所耗费的CPU\Memory\磁盘IO资源成正比，而资源的耗费一般又和处理的数据量是成正比的，即可能是因为存在某些大用户而导致没有数据访问热点的情况下，负载仍然是不均衡的。
负载均衡算法设计
如果把热点ChunkServer上非热点Tablet的访问调度到其他Server，是可以缓解流量不均问题的，因此我们设计了新的负载均衡算法为：以实时统计的ChunkServer上所有tablet的访问次数为Ticket，每次对Tablet的读请求会选择副本中得票率最低的ChunkServer。
同时考虑到流量不均衡的第二个原因是请求的差异较大问题，ChunkServer对外提供的接口分为Get和Scan两种，Scan是扫描一个范围的所有行数据，Get是获取指定一行数据，因此两种访问方式的次数需要划分赋予不同的权重(α,β)参与最终Ticket的运算：
除此之外，简单的区分两种访问模式还是远远不够的，不同的Scan占用的资源也是存在较大差异的，引入平均响应时间（avg_time）这个重要因素也是十分必要的：
负载均衡算法要求具有自适应性和强的实时性，一方面新的访问要实时累积参与下次的负载均衡的调度，另一方面历史权重数据则需要根据统计周期进行非线性的衰减（y 衰减因子），减少对实时性的影响：
本文摘自：
来源：oschina
链接：https://my.oschina.net/u/994499/blog/111380