使用Kubernetes对象实现悲观锁的可行性及相关问题咨询

问题1：使用Kubernetes对象实现悲观锁的方案合理性及缺陷 #

该方案逻辑上完全合理，底层依托etcd的线性一致性写入保证，多个客户端同时创建同名唯一资源时只会有一个请求成功，完全满足分布式悲观锁的核心要求。
但存在以下缺陷：

• 若使用ConfigMap作为锁载体，本身存在设计错配：ConfigMap的原生定位是存储应用配置，用于锁场景会带来权限管控风险（需要给业务服务开放ConfigMap的写、删权限），也容易和正常配置管理逻辑混淆，维护成本高。
• 缺乏锁生命周期的内置支持：无论是ConfigMap还是Lease，过期、续租逻辑都需要业务侧自行实现，容易出现边界问题：比如节点时钟偏移导致过期判断错误、进程GC卡顿未及时续租导致锁被意外抢占、进程异常退出后锁无法及时释放等。
• 无原生阻塞唤醒机制：客户端抢锁失败后只能自行轮询请求API Server，没有类似ZooKeeper Watcher的事件通知机制，会产生不必要的请求开销，也会增加锁获取的延迟。
  注：Lease对象是Kubernetes专门为心跳、锁场景设计的资源，内置了持有者标识、租期时长、续租时间等专用字段，相比ConfigMap更适合作为锁载体，能减少很多自行实现的元信息管理逻辑

问题2：ZooKeeper、Redlock等分布式锁方案相比Kubernetes对象锁的优势 #

• 生态成熟度更高：两类方案都有经过多年生产验证的多语言客户端实现，锁的过期、续租、重试、容错逻辑都已经封装完善，不需要业务侧自行实现核心逻辑，大大降低出bug的概率。
• 锁特性更丰富：ZooKeeper基于临时顺序节点可以原生实现公平锁、非公平锁、阻塞锁等多种模式，不需要客户端轮询；Redlock也支持灵活的锁粒度、超时策略配置，适配更多业务场景。
• 适用范围更广：Kubernetes对象锁只能给集群内有对应RBAC权限的工作负载使用，而ZooKeeper、Redis作为独立的分布式组件，可以支持跨集群、跨机房、包含集群外节点的异构架构场景。
• 性能表现更好：两类方案的读写路径都比经过Kubernetes API Server代理的请求路径更短，高并发抢锁场景下的吞吐量更高，延迟也更稳定。

内容的提问来源于stack exchange，提问作者csviri