高并发 数据库操作比如插入，修改等解决办法

一般没有办法就是直接操作 数据库了，所以才 需要分布式mysq等，必须有事务。 但是如何并发太大还是不够的， 解决方案： 原子计数器---技术-- redis/noSQL 记录用户行为消息--分布式MQ 消费消息并落地--- mysql 这样可以抗很高的并发，但是成本太大了

运维成本和稳定型： NoSQL,MQ等 开发成本： 数据一致性，回滚方案等 幂等性难保证：重复秒杀问题 不适合新手的架构

为什么不用MySQL呢？ 一般认为是mysql低效，其实不是 其实是因为 事务的关系，特别是操作2个表的时候 一个事务 里面 有更新又有插入数据的时候，那么 mysql就是 行级锁启动了，同一条数据就锁着了。 一直到前一个操作的客户 commit或者 回滚该条数据。 其他用户想操作该条数据 是锁着的，在等待。。 如果很多客户那么就会等待太久了。 其中等待时间 包括了 网络延迟 以及GC垃圾回收时间 串行化了

优化方向： 减少行级锁持有时间 将客户端的逻辑放在mysql 里面，避免网络延迟和GC垃圾回收影响

如何放到mysql服务端： 定制SQL方案： update/+[auto_commit]/ ,需要修改mysql源码 意思是，如何 更新成功的结果是1就自动提交，如果失败就自动回滚，不提交给客户端了，造成不必须有的时间影响。 使用存储过程：整个事务在mysql 端完成。 存储过程本身就是 为了 将整个事务在mysql 服务器端完成。 避免客户端去完成事务造成的时间的干扰。 就是 事务竞争优化：减少事务锁时间

比如一个例子： 一个事务，有更新和 插入的操作。 一般情况可能是 ， 先执行更新，然后再执行插入 数据到其他表里面。 但是在高并发的情况下， 简单优化 ; 是 这样的， 先 执行插入， 然后 在去更新比较好。 因为 更新的情况下，数据库会对那条数据 加一个 行级锁，先插入呢，可以减少锁的持有时间。 深度优化： 事务SQL在MySQL端执行（存储过程） 存储过程： 1， 存储过程优化： 事务行级锁持有的时间 2， 不要过度依赖存储过程 3， 简单的逻辑可言应用存储过程 4， 这样可以提供并发量，特别是秒杀并发

转载于:https://my.oschina.net/ouminzy/blog/729308