我眼中的云计算-调度/负载均衡

        可以想见，“实现任务到资源的最优分配”- 调度是“分而治之”模式的核心问题，而且调度粒度越精细，资源消耗的控制才能越精确；但是精细粒度的任务调度也带来更高的调度开销，需要根据业务情况权衡；调度最终和最重要的目标是吞吐量(指定时间段内完成的任务数，以及用户分级/业务分组的能力/流量控制)，响应时间(这里主要考虑处理时间，暂不考虑传输时间)；

        对于调度器而言，资源是客观存在的硬件限制，主要有：

计算能力，即CPU，现在关心的主要是物理内核数；
内存容量，刨开操作系统和其它系统软件的占用外，实际的可用数，毕竟如果引发swap操作将使执行性能急剧下降；
内存带宽，硬件架构的升级，如Nehalem架构中QPI与之前的前端总线相比带宽提升了一倍；
网络带宽，分布式系统的桥梁，大量数据传输时的瓶颈；

而任务则是要利用资源解决的问题，相对资源而言比较复杂，可能存在的情况有：

任务之间存在依赖关系，如用户提交数据后的查询操作，自己必须可见；再如早期的session stick，同一个用户的请求分配到相同的服务器处理；；
任务对资源的占用有差别，热点数据分布不均匀时，对计算或存储的压力不一致；；
任务对不同资源的利用程度不同，有计算型的任务和内存型的任务，如加解密任务，数据缓存任务；
硬件资源有限，物理节点的计算能力/存储空间/网络带宽都是有限的；
任务对处理资源有要求，只能在特定资源上执行，在分布式环境下，数据按照一定规则切分存储，任务的分配必须按照数据切分的规则进行，二次重入；

罗列完资源和任务后，该说说用于平衡资源和任务的调度算法了，常用的调度算法有：

轮询(Round Robin)，轮叫的方式依次将请求调度不同的服务器，算法简单，保持最后分发节点的变量在高并发时有性能隐患，且忽略物理节点的性能差别；
随机(Random)，随机把请求调度不同的服务器，消除了轮询的同步资源隐患；
权重(Weight)，在轮询的基础上增加了物理节点性能的考虑，可以为性能好的物理节点分配更多的任务，静态调度，不关心实际任务的资源消耗；
Hash(IP/Cookie)，可以基于请求的目的IP/源IP/Cookie进行hash运算，把请求分发到相应的物理节点，在用户量大的基础上可以较好的实现均衡；
负载(System Load)，根据物理节点的实时负载和响应情况，调整节点间处理请求的比例，动态调度；

分布式系统架构里，调度算法所在的位置也有多种选择，大致有以下几种：

服务端模式，用硬件实现负载均衡，结构简单性能好，但比较贵且存在单点问题；
客户端模式，采用客户端包来软件实现分发算法，配置多个分发节点情况，可进行失效转移，比如Memcached 客户端；这种方式避免了单点风险，能更好的平衡压力，但是扩展和升级时有限制；
客户端模式+管理节点，配制节点以及算法都可以采用集中的Master来管理和维护，包括心跳检测等手段由Master来实现；客户端包的实现相对简化，提高了客户端的可扩展性和可维护性，但引入了额外的Master节点，增加了系统复杂度，需要实现Master失效时的容错策略，通过客户端包缓存的使用，可以允许Master短暂失效；