高并发的情况对数据库更新方法

在实际工作过程中，很多企业是业务系统都存在高并发的情况，动辄随便一个数据表存在上千万数据量。

由于企业业务有特殊性，难免会通过数据库进行更新操作。如何在高并发情况下对数据库进行操作，对数据库进行更行时，如果没有防重机制做拦截，就会导致数据被更新多次，造成更新后程序的后续操作。高并发的情况下，多个请求对同一条数据进行更新操作，易导致数据被多次更新，影响数据库的正确性；如何在高并发情况下对数据进行更新：


方案一：

加锁查询拦截，在更新前，加锁(分布式系统用分布式锁、也可用数据库锁等)，查询需要更新的数据是否存在且未被更新，根据查询结果做更新操作，更新后释放锁。适用于实际环境需要对数据需要进行多次更新，或多个中间状态都可以对数据进行操作；优势需要保证数据更新的一致性。缺点：系统性能消耗大，锁表期间不能进行业务系统录入，影响系统的效率。
SQL代码如下：
// 用redis加锁   redis.set(key, value);  
// 查询要更新的数据  int result = select * from table where 条件;
// 更新操作  if(result == 1){   
//判断数据是否已经被更新   if(未被更行){
//更新       update table set XXX=x2 where 条件;
}}
// 释放锁



本人所就职公司存在业务不能停机也不能中断的情况。所以推荐一下方案二：
方案二：
数据库层面拦截,直接在更新数据时带状态更新数据，根据更新后成功与否做后续操作；适用于明确知道更新数据前或后的状态，且不会在更新时多次发生状态变化，保证前后一致性；优势简单，保证数据更新的一致性，且对效率影响较小；缺点系统性能消耗大，锁机制影响系统的效率；
// 数据库层的sql语句限制即可
int result = update table set 更新的内容 where 原数据的内容  != 更新的内容；
//  更新成功if(result == 1){
// 执行更新成功后的操作
    }else{
  // 执行更新失败后的操作

感谢楼主带来的运维经验分享！！！

并发运维是生产环境中常遇到的事，而且由于实际业务情况可能会多少有所影响，因此正确评估和充分实施就显得格外重要；本案例脚本可以作为参考。

这个经验很实用，有些甲方客户，并不太清楚如果评估并发量，这个帖子很棒

这个经验很实用，很多情况下数据库不能用平均并发去计算硬件配置，只能按最高峰去配置，但是最高峰配置硬件就增加了成本