|
锁定老帖子 主题：多个客户端连接同一套数据，怎样防止同时更新
精华帖 (1) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2012-12-28
Shen.Yiyang 写道 finallygo 写道 Shen.Yiyang 写道 finallygo 写道 Shen.Yiyang 写道 finallygo 写道 Shen.Yiyang 写道 读取远大于写入，请用乐观锁；
基本为写入，用悲观锁。 如果数据库资源是集中的，没有拆分，为什么要用分布式锁，好玩？ 因为是分布式的应用啊 如果数据库没有拆分，或者没有拆分的计划；那么用分布式锁，和直接在数据库加锁，有任何性能功能上的区别？ 性能上肯定差很多呀,至少用分布式锁,不依赖于数据库了,对数据库的压力可以减少很多,提高并发 好吧，伸手要测试结果；分布式锁就不需要在服务器之间通信了吗，有什么理由 服务器之间通信+数据库IO 比 数据库锁+数据库IO 快，而且是差很多， 这依据是什么。 前提是数据库不拆分。 呃...这不就是拿缓存和数据库的速度进行对比么... 这跟缓存不搭嘎啊，分布式锁只是在数据库之外解决了锁的问题，IO还要走数据库，怎么能这样做对比呢； 分布式锁应用的最合适的场景，始终是数据源可能拆分，并且用了分布式锁以后，需要始终通过一个repository层去访问数据库，而不能直接使用；所以这个更多的是公司层面架构的选择，APP根本不能擅自做主。 当然有关系了,如果获取不到锁,就直接返回了,怎么会操作数据库呢?? |
| 返回顶楼 | |
|
发表时间：2012-12-28
finallygo 写道 Shen.Yiyang 写道 finallygo 写道 Shen.Yiyang 写道 finallygo 写道 Shen.Yiyang 写道 finallygo 写道 Shen.Yiyang 写道 读取远大于写入，请用乐观锁；
基本为写入，用悲观锁。 如果数据库资源是集中的，没有拆分，为什么要用分布式锁，好玩？ 因为是分布式的应用啊 如果数据库没有拆分，或者没有拆分的计划；那么用分布式锁，和直接在数据库加锁，有任何性能功能上的区别？ 性能上肯定差很多呀,至少用分布式锁,不依赖于数据库了,对数据库的压力可以减少很多,提高并发 好吧，伸手要测试结果；分布式锁就不需要在服务器之间通信了吗，有什么理由 服务器之间通信+数据库IO 比 数据库锁+数据库IO 快，而且是差很多， 这依据是什么。 前提是数据库不拆分。 呃...这不就是拿缓存和数据库的速度进行对比么... 这跟缓存不搭嘎啊，分布式锁只是在数据库之外解决了锁的问题，IO还要走数据库，怎么能这样做对比呢； 分布式锁应用的最合适的场景，始终是数据源可能拆分，并且用了分布式锁以后，需要始终通过一个repository层去访问数据库，而不能直接使用；所以这个更多的是公司层面架构的选择，APP根本不能擅自做主。 当然有关系了,如果获取不到锁,就直接返回了,怎么会操作数据库呢?? 返回？你不要数据了？获取不到锁以后，通常的情况就是进入锁的等待和通知阶段；而且分布式的等待和通知，与数据库这种单点处理等待通知还有所不同，是需要消耗服务器之间的网络通信来选择 锁的获胜者，只能说你等待和通知的负载转移到了分布式这里，而不能说无负载；如果你不合理地设计通知机制，在高并发的时候就会出现大量无意义通知的羊群效应，大量占用网络IO。 总之，分布式解决方案根本不是银弹，应用分布式技术同样会带来分布式技术带来的限制。 |
| 返回顶楼 | |
|
发表时间：2012-12-28
Shen.Yiyang 写道 finallygo 写道 Shen.Yiyang 写道 finallygo 写道 Shen.Yiyang 写道 finallygo 写道 Shen.Yiyang 写道 finallygo 写道 Shen.Yiyang 写道 读取远大于写入，请用乐观锁；
基本为写入，用悲观锁。 如果数据库资源是集中的，没有拆分，为什么要用分布式锁，好玩？ 因为是分布式的应用啊 如果数据库没有拆分，或者没有拆分的计划；那么用分布式锁，和直接在数据库加锁，有任何性能功能上的区别？ 性能上肯定差很多呀,至少用分布式锁,不依赖于数据库了,对数据库的压力可以减少很多,提高并发 好吧，伸手要测试结果；分布式锁就不需要在服务器之间通信了吗，有什么理由 服务器之间通信+数据库IO 比 数据库锁+数据库IO 快，而且是差很多， 这依据是什么。 前提是数据库不拆分。 呃...这不就是拿缓存和数据库的速度进行对比么... 这跟缓存不搭嘎啊，分布式锁只是在数据库之外解决了锁的问题，IO还要走数据库，怎么能这样做对比呢； 分布式锁应用的最合适的场景，始终是数据源可能拆分，并且用了分布式锁以后，需要始终通过一个repository层去访问数据库，而不能直接使用；所以这个更多的是公司层面架构的选择，APP根本不能擅自做主。 当然有关系了,如果获取不到锁,就直接返回了,怎么会操作数据库呢?? 返回？你不要数据了？获取不到锁以后，通常的情况就是进入锁的等待和通知阶段；而且分布式的等待和通知，与数据库这种单点处理等待通知还有所不同，是需要消耗服务器之间的网络通信来选择 锁的获胜者，只能说你等待和通知的负载转移到了分布式这里，而不能说无负载；如果你不合理地设计通知机制，在高并发的时候就会出现大量无意义通知的羊群效应，大量占用网络IO。 总之，分布式解决方案根本不是银弹，应用分布式技术同样会带来分布式技术带来的限制。 汗...你都和别人起冲突了,还需要等什么呢??当然是立刻返回告诉用户并更新到最新,svn,git不都是这么处理的??另外,你说要在服务器端等待....你考虑了高并发的情况么?? |
| 返回顶楼 | |
|
发表时间：2012-12-28
finallygo 写道 汗...你都和别人起冲突了,还需要等什么呢??当然是立刻返回告诉用户并更新到最新,svn,git不都是这么处理的??另外,你说要在服务器端等待....你考虑了高并发的情况么??
你怎么能以技术方案来修改用户的需求？ 一个业务过程如果就是等待并且完成，你可以直接修改成让用户不断操作，这用户体验和需求就完全不管了？ 在服务端等待不是很正常吗，你不要跟我说，你遇到的所有分布式锁都没有通知机制，都只能trylock；因为并发所以分布式锁不能排队，真是奇闻啊；你这么惧怕服务器负载那还要分布式干嘛，都不在服务器等，直接上单机+备份啊，反正没什么大负载啊 |
| 返回顶楼 | |
|
发表时间：2012-12-28
最后修改：2012-12-28
Shen.Yiyang 写道 finallygo 写道 汗...你都和别人起冲突了,还需要等什么呢??当然是立刻返回告诉用户并更新到最新,svn,git不都是这么处理的??另外,你说要在服务器端等待....你考虑了高并发的情况么??
你怎么能以技术方案来修改用户的需求？ 一个业务过程如果就是等待并且完成，你可以直接修改成让用户不断操作，这用户体验和需求就完全不管了？ 在服务端等待不是很正常吗，你不要跟我说，你遇到的所有分布式锁都没有通知机制，都只能trylock；因为并发所以分布式锁不能排队，真是奇闻啊；你这么惧怕服务器负载那还要分布式干嘛，都不在服务器等，直接上单机+备份啊，反正没什么大负载啊 呃...这个是正常的需求呀,别人在修改,你当然不能修改了,这个不就是楼主想要的需求么??要不为啥要加锁?? 我没有说分布式锁不能等待,这个和需求有关系,这里当然是直接返回给用户了;就是为了较小服务器压力才用分布式锁的,这是我一直强调的,不知道你是怎么理解的 |
| 返回顶楼 | |
|
发表时间：2012-12-28
最后修改：2012-12-28
Shen.Yiyang 写道 finallygo 写道 汗...你都和别人起冲突了,还需要等什么呢??当然是立刻返回告诉用户并更新到最新,svn,git不都是这么处理的??另外,你说要在服务器端等待....你考虑了高并发的情况么??
你怎么能以技术方案来修改用户的需求？ 一个业务过程如果就是等待并且完成，你可以直接修改成让用户不断操作，这用户体验和需求就完全不管了？ 在服务端等待不是很正常吗，你不要跟我说，你遇到的所有分布式锁都没有通知机制，都只能trylock；因为并发所以分布式锁不能排队，真是奇闻啊；你这么惧怕服务器负载那还要分布式干嘛，都不在服务器等，直接上单机+备份啊，反正没什么大负载啊 或者这么说吧,比如这个是一个秒杀的系统,如果一个物品被人抢到,其他人是不是应该立刻返回???还是你觉得要让用户一直在那里等呀等,等半天,发现没有了???或许开发12306的哥们,和你的想法是一样的~~ |
| 返回顶楼 | |
|
发表时间：2012-12-28
你的例子根本就是对需求的误读，不能同时修改 = 快速失败策略？ 东西缺货确实是马上返回，这只是一种快速失败策略的体现，并且“修改物品状态的过程”是不是需要同步，是不是必须等待才能确定购买是否可以？
获取不到锁就返回，只能适用于锁等价于资源，并且资源只能被抢占一次；如果可以反复修改，或者锁和资源有复杂的关系，根本就不能成立； 拜拜 |
| 返回顶楼 | |
|
发表时间：2012-12-28
Shen.Yiyang 写道 你的例子根本就是对需求的误读，不能同时修改 = 快速失败策略？ 东西缺货确实是马上返回，这只是一种快速失败策略的体现，并且“修改物品状态的过程”是不是需要同步，是不是必须等待才能确定购买是否可以？
获取不到锁就返回，只能适用于锁等价于资源，并且资源只能被抢占一次；如果可以反复修改，或者锁和资源有复杂的关系，根本就不能成立； 拜拜 是呀,我刚才也强调了,分布式锁,并不是不能等待,这个需要看具体需求的,而这里的例子,如果是允许反复修改的,我想问,那还加锁干啥? |
| 返回顶楼 | |
|
发表时间：2012-12-31
finallygo 写道 Shen.Yiyang 写道 你的例子根本就是对需求的误读，不能同时修改 = 快速失败策略？ 东西缺货确实是马上返回，这只是一种快速失败策略的体现，并且“修改物品状态的过程”是不是需要同步，是不是必须等待才能确定购买是否可以？
获取不到锁就返回，只能适用于锁等价于资源，并且资源只能被抢占一次；如果可以反复修改，或者锁和资源有复杂的关系，根本就不能成立； 拜拜 是呀,我刚才也强调了,分布式锁,并不是不能等待,这个需要看具体需求的,而这里的例子,如果是允许反复修改的,我想问,那还加锁干啥? 允许反复修改就不用加锁了？你这是什么神逻辑？ 很多时候加锁只是为了禁止他们同时更新导致脏数据，而不是禁止他们反复更新。 |
| 返回顶楼 | |
|
发表时间：2013-01-01
如果考虑扩展性，使用分布式锁，可以扩展成锁部分逻辑，而不只是一个更新语句，
如果不考虑，只考虑数据库，直接使用select xx from xx for update wait xx秒,通过后然后执行更新 |
| 返回顶楼 | |
