随着大规模并行分布处理系统，特别是网络工作站集群的广泛应用。如何采取有效的调度策略来平衡各节点的负载，从而提高整个系统资源的利用率，已成为人们的研究热点。集群具有可扩展性、 高可用性、高性能、高性价比等优点，作为存储区域网的存储设备具有天生的优势。随着PC机的发展，硬盘的价格越来越低，其存储容量越来越大，每台PC机也可配置多块硬盘，且可扩充能力极高，作为集群中的节点管理也相当方便，并具有一定的计算能力。如何采取有效的调度策略来平衡各节点的负载，从而提高整个系统资源的利用率，成为研究的重点。
负载均衡的目标
- 要保持所有处理机处于忙碌状态，而不是保证他们平分负载
- 提供最短的平均任务响应时间
- 具有一定的自适应性，能适于变化的负载
- 是可靠的，避免负载的轻重跳跃，避免处理机抖动，减少不必要的通讯开销
影响分布式系统性能的因素
主要有这些因素影响着分布式系统的性能：网络延迟、数据通信效能、CU处理能力、任务的分割、无法预算处理时间、任务的颠簸等等。我们在寻求分布式计算调度算法时，就是有针对性的以解决这些问题为目的，从各个角度，不同侧面，利用一种或者集中方法结合起来的形式，从而达到最优解，使得系统效率相对最高。
几种基本的调度算法
获得网络负载均衡有几个基本的方法，这些方法可以结合使用，形成更高级的算法，以下是几种基本的方法：
轮转法
轮转算法是所有算法中最简单也最容易实现的一种方法，轮转法简单地在一串节点中线性轮转，平衡器将新请求发给节点表中的下一个节点。如此连续下去。这个算法在DNS域名轮询中被广泛使用。但是简单应用轮转法DNS转换，可能造成持续访问同一节点，从而干扰正常的网络负载平衡，使网络平衡系统无法高效工作。轮转法典型适用于集群中所有节点的处理能力和性能均相同的情况，在实际应用中，一般将它与其他简单方法联合使用时比较有效。
加权法
加权算法根据节点的优先级或权值来分配负载。权值是基于各节点能力的假设或估计值。加权方法智能与其它方法结合使用，是它们一个很好的补充。
散列法
散列法也叫哈希法（Hash），通过单射不可逆的Hash函数，按照某种规则将网络请求发往集群节点。与简单加权法相似。
最少连接法
针对TCP连接进行在最少连接法中，管理节点纪录目前所有活跃连接，把下一个新的请求发给当前含有最少连接数的节点。缺陷是某些应用层会话要消耗更多的系统资源，尽管集群中连接数平衡了，但是处理量可能差别很大，连接数无法反映出真实的应用负载。
最低缺失法
在最低缺失法中，管理节点长期纪录到各节点的请求情况，把下个请求发给历史上处理请求最少的节点。与最少连接法不同的是，最低缺失记录过去的连接数而不是当前的连接数。
最快响应法
管理节点记录自身到每一个集群节点的网络响应时间，并将下一个到达的连接请求分配给响应时间最短的节点。在大多数基于LAN的集群中，最快响应算法工作的并不是很好，大多数与以太网连接的现代系统，有部分负载时，可在1ms或更短时间内响应，这使得这种方法没有意义。
调度任务解决方案
单机定式任务调度的问题
在很多应用系统中我们常常要定时执行一些任务。比如，订单系统的超时状态判断、缓存数据的定时更新、定式给用户发邮件，甚至是一些定期计算的报表等等。常见的处理方式有线程的while(true) 和sleep组合、使用Timer定时器触发任务又或者是使用quartz框架。貌似这些方法可以完美的解决方案，为什么还需要分布式呢？主要有如下两点原因：
1.高可用：单机版的定式任务调度只能在一台机器上运行，如果程序或者系统出现异常就会导致功能不可用。虽然可以在单机程序实现的足够稳定，但始终有机会遇到非程序引起的故障，而这个对于一个系统的核心功能来说是不可接受的。
2.单机处理极限：原本1分钟内需要处理1万个订单，但是现在需要1分钟内处理10万个订单；原来一个统计需要1小时，现在业务方需要10分钟就统计出来。你也许会说，你也可以多线程、单机多进程处理。的确，多线程并行处理可以提高单位时间的处理效率，但是单机能力毕竟有限（主要是CPU、内存和磁盘），始终会有单机处理不过来的情况。
这个时候就需要分布式的定时任务来实现了。业内常用的分布式定式任务解决方案主要有quartz、淘宝的TBSchedule和当当的elastic-job。
quartz的集群解决方案
quartz的单机版本大家应该比较熟悉，它的集群方案是使用数据库来实现的。集群架构如下：
上图三个节点在数据库中都拥有同一份Job定义，如果某一个节点失效，那么Job会在其他节点上执行。由于三个节点上的Job执行代码是一样的，那么怎么保证只有在一台机器上触发呢？答案是使用了数据库锁。在quartz的集群解决方案里有张表scheduler_locks，quartz采用了悲观锁的方式对triggers表进行行加锁，以保证任务同步的正确性。一旦某一个节点上面的线程获取了该锁，那么这个Job就会在这台机器上被执行，同时这个锁就会被这台机器占用。同时另外一台机器也会想要触发这个任务，但是锁已经被占用了，就只能等待，直到这个锁被释放。之后会看trigger状态，如果已经被执行了，则不会执行了。
简单地说,quartz的分布式调度策略是以数据库为边界资源的一种异步策略。各个调度器都遵守一个基于数据库锁的操作规则从而保证了操作的唯一性。同时多个节点的异步运行保证了服务的可靠。但这种策略有自己的局限性：集群特性对于高CPU使用率的任务效果很好，但是对于大量的短任务，各个节点都会抢占数据库锁，这样就出现大量的线程等待资源。这种情况随着节点的增加会越来越严重。
另外，quartz的分布式只是解决了高可用的问题，并没有解决任务分片的问题，还是会有单机处理的极限。
PowerJob
PowerJob（原OhMyScheduler）是全新一代分布式调度与计算框架，能让您轻松完成作业的调度与繁杂任务的分布式计算。
主要特性 使用简单：提供前端Web界面，允许开发者可视化地完成调度任务的管理（增、删、改、查）、任务运行状态监控和运行日志查看等功能。
定时策略完善：支持CRON表达式、固定频率、固定延迟和API四种定时调度策略。
执行模式丰富：支持单机、广播、Map、MapReduce四种执行模式，其中Map/MapReduce处理器能使开发者寥寥数行代码便获得集群分布式计算的能力。
DAG工作流支持：支持在线配置任务依赖关系，可视化得对任务进行编排，同时还支持上下游任务间的数据传递 执行器支持广泛：支持Spring Bean、内置/外置Java类、Shell、Python等处理器，应用范围广。运维便捷：支持在线日志功能，执行器产生的日志可以在前端控制台页面实时显示，降低debug成本，极大地提高开发效率。依赖精简：最小仅依赖关系型数据库（MySQL/Oracle/MS SQLServer...），扩展依赖为MongoDB（用于存储庞大的在线日志）。高可用&高性能：调度服务器经过精心设计，一改其他调度框架基于数据库锁的策略，实现了无锁化调度。部署多个调度服务器可以同时实现高可用和性能的提升（支持无限的水平扩展）。故障转移与恢复：任务执行失败后，可根据配置的重试策略完成重试，只要执行器集群有足够的计算节点，任务就能顺利完成。适用场景 有定时执行需求的业务场景：如每天凌晨全量同步数据、生成业务报表等。有需要全部机器一同执行的业务场景：如使用广播执行模式清理集群日志。有需要分布式处理的业务场景：比如需要更新一大批数据，单机执行耗时非常长，可以使用Map/MapReduce处理器完成任务的分发，调动整个集群加速计算。有需要延迟执行某些任务的业务场景：比如订单过期处理等。设计目标 PowerJob 的设计目标为企业级的分布式任务调度平台，即成为公司内部的任务调度中间件。整个公司统一部署调度中心 powerjob-server，旗下所有业务线应用只需要依赖 powerjob-worker 即可接入调度中心获取任务调度与分布式计算能力。
elastic-job
Elastic-Job当当开源的分布式调度解决方案，由两个相互独立的子项目Elastic-Job-Lite和Elastic-Job-Cloud组成。Elastic-Job-Lite定位为轻量级无中心化解决方案，使用jar包的形式提供分布式任务的协调服务。一般我们只要使用Elastic-Job-Lite就好。
分布式任务调度平台 XXL-JOB
XXL-JOB是一个轻量级分布式任务调度平台，其核心设计目标是开发迅速、学习简单、轻量级、易扩展。现已开放源代码并接入多家公司线上产品线，开箱即用。
同类产品对比
关注公众号 soft张三丰
