分布式锁实现
demo参考：https://github.com/etcd-io/etcd/blob/master/clientv3/concurrency/example_mutex_test.go
基本原理：在etcd事务中查询key的revision是否为0，等于0则创建key和value，表示抢锁成功；不等于0则返回最早创建该key的revision信息，表示抢锁失败。更详细的实现留个TODO。
问题现象
-
pprof显示goroutine数量异常，查看详细调用栈看到有两处goroutine泄漏，数量都在14000多。
1562121215406.jpg - 查看etcd锁的kv数量，和泄漏的goroutine数量一致。
问题分析
- 分析goroutine阻塞位置的代码（如下），从现象特征、注释和代码上下文初步推测加锁的key没有释放成功，goroutine一直对key的lease做keepalive操作。
// keep the lease alive until client error or cancelled context <- 核心注释
go func() {
defer close(donec)
for range keepAlive {
// eat messages until keep alive channel closes
}
}()
func (l *lessor) keepAliveCtxCloser(ctx context.Context, id LeaseID, donec <-chan struct{}) {
select {
case <-donec:
return
case <-l.donec:
return
case <-ctx.Done():
}
//略
}
- 和etcd mutex example demo代码比对，缺少unlock操作。
- 确认unlock能否解决问题。源码如下：
func (m *Mutex) Unlock(ctx context.Context) error {
client := m.s.Client()
if _, err := client.Delete(ctx, m.myKey); err != nil {
return err
}
m.myKey = "\x00"
m.myRev = -1
return nil
}
unlock直接将key删除，可能会出现其他服务抢到锁，临界代码再次被执行。这样能解决当前问题，但会引入其他问题。
解决方案
unlock
- unlock操作是将锁删除。如果unlock失败怎么办？锁一直存在，goroutine还会泄漏！
- 各个应用实例执行状态无法确定，某个实例unlock后会有其他应用实例lock成功的可能，会演变成临界代码的串行化执行。
lock expire
- 根据lock后的程序执行情况，冗余判断代码执行时间，进而设置锁存活时间，并停止对锁的续租行为，到期后key和value自动消失。
- 如果lock后执行失败了？执行时间不一定靠谱？抢锁后的操作失败或者执行超时锁消失造成二次上锁，这些问题引发的后果是可承担的，出现概率极低，当前的业务场景下是ok的。
- 抢锁设置超时时间，避免多服务实例goroutine执行阻塞。
如何停止keepalive？分析源码
- 源码中有说明注释
- 从调用栈分析是NewSession的调用，入口示例代码：
cli, err := clientv3.New(clientv3.Config{Endpoints: endpoints})
if err != nil {
log.Fatal(err)
}
defer cli.Close()
s1, err := concurrency.NewSession(cli) //<- 问题入口函数
if err != nil {
log.Fatal(err)
}
defer s1.Close()
m1 := concurrency.NewMutex(s1, "/my-lock/")
// acquire lock for s1
if err := m1.Lock(context.TODO()); err != nil {
log.Fatal(err)
}
fmt.Println("acquired lock for s1")
- NewSession实现如下：
// NewSession gets the leased session for a client.
func NewSession(client *v3.Client, opts ...SessionOption) (*Session, error) {
ops := &sessionOptions{ttl: defaultSessionTTL, ctx: client.Ctx()}
for _, opt := range opts {
opt(ops)
}
//如果没有租约lease，则申请一个新的，其TTL是可以通过参数WithTTL设置，不设置默认defaultSessionTTL 60s。
id := ops.leaseID
if id == v3.NoLease {
resp, err := client.Grant(ops.ctx, int64(ops.ttl))
if err != nil {
return nil, err
}
id = v3.LeaseID(resp.ID)
}
ctx, cancel := context.WithCancel(ops.ctx)
//KeepAlive参数ctx的parent来源于ops.ctx，通过此context可以cancel keepalive，停止keepalive channel。
keepAlive, err := client.KeepAlive(ctx, id)
if err != nil || keepAlive == nil {
cancel()
return nil, err
}
donec := make(chan struct{})
s := &Session{client: client, opts: ops, id: id, cancel: cancel, donec: donec}
// keep the lease alive until client error or cancelled context
go func() {
defer close(donec)
for range keepAlive { //<- 阻塞点之一，因为keepalive goroutine不停续租，没有close该channel
// eat messages until keep alive channel closes
}
}()
return s, nil
}
sessionOption对session做参数赋值操作，类似gRPC的client grpc.DialContext的代码。将结构字段赋值做成可变参数，做到针对性的定制化，并提供了WithTTL WithLease WithContext三种参数选项，分别设置新申请租约的TTL、设置已有租约、设置context。如果不熟悉context请先熟悉context的parent canel机制。
太累了，不写了。看一下goroutine执行图，有留言我再写。
lease keepalive执行图
etcd v3 lease keepalve.jpg
- goroutine E是专门负责在keepalive失败或者取消后，清理keepalive所持有数据对象资源的。D是专门负责在keepalive失败或者取消后，通知上层goroutine。因此goroutine D和E阻塞。
- goroutine A在stream通道中周期性发送lease保活心跳，etcd接收到心跳request后对lease renew，然后向goroutine B发送response，返回TTL。如果TTL>0，则更新下一次发送保活心跳的时间和lease过期时间，并发送lease alive的message给到goroutine D，形成keepalive forever的模型，goroutine D和E保持阻塞。如果TTL<=0，则调用keepalive关闭模块，通知goroutine D和E进行结束。
- goroutine C在周期性计算keepalive是否到期，到期删除释放相关资源。主要职责是防止服务端宕掉、网络问题或其他异常问题导致lease已经消亡而客户端还认为lease存活的假象，采取过期机制。
- 在goroutine E中增加timeout的context，到时间自动关闭context done channel，进而结束D和E goroutine。
- 实际代码更加复杂，更多channel之间的通信，暂时不画全貌。