在分布式 Web 后端中,各位老哥们会考虑在业务接口中引入锁 信号量这种吗?
我记得很久以前我在一个博客中看到 能不用 lock 尽量不用 说 一个是不好控制 另外一个是容易吃性能
各位老哥们能指点下?或者心得?
![]() |
1
codehz 43 天前
用不用不是得看正确性吗,当然除了传统意义上的分布式锁之外也有别的方案,比如乐观并发控制
|
![]() |
2
sujin190 43 天前
吃不了多少性能吧,而且 web 中分布式锁都是对特定资源加锁,除非是秒杀这种特定场景否则对并发性影响几乎可以忽略不计,而且靠谱一点的分布式锁方案网络正常情况下延时都应该低于 2ms ,这对接口响应时间来说的影响也不大吧,主要就是加锁直观简单且靠谱,你看直接套用系统的多线程编程都很难了,其实用其它方案其实更复杂的,想要设计完备其实就更难了
|
![]() |
3
mightybruce 43 天前
没有什么绝对的事情, 建议多看看架构设计的书。
软件架构设计没有银弹,只有取舍。 |
![]() |
4
helloluckydamon 43 天前 ![]() 当你要访问共享资源,又可能会发生并发修改问题的时候,没办法不用锁。如果不会造成并发修改冲突,无锁编程肯定性能高。
比如使用旁路缓存模式,从数据库加载 1 万条数据列表大概 10MB 到 redis ,这时候并发请求读取,A 线程读取数据库 1 万条,B 线程也来读取发现 Redis 数据不存在也去请求数据库,这时候 B 读取数据库发现有人更新了读取到了 1 万零 1 条,然后 B 线程执行快先完成将数据写入 Redis ,A 线程此时慢了一步继续写入 Redis ,那最新的一条数据就被覆盖了,这时候缓存和数据库就不一致。 当然也可以用队列来处理这种情形。 信号量一般用在对资源的数量要求极度精准的情况,比如限流最高就要求同一单位时间 1000 人访问,那使用信号量就会特别精准,而且还能应对流量突刺,同时不会产生临界区问题,你使用其他的限流算法就比较难做到。 所以,如果你现在还没有使用锁和信号量,那一般是以下三个情况: 1. 你的业务场景确实暂时不需要,不必强加 2. 你还没有在线上遇到过由并发读写产生的 bug ,所以还没发现 3. 因为缺少并发处理经验,所以暂时缺少这部分的意识,需要补充 |
![]() |
5
liuqiongyu889 43 天前
看情况,大部分的表单提交请求冲突覆盖都没问题,没必要上锁,客户端做好 button disabled 尽量避免重复发送就行,交易、订单、等需要严格递增插入的场景必须上锁,避免脏状态落库,java 可以考虑用这个:[redisson]( https://github.com/redisson/redisson),大部分需求都能满足了。
|
![]() |
6
awalkingman 43 天前
@codehz 同意。用不用是看需要看需求,掌握好技能根据实际情况决定,不是看博客下爆论。
|
![]() |
7
potatowish 43 天前 via iPhone
分布式锁、分布式读写锁、乐观锁这三个用的多。没获取到锁或者条件不满足,让调用方自己重试
|
8
Pantheoon 43 天前
搞 web 看下分布式锁的原理 以及 mysql 锁的原理,jdk 自带的锁都是单机的,用的很少
|
9
piecezzz 43 天前
看场景,看业务。
|