分布式计划任务设计与实现

分布式计划任务设计与实现

http://netkiller.github.io/journal/scheduler.html

Mr. Neo Chen (netkiller), 陈景峰(BG7NYT)

中国广东省深圳市龙华新区民治街道溪山美地
518131
+86 13113668890
+86 755 29812080
<[email protected]>

版权 ? 2014 http://netkiller.github.io

版权声明

转载请与作者联系,转载时请务必标明文章原始出处和作者信息及本声明。

文档出处:
http://netkiller.github.io
http://netkiller.sourceforge.net

2014-09-30

摘要

本文主要通过分布式计划任务软件设计讲述分布式软件开发。

我的系列文档

Netkiller Architect 手札 Netkiller Developer 手札 Netkiller PHP 手札 Netkiller Python 手札 Netkiller Testing 手札 Netkiller Cryptography 手札
Netkiller Linux 手札 Netkiller Debian 手札 Netkiller CentOS 手札 Netkiller FreeBSD 手札 Netkiller Shell 手札 Netkiller Security 手札
Netkiller Web 手札 Netkiller Monitoring 手札 Netkiller Storage 手札 Netkiller Mail 手札 Netkiller Docbook 手札 Netkiller Version 手札
Netkiller Database 手札 Netkiller PostgreSQL 手札 Netkiller MySQL 手札 Netkiller NoSQL 手札 Netkiller LDAP 手札 Netkiller Network 手札
Netkiller Cisco IOS 手札 Netkiller H3C 手札 Netkiller Multimedia 手札 Netkiller Perl 手札 Netkiller Amateur Radio 手札 Netkiller DevOps 手札


目录

1. 什么是分布式计划任务

首先我们解释一下计划任务,计划任务是指有计划的定时运行或者周期性运行的程序,我们最常见的就是Linux “crontab”与Windows “计划任务程序”,我们也常常借助他们实现我们的计划任务,因它们的时间调度程序非常成熟,无需我们再开发一套。

2. 为什么采用分布式计划任务

起初,我们也跟大多数人一样采用crontab调度程序,但随着项目越来越大,系统越来越复杂,就抱漏出许多问题。

首先是高可用HA需求,当运行计划任务的服务器一旦出现故障,所有的计划任务将停止工作。

其次是性能问题,越来越多的大型计划任务程序出现,对CPU/IO密集操作,单个节点已经不能满足我们的需求。

让计划任务7*24*365不间断运行,必需有一套行之有效的方案才行,我意识到必须开发一个全新的分布式计划任务框架,这样开发人员无需关注怎样实现分布式运行,集中写任务即可。

我首先提出这个框架必需具备几个特性:

分布式计划任务需具备以下特性

  1. 故障转移,我们至少使用两个节点,当一个节点出现问题,通过健康状态检查程序,另一个节点会自动接管任务。
  2. 分布式运行,一个任务可以运行在多个节点之上,能够同时运行,能够调整运行的前后顺序,能够并发互斥控制。
  3. 节点可动态调整,最少两个节点,可以随时新增节点,卸载节点。
  4. 状态共享,任务可能会涉及的通信,例如状态同步等等。

3. 何时使用分布式计划任务

何时使用分布式计划任务

  1. 遇到性能问题,遇到性能问题你可能首先想到的是分服务器,但很多应用不具备跨服务器运行。
  2. 高可用,一个节点出现故障,另一个节点将接管并继续运行。
  3. 灾备,你可以将两个或两个以上的计划任务节点分别部署在两个以上的机房,通过HA特性任何一个机房出现故障,其他机房仍会继续运行。

4. 分布式计划任务的部署

两个节点部署

两个节点可以实现“主”、“备”方案,队列(排队)运行方案与并行方案,其中并行方案又分为不同运行于异步运行,还涉及到互斥运行。

两个以上节点部署

多节点建议采用队列运行方案,并行方案,但不建议使用互斥并行方案(浪费资源)

5. 谁来写分布式计划任务

当我们的分布式计划任务框架一旦完成,任务的编写部分非常轻松,只需继承框架程序便具备分布式运行的特性。

6. 怎么实现分布式计划任务

计划任务是一个相当复杂的一块,有操作系统计划任务,有运用程序计划任务,有基于TCP/IP的访问的,有基于命令行访问的,有定时执行的,有周期运行的,还有基于某些条件触发运行的。总之解决计划任务灾备,要比web,cache, database 复杂的多。

图 1. 分时方案

严格划分时间片,交替运行计划任务,当主系统宕机后,备用系统仍然工作,只不过处理周期拉长了。缺点:周期延长了

图 2. HA 高可用方案

正常情况下主系统工作,备用系统守候,心跳检测发现主系统出现故障,备用传统启动。缺点:单一系统,不能负载均衡,只能垂直扩展(硬件升级),无法水平扩展

图 3. 多路心跳方案

上面的HA是三层的基于VIP技术实现,下面这个方案我采用多路心跳,做服务级,进程级,IP与端口级别的心跳检测,做正常情况下主系统工作,备用系统守候,心跳检测发现主系统出现故障,备用传统启动,当再次检测到主系统工作,将执行权交回主系统.缺点:开发复杂,程序健壮性要求高

图 4. 任务抢占方案

A,B 两台服务器同时工作,启动需要一前一后,谁先启动谁率先加锁,其他服务器只能等待,他们同时对互斥锁进行监控,一旦发现锁被释放,其他服务谁先抢到谁运行,运行前首先加排他锁。 优点:可以进一步优化实现多服务器横向扩展。 缺点:开发复杂,程序健壮性要求高,有时会出现不释放锁的问题。

图 5. 任务轮循或任务轮循+抢占排队方案

任务轮循或任务轮循+抢占排队方案

  1. 每个服务器首次启动时加入队列。
  2. 每次任务运行首先判断自己是否是当前可运行任务,如果是便运行。
  3. 否则检查自己是否在队列中,如果在,便推出,如果不在队列中,便加入队列。

6.1. 分布式互斥锁

互斥锁也叫排它锁,用于并发时管理多进程或多线程同一时刻只能有一个进程或者线程操作一个功能。如果你理解什么是互斥锁,便很容易理解分布式锁。

我们将进程,线程中的锁延伸到互联网上,实现对一个节点运行的进程或线程加锁,解锁操作。这样便能控制节点上进程或线程的并发。

+------------------+                             +------------------+
| Server A         |                             | Server B         |
+------------------+      +---------------+      +------------------+
| Thread-1         |      | Cluster Mutex |      | Thread-1         |
| Thread-2         |----> +---------------+ <----| Thread-2         |
| Thread-3         |      | A Thread-2    |      | Thread-3         |
+------------------+      +---------------+      +------------------+
                                  |
                                  V
                          +---------------+
                          | Cluster Mutex |
                          +---------------+
                          | A Thread-2    |
                          +---------------+

上图中有两台服务器上运行任务,其中Server A 的 Thread-2 做了加锁操作,其他程序必须等待它释放锁才能运行。

你会问如果 Server A 宕机怎么办,是否会一直处于被锁状态?我的答案是每个锁都有一个超时阀值,一旦超时便自动解锁。

另外我们还要考虑“域”的问题,你也可以叫它命令空间,主要是防止锁出现同名被覆盖。

6.2. 队列

排队运行

+------------------+                             +------------------+
| Server A         |                             | Server B         |
+------------------+      +---------------+      +------------------+
| Thread-1         |      | Task Queue A  |      | Thread-1         |
| Thread-2         |----> +---------------+ <----| Thread-2         |
| Thread-3         |      | A Thread-2    |      | Thread-3         |
+------------------+      | B Thread-1    |      +------------------+
                          | B Thread-3    |
                          | A Thread-3    |
                          +---------------+
                                  |
                                  | <sync>
                                  V
                          +---------------+
                          | Task Queue B  |
                          +---------------+
                          | A Thread-2    |
                          | B Thread-1    |
                          | B Thread-3    |
                          | A Thread-3    |
                          +---------------+

从上图中我可以看到Task Queue中排队情况,运行是自上而下的。

注意Task Queue 需要两个节点,它们是主从结构,A 节点实时向 B 节点同步sh状态。如果 A 节点出现故障, B 节点立即取代 A 节点。

6.3. 其他

计划任务可以分布式运行了,但并不能保证万无一失,配套其他服务器也要做调整。例如数据库,缓存等等。

时间: 2024-10-09 03:26:22

分布式计划任务设计与实现的相关文章

hadoop分布式架构和设计

引言 Hadoop分布式文件系统(HDFS)被设计成适合运行在通用硬件(commodity hardware)上的分布式文件系统.它和现有的分布式文件系统有很多共同点.但同时,它和其他的分布式文件系统的区别也是很明显的.HDFS是一个高度容错性的系统,适合部署在廉价的机器上.HDFS能提供高吞吐量的数据访问,非常适合大规模数据集上的应用.HDFS放宽了一部分POSIX约束,来实现流式读取文件系统数据的目的.HDFS在最开始是作为Apache Nutch搜索引擎项目的基础架构而开发的.HDFS是A

从Storm和Spark Streaming学习流式实时分布式计算系统的设计要点

0. 背景 最近我在做流式实时分布式计算系统的架构设计,而正好又要参见CSDN博文大赛的决赛.本来想就写Spark源码分析的文章吧.但是又想毕竟是决赛,要拿出一些自己的干货出来,仅仅是源码分析貌似分量不够.因此,我将最近一直在做的系统架构的思路整理出来,形成此文.为什么要参考Storm和Spark,因为没有参照效果可能不会太好,尤其是对于Storm和Spark由了解的同学来说,可能通过对比,更能体会到每个具体实现背后的意义. 本文对流式系统出现的背景,特点,数据HA,服务HA,节点间和计算逻辑间

大型分布式网站架构设计与实践

大型分布式网站架构设计与实践(一线工作经验总结,囊括大型分布式网站所需技术的全貌.架构设计的核心原理与典型案例.常见问题及解决方案,有细节.接地气/京东:大型分布式网站所需技术的全貌.架构设计的核心原理与典型案例.常见问题及解决方案) 陈康贤 著   ISBN 978-7-121-23885-7 2014年9月出版 定价:79.00元 460页 16开 编辑推荐 --作者一直奋战在阿里巴巴及淘宝网一线,书中所讲是其亲身经验的总结,显得更加实战和珍贵. --全面介绍大型分布式网站架构所涉及的技术细

分布式系统开发常见问题-1. session的复制与共享 2. 分布式缓存的设计

1. session的复制与共享 在web应用中,为了应对大规模访问,必须实现应用的集群部署.要实现集群部署主要需要实现session共享机制,使得多台应用服务器之间会话统一, tomcat等多数主流web服务器都采用了session复制以及实现session的共享. 但问题还是很明显的: 在节点持续增多的情况下,session复制带来的性能损失会快速增加.特别是当session中保存了较大的对象,而且对象变化较快时,性能下降更加显著.这种特性使得web应用的水平扩展受到了限制. session

CYQ.Data V5 分布式自动化缓存设计介绍(二)

前言: 最近一段时间,开始了<IT连>创业,所以精力和写的文章多数是在分享创业的过程. 而关于本人三大框架CYQ.Data.Aries.Taurus.MVC的相关文章,基本都很少写了. 但框架的维护升级,还是时不时的在进行中的,这点从开源的Github上的代码提交时间上就可以看出来了. 毕竟<IT连>的后台WebAPI,用的是Taurus.MVC,后台系统管理用的是Aries. 不过今天,就不写创业相关的文章了,先分享篇技术类的文章. CYQ.Data 分布式自动缓存 之前写过一篇

《大型分布式网站架构设计与实践》

读后感 逐字逐句看完<大型分布式网站架构设计与实践>第2章,意犹未尽!如标题所言,这是一本“真材实料的分布式资料”,它与我看过的分布式书籍(如<大型网站系统与Java中间件实践>)不同,本书重技术兼并理论,给了新人入手的方向. 我最最感动的是书中介绍了很多分布式的“干货”:分布式缓存可以用memcache.数据库水平/垂直拆分技术.分布式存储可以HBase/Redis等.消息通道可以用ActiveMQ.搜索引擎Lucene/Solr等.当然每一种技术都不是一本书能说完的,作者至少给

分布式存储系统架构设计,应该遵循什么样的原则?

分布式存储系统,本质是将数据分散存储在多台独立的x86设备上.传统的网络存储系统通常采用集中的存储服务器存放数据,存储服务器很容易成为系统性能的瓶颈,也容易成为可靠性和安全性的瓶颈.分布式存储系统采用可扩展的系统结构,利用多台x86服务器分担存储负荷,利用位置服务器定位存储信息,不但提高了系统的可靠性.可用性和存储读写效率,还易于扩展. 传统架构VS分布式架构 分布式架构I/O 分布式存储系统架构设计核心原则 1.分布式.无共享架构 采用基于策略的分布式哈希表数据路由算法,使得客户端无需查找元数

从JAVA多线程理解到集群分布式和网络设计的浅析

对于JAVA多线程的应用非常广泛,现在的系统没有多线程几乎什么也做不了,很多时候我们在何种场合如何应用多线程成为一种首先需要选择的问题,另外关于java多线程的知识也是非常的多,本文中先介绍和说明一些常用的,在后续文章中如果有必要再说明更加复杂的吧,本文主要说明多线程的一下几个内容: 1.在应用开发中什么时候选择多线程? 2.多线程应该注意些什么? 3.状态转换控制,如何解决死锁? 4.如何设计一个具有可扩展性的多线程处理器? 5.多线程联想:在多主机下的扩展-集群? 6.WEB应用的多线程以及

聊一聊分布式锁的设计

起因 前段时间,看到redis作者发布的一篇文章<Is Redlock safe?>,Redlock是redis作者基于redis设计的分布式锁的算法.文章起因是有一位分布式的专家写了一篇文章<How to do distributed locking>,质疑Redlock的正确性.redis作者则在<Is Redlock safe?>文章中给予回应,一来一回甚是精彩.文本就为读者一一解析两位专家的争论. 在了解两位专家的争论前,让我先从我了解的分布式锁一一道来.文章中