并发修改数据的处理

场景

有一个数据是中心数据，另外一些数据是次要的数据，这些数据的修改是不确定的，并且他们的修改，会引起一些中心的数据的变化，次要数据进行修改，与中心数据的一起发生的变动要放在一个事务里面，但是次要数据的修改可能会是不同的用户发起的 换言之可能是并行的。

解决方案

1. 首先对于中心数据而言，不能被并行修改，这样的修改会有类似 ABA问题的产生，锁是必须的

2.锁可以使用数据库层面的 也可以使用代码层面的，不过一般不推荐使用数据库层面的，这里使用代码层面的

3.锁的用法

   1. 在将要对中心数据发生修改时，获取锁，当然也可能失败，这里要指定一些重试策略 比如每次获取失败sleep(300)重试3次最后没有获取 前端提示系统忙稍后获取

   2. 获取锁后 执行业务代码 完成后释放锁，释放锁最好是放在finally中 整个业务代码最好是放在try catch里面

4. 数据修改

   考虑这么一个场景

   用户A在修改某条次要数据 ，用户b也在修改某条次要数据 很显然 如果采取措施 那么 次要数据的结果 将是最后完成修改的那个人的 而中心数据则会发生奇怪的变化 A和B 都不认识。这个时候应该是 一个人先修改 后面那个人修改失败 并提示她数据过期 请重新获取数据在修改，这样数据就不会发生奇怪的变化了。

所以这里还要额外考虑一下，一般最常用的东西，就是版本号了，即所谓的乐观锁。但这个版本号又该怎么加呢？ 所有次要数据加一个 还是只在中心数据加一个，这个就要具体分析了。一般来说如果次要数据与中心数据是一对一的 加在哪里都可以，但是如果是多对一中心数据就必须有了，新增次要数据版本号没没啥意义。

事实上 上面的两个锁 一般是分开用的，放在一起的话 只不过是对数据库友好一点，不会让每个请求 都进行一次数据的修改。