Quartz Job Scheduling Framework[翻译]第十一章. Quartz 集群 (第一部分)

第十一章. Quartz 集群

不可避免的,我们还是要说到集群。虽然单个 Quartz 实例能给予你很好的 Job 调度能力,但它不能令典型的企业需求,如可伸缩性、高可靠性满足。假如你需要故障转移的能力并能运行日益增多的 Job,Quartz 集群势必成为你方言的一部分了。本章就告诉你如何使用 Quartz 的集群能力来更好的支持你的业务需求,并且即使是其中一台机器在最糟的时间崩溃了也能确保所有的 Job 得到执行。

一. 集群对 Quartz 来说意味着什么?

集群扮演着运行一个组件或应用的多个实例,它们以透明的方式提供服务。集群是企业范畴的事物,而不局限于 Java 的世界里。当部署 J2EE 应用时,例如,供应商为应用服务器提供了集群的能力,以便于像 EJB、JNDI 和 Web 组件能获得高可用性。然当客户端请求这些服务时候,它们就能更可靠的提供服务。

这和一些用户要求他们的 Quartz 应用的行为是完全一样的。用户希望构建并设定 Quartz 应用是当一个 Job 一定要执行时,它就要得到执行。随着你的 Quartz 应用变得更普及,还要安排不断增多的需求,Quartz 应用的集群将能让你安下心来,你能处理你的需求并确保一切按计划进行。而且你只需要付出很小的努力来搭建和维护便能得到这些好处。

·Quartz 应用集群的好处

集群的 Quartz 应用比起非集群环境,能提供两个关键的好处

    ·高可用性

    ·伸缩性

·高可用性

高可用性的应用是指能以高百分率的时间服务于客户。在某些情况下,可能就是一周 7 天,一天 24 小时。对于其他的应用,可能只是“尽量多的时间”。可用性通常表示为在 0 到 100 之间的一个百分数。一个应用也许经常失败但仍可达到高可用性。另一方面,一个应用可能只菪掉一次但是随后处在菪掉状态很长时间,可用性就低了。计量可用性不是应用的菪掉次数,而是菪掉状态经历总的时间。显然,作为开发者来说,我们希望我们的应用从不失败。这也是可以出现的,不过你必须对此有所准备。

硬件和软件的可用性级别有时候是以九的级别来衡量的。九的级别指示了在可用性百分数中有多少个数字九。例如,99.999 说的是达到五个九的级别,因为这里有五个九。表 11.1 显示了在某一级别的近似宕机时间百分比。

表 11.1. 应用的可用性级别

可用性 每年近似的宕机小时数
99% 87.6 小时
99.9% 8.8 小时
99.99% .9 小时
99.999% 0.09 (大约 5 分钟)

看到了表 11.1,你或许能得到结论,四个九的级别(大约每年宕机一小时) 就是一个令人叹为观止的高用性了,通常就是这样子的。然而,假如是一个 Quartz 应用,它是被设计来传送发票的,要是它连续 12 天里每天宕机 5 分钟的话,那些发票就会被认作过期,那么 生意上就会承受大量的损失,你也很可以要去寻到一份新的工作了(我可不是说的 Quartz 的那种 Job)。这不仅仅是宕机时间的总和,而是一旦宕机,程序就要罢工。

其中一个能获得尽可能高可用性的分子就是故障转移的概念。故障转移确保了即使是系统出现故障时,其他冗余的服务组件能处理请求,使得客户端(或 Job) 能从失败中恢复过来。从故障组件或服务中倒换到另一相同功能的组件或服务的能力增强了应用的可用性。这一切换或故障转换应当是透明的。

·伸缩性

伸缩性意味着为增进应用自身能力,可以动态增加新的资源(如硬件) 到应用环境中的能力。在一个可伸缩的应用中,为达到增进能力的做法不涉及到改变代码或是设计。

获得伸缩性可不是变魔术那样。一个程序必须从一开始就要有合理的设计;支撑额外的能力通常要耗费管理上的努力来增加新的硬件(如内存) 或是启动程序更多的实例。

·负载均衡

作为获得更好的伸缩性,在集群中跨节点分布式工作的能力是很重要的。把工作散布开能确保集群中的每一个节点会共同承担工作负载。想像一下假如集群中所有的工作都指定给某一个节点,同时其他节点处于空闲状态。继续这种模式,终究这个过载的节点将无法处理增加的工作而导致失败。

最好的场景是,工作均匀的分布在集群中的所有实例上。有几个不同的算法能用来分布工作,包括随机法、循环法和加权循环法,只列了这些。

当前,Quartz 使用的是随机算法来提供最低限度负载均衡的能力。集群中的每个 Scheduler 实例尝试 Scheduler 所允许尽量快的速度触发已布署的 Trigger。Scheduler 实例通过触发自己的 Trigger 来竞争(使用数据库锁) 得到执行 Job 的权利。当某个 Job 的 Trigger 被触发时,别的 Scheduler 实例就不再试图触发这一 Trigger 了,直到下一次触发时间的到来。这种机制可能比你从它的简单性所推断的还要工作的更好。这是因为 Scheduler "多数时候是忙的",作为至少的一个都有希望找到下次要触发的 Job。因此,这样就可能获得近乎完全合理的负载均衡性。

类别: Quartz. 标签: , . 阅读(359). 订阅评论. TrackBack.

Leave a Reply

Be the First to Comment!

avatar