文件名称：负载均衡-htrc110 用户手册
文件大小：1.33MB
文件格式：PDF
更新时间：2024-06-30 06:35:45
分布式
3.5 负载均衡 负载平衡是一个研究课题，难点在于负载平衡的策略和参数调整，工程化的难度不大， 和数据挖掘相关的项目有些类似，需要不断地做假设并做实验验证。 负载平衡有两种思路，一种是集群总控机根据负载情况全局调度，另一种思路是采用 DHT 方法。 第二种思路可以参考 Amazon Dynamo 的论文，DHT 算法中每个节点分配的 token 决定 了数据及负载的分布。假设 DHT 环中有 S 个节点，一种比较好的 token 分配方法是将整个 Hash 空间分成 Q 等份，Q >> S，token 分配维持每个节点分配 Q/S 个 token 的特性。当节点 下线时，需要将它所服务的 token 分配给其它节点，从而保持每个节点包含 Q/S 个 token 的 特性；同样，当新节点上线时，也需要从集群中已有的节点获取 token 使得最终维持每个节 点 Q/S 个 token 的特性。 第一种思路需要工作机通过 heartbeat 定时将读、写个数，磁盘，内存负载等信息发送 给主控机，主控机根据负载计算公式计算出需要迁移的数据放入到迁移队列中等待执行。负 载平衡的时候需要注意控制节奏，比如一台工作机刚上线的时候，由于负载最轻，如果主控 机将大量的数据迁移到新上线的机器，由于迁移过程不能提供写服务，整个系统的对外表现 性能会因为新增机器而变差。一般来说，从新机器加入到集群负载达到比较均衡的状态需要 较长一段时间，比如 30 分钟到一个小时。 3.6 Chubby Chubby 是 Google 的 Paxos 实现，Paxos 靠谱的实现不多，Chubby 毫无疑问是做的最优秀的。 Chubby 通过类似文件系统接口的方式给用户暴露分布式锁服务。我们先看看应用是如何使 用 Chubby 服务的。 在 GFS/Bigtable 论文中，我们至少能够看到有如下几处使用了 Chubby。 1, Master 选举。Master 宕机时，与 Master 保持强同步的 Slave 切换为 Master 继续提供服务。 在这个过程中，Master和 Slave都定时向Chubby请求成为Master的锁，Master锁有一个 Lease 的期限，如果 Master 正常，一定会在 Master 锁没有过期的时候申请延长锁的时间，继续提 供服务。当 Master 宕机且锁的 Lease 过期时，Slave 将抢到 Master 锁切换为 Master。 2, tablet 服务。为了保证强一致性，一个 tablet 同一时刻只允许被一个 Tablet Server 加载提 供服务。每个 tablet server启动时都向 Chubby服务获取一个锁，每当 Master发现 tablet server 出现异常时，它也尝试获取该 Tablet server 的锁。Master 和 Tablet Server 二者只有一个节点 能够获取到锁，如果锁被 Master 获取，可以确定 Tablet Server 已经宕机，此时可以将它服 务的 tablet 分配给其它机器。 3, 存储 Bigtable 表格的 schema 信息。由于 Chubby 可以认为是一个一致的共享存储，并且 schema 的访问压力不大，Chubby 可以存储 schema 信息。 我们再来看看 Chubby 内部大致是如何实现的。Chubby 一般有五台机器组成一个集群，可以 部署成两地三机房，这样任何一个机房停电都不影响 Chubby 服务。Chubby 内部的五台机器 需要通过实现 Paxos 协议选取一个 Chubby Master 机器，其它机器是 Chubby Slave，同一时 刻只有一个 Chubby Master。Chubby 相关的数据，比如锁信息，客户端的 Session 信息都需 要同步到整个集群，采用半同步的做法，超过一半的机器成功就可以回复客户端。每个