多个客户端连接同一套数据，怎样防止同时更新

如果数据库没有拆分，或者没有拆分的计划；那么用分布式锁，和直接在数据库加锁，有任何性能功能上的区别？

性能上肯定差很多呀,至少用分布式锁,不依赖于数据库了,对数据库的压力可以减少很多,提高并发

好吧，伸手要测试结果；分布式锁就不需要在服务器之间通信了吗，有什么理由 服务器之间通信+数据库IO 比 数据库锁+数据库IO 快，而且是差很多， 这依据是什么。

前提是数据库不拆分。

呃...这不就是拿缓存和数据库的速度进行对比么...

对，不分数据库

两种办法：
1.依赖数据库存储过程

2.表加上更新时间戳列，select的时候得到了时间戳，update的把时间戳比较一下就可以了。

乐观锁?

你加个 时间戳 。然后更新前 锁定表 ，对比时间戳 更新/报错 ，解锁表。
很简单的逻辑嘛。

Of Course

这跟缓存不搭嘎啊，分布式锁只是在数据库之外解决了锁的问题，IO还要走数据库，怎么能这样做对比呢；
分布式锁应用的最合适的场景，始终是数据源可能拆分，并且用了分布式锁以后，需要始终通过一个repository层去访问数据库，而不能直接使用；所以这个更多的是公司层面架构的选择，APP根本不能擅自做主。