go 实现的高性能分布式锁服务，每秒可处理 83 万加锁和解锁请求

[sujin190]

之前遇到在下单扣费之类的场景需要分布式锁，后来就自己做了一个，优化一段时间，感觉性能还行啊，i5 8g 机器单机每秒可以完成 83 万加锁解锁请求，不得不说写一个好的 benchmark 也很难啊。

项目地址：

https://github.com/snower/slock

除了分布式锁同步场景外，还实现了分布式 Event，分布式 Semaphore，在消息中心、秒杀枪库存、限流都可以比较方便使用了。

多核性能也不错，可以用到多核，单机测试中，带宽沾满千兆，go 的性能还是好啊。

[pifuant]

单机分布式锁？

[holyghost]

单机分布式锁？

[sujin190]

@pifuant #1
@holyghost #2 单机 83 万加锁解锁，但是网络服务啊，不是单机用的
比如 web 场景，多台机器需要同步操作库存扣费啥的

[liprais]

楼主是不是不知道啥是分布式锁........

[sujin190]

@liprais #4 有什么区别么？重点是不局限必须在同一台机器，而保证原子，无论怎么最终还是需要一个中心来确认

[sujin190]

@liprais #4 而且也只是小服务，主要就是简单，快，针对 web 场景需要同步或是限流之类使用完全没问题啊

[holyghost]

@sujin190 有。。。而且肯定不是一个中心来确认

[whatsmyip]

emmmm

[yangbin9317]

tql ……

[zealot0630]

楼主放弃了 CAP 中的 C，然后搞了个毫无实用价值的东西

[sujin190]

@holyghost #7 那可能你是没理解，我这需要的是同步，不是一致性，Paxos 之类的协议都解决的是一致性问题，并不是解决同步问题
一致性有很多协议可以解决，但是同步无论什么协议，最终都需要一个中心来确认吧
而且在需要同步的场景中，那么应该是很快速资源消耗很低的方式实现才是
在简单场景中，很多时候完全可以依赖同步很简单解决一致性问题，但是同步并不是完全用了解决一致性问题的

[zealot0630]

搞错了 放弃了 A

[sujin190]

@zealot0630 #10 这解决的是同步问题，并不是数据库场景中的一致性问题

[wusatosi]

那要是中心突然下线了怎么办（。）

[pifuant]

@sujin190 高可用都保证不了， 这个分布式锁谁敢用？

[sujin190]

@wusatosi #14 同步问题中不是特别怕中心挂的情况吧

一般来说同步场景都是某一刻同步，比如 a 和 b 在前一刻用 1 中心同步，那么 c 和 d 为啥不能在下一刻用 2 备用中心同步呢，其中产生的一致性问题应该仍然还是由数据库事物或者其他一致性协议来保证

总的来说，分布式锁其中一个场景应该是想要解决的问题应该是我们在很多时候使用一致性结果来同步的极大资源消耗问题，比如很明显的秒杀场景中，是否还有库存这个状态

其他的比如扫码登陆时，是否已经扫码不也是一个同步问题么

[sujin190]

@pifuant #15 本来就是小工具啊，解决小微场景中某些用锁可以很方便解决的同步问题，并没有说在大型场景中可以很成熟使用

[wweir]

讲个笑话，paxos、raft 没解决同步的问题 😹

[sujin190]

@pifuant #15 不过最近也在考虑也行可以加入 binlog 和集群模式看看，也只是探讨，在很多小微场景确实高可用不是特别突出，简单快速解决问题也挺好不是

[sujin190]

@wweir #18 paxos、raft 解决的是一致性问题吧