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

通常没有办法就是直接操做 数据库了，因此才 须要分布式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， 这样能够提供并发量，特别是秒杀并发