zk分布式Job 实现的业务逻辑

zk分布式Job

• 1. 多个服务节点只允许其中⼀个主节点运⾏JOB任务。
  2. 当主节点挂掉后能⾃动切换主节点，继续执⾏JOB任务。
• 实现细节
  • 用zkclien 或者其他第三方写一个程序，放在每一个分布式job对应的服务中， 用来选举一个job作为Master, 让他跑定时任务。 其业务实现逻辑如下
    1. 创建一个根目录zk持久节点 （比如就叫做 /JobMaster）
    2. 创建根目录下的序列化临时节点（ 比如叫做 /MasterCandidate）为什么是临时节点呢？ 因为如果有服务宕机了， zk的临时节点会删除， 那么根节点就可以感知（监听）他的变化, 切设置节点内容为candidateNode
       • 每个分布式job 对应的服务都会创建这么一个序列化临时节点。 比如有三个， 那么就会创建 /MasterCandidate001 , /MasterCandidate002, /MasterCandidate003
    3. 选举master
       • 用CAS的方式/ 或者用zk的方法监听根目录都是一样可以的， 不断监听根节点， 遍历根节点
         • 如果根节点中有值为 masterNode， 那么节点就作为master
         • 如果根节点没有值为masterNode， 那么用节点序列号最小的节点， 他的节点值由candidateNode 编程 masterNode
    4. 每个分布式锁应用， 在执行业务逻辑的时候， 先要判断自己是不是master（怎么判断？ 方式有很多， 比如可以把服务自己的IP也写到zk里面比如“masterNode：192.168.122.111” 或者把 这个创建的临时序列化节点对应的全路劲记录在每一个应用中做对比也行）， 如果是， 就执行， 如果不是， 就不执行