技术社区 > 技术实践｜技术实践｜分布式时间锁

技术实践｜技术实践｜分布式时间锁

2023年06月13日

前言

K8s client-go中，源生自带了一个leader库，便于实现分布式时间锁。

以K8s原生的controller-manager组件为例，当有三台master机器时，默认会运行三个controller-manager实例，但只有一个在干活，另外两个处于备用状态。而这个功能的实现，就依赖于分布式时间锁。

所有相关配置如下图所示：

锁的持有者，会每隔retryPeriod更新锁的有效期，表示它一直在持有这把锁。

特别说明下两个参数：

一. leaseTimeout

举个例子：现在有个房间，我要求当有人进入房间时，下一个人至少等待1小时才可进入房间。这时，我们可以将leaseTimeout设置为1小时，每当有人进入房间，则将房门上的时候改为当前时间。下一个人准备进入时，必须检查房门上的时间距离当前时间超过leaseTimeout。
之所以要这样设计，是因为在分布式情况下，只有程序活着的时候才可以要求它干什么，而一旦它异常了，它就失控了。而为了防止在它异常时，其它活着的程序可以正常接替它，所以就约定了leaseTimeout，一旦超过这个时间，则直接认定它异常，可以接管。

二. renewDeadline

上面的约定，无法防止脑裂。因为锁持有者在leaseTimeout中未更新锁，并不代表它已经挂了，它可能只是因为其它原因无法更新锁，或者程序夯住了，之后它可能再恢复。而如果它在别人接替它后，原持有者再恢复运行，则会导致脑裂，为了防止这种情况发生，针对锁持有者就设置了renewDeadline
如果锁持有者如果无法在renewDeadline时间内完成锁的更新，则要求锁持有者强制释放锁，程序退出。
所以renewDeadline必须比leaseTimeout小