Kafka不适合直接做分布式锁，因其缺乏强一致性租约、无原生租期续期、消费者组再平衡易致锁意外释放，且offset提交无法保障独占写入；可靠方案需借助etcd等外部服务实现原子锁操作，Kafka仅作低延迟事件通知通道。
为什么Kafka不适合直接做分布式锁
直接用Kafka实现分布式锁是反模式——Kafka 本身不提供强一致性租约、无原生租期续期机制、消费者组再平衡会导致锁意外释放，且 offset 提交语义无法保证“锁持有期间独占写入”。你看到的“Kafka+ZooKeeper”或“Kafka+时间戳”方案，本质是借Kafka做事件广播，真正锁逻辑仍依赖外部协调服务（如etcd、Redis）。
用Kafka配合etcd实现可靠分布式锁的典型流程
核心思路：Kafka只负责触发锁申请/释放通知，etcd负责原子性锁操作。避免把Kafka当协调中心用。
-
LockService.Acquire(ctx, "order-123")先向/locks/order-123发起 etcdCompareAndSwap（带租期TTL），成功则写入持有者ID和租期 - Acquire 成功后，往 Kafka topic
lock_events发送{"key":"order-123","action":"acquired","holder":"svc-order-01"} - 其他服务监听该 topic，收到事件后主动调用
etcd.Get("/locks/order-123")确认当前状态，而非盲目等待 - 锁释放时，先删 etcd key，再发
{"key":"order-123","action":"released"}到 Kafka
注意：Kafka 消息不保证严格有序（分区级有序），所以所有客户端必须以 etcd 为准，Kafka 只是低延迟通知通道。
Go中用sarama和go.etcd.io/etcd/clientv3的关键代码片段
不要在 sarama.Consumer 回调里直接操作 etcd 锁——网络延迟可能导致重复加锁或误判。应把消息转为 channel 后由独立 goroutine 处理：
立即学习“go语言免费学习笔记（深入）”；
// Kafka 消费端
msgs := consumer.ConsumePartition("lock_events", 0, sarama.OffsetNewest)
go func() {
for msg := range msgs.Messages() {
var event struct{ Key, Action, Holder string }
json.Unmarshal(msg.Value, &event)
if event.Action == "acquired" {
// 这里只触发检查，不直接加锁
select {
case lockCheckCh <- event.Key:
default:
}
}
}
}()
<p>// 单独的锁检查 goroutine
go func() {
for key := range lockCheckCh {
resp, _ := etcdClient.Get(context.Background(), "/locks/"+key)
if len(resp.Kvs) > 0 && string(resp.Kvs[0].Value) != myServiceID {
// 真实持有者不是自己 → 触发本地状态同步或跳过处理
}
}
}()容易被忽略的三个坑
实际落地时，以下三点导致多数团队踩坑：
- etcd 的 lease TTL 必须明显大于 Kafka 消费延迟峰值（建议 ≥ 5× P99 消费延迟），否则锁未释放就被自动过期
- Kafka producer 要设
RequiredAcks: sarama.WaitForAll，否则锁事件丢失会导致其他节点永远收不到通知 - 不要用 consumer group 自动提交 offset —— 必须在 etcd 锁确认生效后，手动调用
consumer.CommitOffsets()，否则消息重复消费会引发状态错乱
真正难的不是写几行 Kafka 生产/消费代码，而是让 Kafka 和 etcd 的语义边界清晰、失败路径可追溯、租期与网络延迟对齐。
