调度系统在设计时应该注意哪些方面

 

    我们接着上篇文章的内容继续说，任务调度系统如何进行设计。

    任务调度系统的高可用性，“定时任务调度系统 2.0” 开发完成以后，仔细地想了一遍，似乎没有什么漏洞了，亲切地询问了加班加点设计和开发的情况，而面对系统最近用户越来越多，老板特别提出了高可用的需求，系统的各个组件也得达到高可用！”“高可用， 拿我的定时调度系统来说，就是说可以部署在多个机器上，一个down掉了，其他的还可以运行。

    如何去实现这一点呢，很简单啊，把定时调度系统部署到多个机器上，形成几个备份就行了，那同一个时刻，有多少个Scheduler 在运行。三个实例都在运行，那一个Job就有可能运行多次，这肯定是不行的，要不让三个实例A,B,C都去访问同一个数据库吧！那三个实例访问同一份数据，肯定会出现冲突，互相覆盖，那就乱套了，其实，实例A，实例B，实例C组成一个类似集群的东西，但是同一时刻，一个Job只能在一个实例上运行。

    比如Job X 从凌晨1点开始，每隔1小时运行一次。那1:00 的时候Job X可能在实例A上运行， 2:00的时候可能在实例B上运行， 3:00的时候可能在实例C上运行。也就是说，这三个实例部分地实现了负载均衡，这是个难办的问题，难道让这三个实例A,B,C之间互相通信？

    也就是说，这变成一个分布式系统下的通信问题了，我们要不用这个数据库做点文章， 反正这个数据库已经存了Job的信息，Trigger的信息，我们就多加一个表吧，就叫LOCKS，这个表里边每一行记录都可以当做一个‘锁’来用，表示不太明白吗？其实很简单，就是数据库的‘行’锁嘛， 比如SELECT * FROM LOCKS where。 LOCK_NAME=‘TRIGGER‘ FOR UPDATE ，这就把那一行记录给锁住了， 别的事务只能等待当前事务commit以后才能访问。

    还不明白吗，比如，服务器A的实例A在一个事务中先执行了上面SQL, 就把那一行给锁住了。当服务器B的实例B也去执行同样的SQL的时候， 只能等待，对吧？ 这不就相当于实例A获得了锁吗，以后任何一个调度器实例想要获取Job的运行时间，设置Job的下一次运行时间的时候，都必须先获得这个锁，这样这些分布式的调度器就不会冲突了，只会运行一个特定时间的Job。

    这样设计出的调度系统具有灵活的设计和扩展性，加上持久化，集群等强大的功能，还不快去试试。 

 

 

更多产品了解

欢迎扫码加入云巴巴企业数字化交流服务群

产品交流、问题咨询、专业测评

都在这里！