分布式锁

master-worker模式 

涉及三种角色:

1. master,用于检测新的task、worker的添加,将新的task分配给worker处理

2. worker,将自己注册到系统,被master发现后,监控task

3. client,客户端新增task,等待服务响应

master

1. 我们先创建一个master节点, -e表示我们创建的是一个临时节点, xxx表示我们可以存储数据

create  -e  /master  "xxx" 

2. 当另外一个服务也尝试创建master节点时,会提示节点已经存在

我们一般将此节点作为备用,监听master被删除的事件,以便及时补位。

stat  /master  true 

3. 当master节点被删除,会有事件触发,此时继续尝试创建master节点,成功补位

workers, tasks, assign

这里先补充创建一些必要的节点,真实应用中应当在准备阶段完成:

create  /workers  ""

create  /tasks  ""

create  /assign  ""

 在创建完成后,master节点需要监听workers和tasks节点的变动,因为master需要关注这些变动,才能完成task的分配。

ls  /workers  true

ls  /tasks  true

这里的true就是创建watch: 

worker 

将自己注册到/workers下面,这里使用-e表示临时节点

create  -e  /workers/worker1   "xxx"

然后创建一个新的节点到assign下面,用于等待分配任务,并监听这个节点

create  /assign/worker1  ""

ls  /assign/worker1  true

这里创建的是持久化节点,防止因为连接断开导致数据丢失。 

Client 

客户端创建新的task,这里使用有序的创建方式:

create  -s  /tasks/task-  "here is task data"

 这里使用-s表示有序节点

 对这个task加watch

ls  /tasks/task-000000000  true

当节点创建完毕,master会收到提示:

 此时master需要分配任务了:

ls  /tasks

ls  /workers

create  /assign/worker1/task-000000000  ""

 此时,worker也收到消息

worker开始查看task

ls  /assign/worker1

当处理完成,创建一个status节点

create  /tasks/task-000000000/status  "done"

 客户端收到通知后,查询task和assign,确认是否处理完毕

get  /tasks/task-000000000

get  /tasks/task-000000000/status

Logo

权威|前沿|技术|干货|国内首个API全生命周期开发者社区

更多推荐