用施工队的方式理解负载均衡

    今天听Lunch同学分享负载均衡的概念，他引入“施工队”的概念，起到深入浅出的效果。特记录如下：

做集群负载均衡的目的：

1. 提升系统性能，增加整体的吞吐量；

2. 提供灵活的策略，统计现有资源，按实时资源情况进行任务调度；

3. 增强系统可靠性，在部分节点故障时，仍能保证系统和任务正常运行；

4. 提高系统可扩展性，可在系统运行时增加和移除部分节点；

5. 节约成本，以多个低成本设备代替高成本设备，实现同样性能；

数据平台集群构思：

为了最大限度的提高集群平台的灵活性，扩展性，通用性，提出“施工队”的概念。

我们进群中的每一个节点都看成是一个在外找散活的工人，他有能力独自完成一个工程，因为他什么都要干，要花很长的时间，当然，如果业主不着急可以让他慢慢干，但是通常业主等不了那么多时间，如果期间这个工人病了或者请假了，甚至直接走人了，那这个工程就不知道要做多久了。

这个时候聚在一起打牌等活的工人中，有一个提出一个建议，大家组成一个施工队，大家一致同意了，那么第一个提出建议的人就当了施工队的老大，他原来也是一个普通的工人，他也可能会出现溜号的情况，所以他还选了一个副手，平时和工人一起工作，在他不在的时候可以接替他的工作，保证施工队能正常进行工程。

要开始干活了，施工队老大出去接很多活了，有装修的，有大厦定期保养的，有专门去卸货的等等，接活回来后，老大和副手一起开始分析了，首先让这些工人都向他做个自我介绍，自己都擅长些什么，比如有的能挑300斤，有的手脚麻利，知道这些工人的工作能力了。在看看这些活都具体有些什么内容，每个活要几个人干，哪些工人适合干哪些活，要做到什么样才能算完工，工程详细清单出来后，队长和副队长都保存一份。好了，分析完了以后开始发放任务了，活少的时候可能有的工人会领不到任务，领到任务的工人就开始去干活了。

开始干活了，有的工程是包工包料的，那么工程开始前需要施工队先把材料准备好，那么很多工程中都用到比如水泥啊、灰浆啊之类的材料，材料准备好了以后就需要有地方放，工程对就租了一个仓库，用来存放工程队的材料。

干活期间，每个工人都会经常向队长报告自己的工作进度，和自己的体力情况，如果体力不行了，或者直接请假了，队长会调整他的任务，分配给其他比较轻松的工人。如果队长请假了，那么副队长升为队长，然后从工人中选取一个人填补副队长的位置。

任务运行模式：

1. 服务性任务

2. 周期性任务

3. 触发性任务

数据来源：

1. FTP

2. DB

3. WebService/Server

4. Socket/Server

5. Corba/Server

6. Telnet

7. 文件扫描

8. 手工录入

数据格式：

1. Xml

2. BinaryFile

3. String

4. WebService

5. Corba StructuredEvent

6. DB ResultSet

7. 其他厂家数据格式

数据量：

1. 一次一个超大数据/文件

2. 一次多个中等数据/文件

3. 一次一个中等数据/文件

4. 高频率一次一个小数据

5. 一次一个小数据

从以上列出的当前业务中的一些情况，需要集群去做的事情有：

1. 在集群启动后，由集群自行产生或指定一个节点为Leader，一个节点作为vice-Leader。如果leader或vice-leader异常后，集群应该立刻产生新的Leader或vice-leader。Leader作为集中群的核心和任务发起点，对整个集群的所有节点进行管理和调度。Vice-集群中其他的节点称为Follower，在follower启动后主动向Leader注册，并提交当前的资源报告。并且在后期会定时提供资源报告。

2. 服务性任务需要固定的入口点，在集群外围如果没有提供一个统一入口点，那集群中就需要固定某些节点去执行服务性任务。

3. 针对一次超大数据文件，需要把超大文件按照一定规律分拆成多个小文件，把当前任务分拆成多个子任务，并把子任务分发给多个节点。

4. 针对一次多个中等数据文件，把任务拆分成多个子任务，分发给多个节点。

5. 需要支持分布式文件系统，支持文件分拆和文件共享。

6. （是否需要）支持共享高速缓存，在文件不落地的情况下实现数据缓存的共享和任务的分发。

7. 传统集群的特点是每个节点都具备系统的完善功能，能够独立完成运行任务。分布式集群是的特点是每个节点具备的是系统中的部分功能，精专于功能内的任务运行。

负载均衡集群需要的要素：

角色，状态，资源，任务，数据，策略，通讯

转载于:https://my.oschina.net/u/2455518/blog/536613