高并发事务出现的问题

1.第一类丢失
两个事务A B 都对同一数据S 做修改， A修改S成功后，B修改失败发生回滚，回滚的S导致A的修改被覆盖成原先的数据。导致两次对S的修改都失败。
READ COMMITTED以及以上的隔离机制都能解决
2.脏读
还是事务A B处理同一条数据S，在事务A修改了S这条数据但是还未提交数据时，事务B读取了事务A修改后的数据S，然后事务A回滚了，导致事务B读取的该条数据S是不存在的。因为S是之前的内容
REPEATABLE READ隔离机制就能解决
3.不可重复读
还是事务A B处理同一条数据S，事务A读取了数据S，然后事务B修改了数据S，然后事务A又读取了数据S，此时事务A读取的两次S的数据是事务B修改前后的数据，显然不同
REPEATABLE READ隔离机制就能解决
4.第二类丢失不可重复读的特例
还是事务A B处理同一条数据S，事务A把S修改成了S1，事务B后来又把S修改成了S2，然而事务B修改的S2没有在S1的基础上，导致事务A的修改没有作用了，也就是失败了。
5.幻读
事务A B处理一批数据Sn，比如A先读了Sn的一个分类是10个数据，然后事务B给这个分类新增了一条数据，然后事务A再读这类数据发现变成11个了，这就是幻读。先后两次读取数个个数发生了变化，不同于不可重复读

问题举例

什么是事务

事务是一条或多条数据库操作语句的组合，具备ACID，4个特点。
原子性：要不全部成功，要不全部撤销
隔离性：事务之间相互独立，互不干扰
一致性：数据库正确地改变状态后，数据库的一致性约束没有被破坏
持久性：事务的提交结果，将持久保存在数据库中

事务并发会产生什么问题

1）第一类丢失更新：在没有事务隔离的情况下，两个事务都同时更新一行数据，但是第二个事务却中途失败退出，导致对数据的两个修改都失效了。
例如：
张三的工资为5000，事务A中获取工资为5000，事务B获取工资为5000，汇入100，并提交数据库，工资变为5100，
随后
事务A发生异常，回滚了，恢复张三的工资为5000，这样就导致事务B的更新丢失了。
2）脏读：脏读就是指当一个事务正在访问数据，并且对数据进行了修改，而这种修改还没有提交到数据库中，这时，另外一个事务也访问这个数据，然后使用了这个数据。
例如：
　　张三的工资为5000,事务A中把他的工资改为8000,但事务A尚未提交。
　　与此同时，
　　事务B正在读取张三的工资，读取到张三的工资为8000。
　　随后，
　　事务A发生异常，而回滚了事务。张三的工资又回滚为5000。
　　最后，
　　事务B读取到的张三工资为8000的数据即为脏数据，事务B做了一次脏读。
3）不可重复读：是指在一个事务内，多次读同一数据。在这个事务还没有结束时，另外一个事务也访问该同一数据。那么，在第一个事务中的两次读数据之间，由于第二个事务的修改，那么第一个事务两次读到的的数据可能是不一样的。这样就发生了在一个事务内两次读到的数据是不一样的，因此称为是不可重复读。
例如：
　　在事务A中，读取到张三的工资为5000，操作没有完成，事务还没提交。
　　与此同时，
　　事务B把张三的工资改为8000，并提交了事务。
　　随后，
　　在事务A中，再次读取张三的工资，此时工资变为8000。在一个事务中前后两次读取的结果并不致，导致了不可重复读。
4）第二类丢失更新：不可重复读的特例。有两个并发事务同时读取同一行数据，然后其中一个对它进行修改提交，而另一个也进行了修改提交。这就会造成第一次写操作失效。
例如：
在事务A中，读取到张三的存款为5000，操作没有完成，事务还没提交。
　　与此同时，
　　事务B，存储1000，把张三的存款改为6000，并提交了事务。
　　随后，
　　在事务A中，存储500，把张三的存款改为5500，并提交了事务，这样事务A的更新覆盖了事务B的更新。
5）幻读：是指当事务不是独立执行时发生的一种现象，例如第一个事务对一个表中的数据进行了修改，这种修改涉及到表中的全部数据行。同时，第二个事务也修改这个表中的数据，这种修改是向表中插入一行新数据。那么，以后就会发生操作第一个事务的用户发现表中还有没有修改的数据行，就好象发生了幻觉一样。
例如：
　　目前工资为5000的员工有10人，事务A读取所有工资为5000的人数为10人。
　　此时，
　　事务B插入一条工资也为5000的记录。
　　这是，事务A再次读取工资为5000的员工，记录为11人。此时产生了幻读。
提醒：
不可重复读的重点是修改，同样的条件，你读取过的数据，再次读取出来发现值不一样了
幻读的重点在于新增或者删除，同样的条件，第 1 次和第 2 次读出来的记录数不一样

事务隔离机制解决的并发问题

（1）READ_UNCOMMITTED
　　这是事务最低的隔离级别，它充许另外一个事务可以看到这个事务未提交的数据。
　　解决第一类丢失更新的问题，但是会出现脏读、不可重复读、第二类丢失更新的问题，幻读。
（2）READ_COMMITTED
　　保证一个事务修改的数据提交后才能被另外一个事务读取，即另外一个事务不能读取该事务未提交的数据。
　　解决第一类丢失更新和脏读的问题，但会出现不可重复读、第二类丢失更新的问题，幻读问题
（3）REPEATABLE_READ
　　保证一个事务相同条件下前后两次获取的数据是一致的（注意是一个事务，可以理解为事务间的数据互不影响）

解决第一类丢失更新，脏读、不可重复读、第二类丢失更新的问题，但会出幻读。

（4）SERIALIZABLE
　　事务被处理为顺序执行。
　　解决所有问题
　　但是实际不使用这个隔离机制

提醒：
Mysql默认的事务隔离级别为repeatable_read-

innodb引擎的锁机制

之所以以InnoDB为主介绍锁，是因为InnoDB支持事务，支持行锁和表锁用的比较多，Myisam不支持事务，只支持表锁
-共享锁（S）：允许一个事务去读一行，阻止其他事务获得相同数据集的排他锁。顾名思义，共享锁就是多个事务对于同一数据可以共享一把锁，都能访问到数据，但是只能读不能修改。
排他锁（X）：允许获得排他锁的事务更新数据，阻止其他事务取得相同数据集的共享读锁和排他写锁。
顾名思义，排他锁就是不能与其他所并存，如一个事务获取了一个数据行的排他锁，其他事务就不能再获取该行的其他锁，包括共享锁和排他锁，但是获取排他锁的事务是可以对数据就行读取和修改。
意向共享锁（IS）：事务打算给数据行加行共享锁，事务在给一个数据行加共享锁前必须先取得该表的IS锁。
意向排他锁（IX）：事务打算给数据行加行排他锁，事务在给一个数据行加排他锁前必须先取得该表的IX锁。
说明：
1）共享锁和排他锁都是行锁，意向锁都是表锁，
应用中我们只会使用到共享锁和排他锁，意向锁是mysql内部使用的，不需要用户干预。
2）对于UPDATE、DELETE和INSERT语句，InnoDB会自动给涉及数据集加排他锁（X)；对于普通SELECT语句，InnoDB不会加任何锁，事务可以通过以下语句显示给记录集加共享锁或排他锁。
共享锁（S）：SELECT * FROM table_name WHERE … LOCK IN SHARE MODE。
排他锁（X)：SELECT * FROM table_name WHERE … FOR UPDATE。
3）InnoDB行锁是通过给索引上的索引项加锁来实现的，因此InnoDB这种行锁实现特点意味着：只有通过索引条件检索数据，InnoDB才使用行级锁，否则，InnoDB将使用表锁！。
对于共享锁大家可能很好理解，就是多个事务只能读数据不能改数据，对于排他锁大家的理解可能就有些差别，我当初就犯了一个错误，以为排他锁锁住一行数据后，其他事务就不能读取和修改该行数据，其实不是这样的。排他锁指的是一个事务在一行数据加上排他锁后，其他事务不能再在其上加其他的锁。mysql InnoDB引擎默认的修改数据语句，update,delete,insert都会自动给涉及到的数据加上排他锁，select语句默认不会加任何锁类型，如果加排他锁可以使用select …for update语句，加共享锁可以使用select … lock in share mode语句。所以加过排他锁的数据行在其他事务种是不能修改数据的，也不能通过for update和lock in share mode锁的方式查询数据，但可以直接通过select …from…查询数据，因为普通查询没有任何锁机制。
总结
可以利用事务中更新操作自动排他锁并且事务提交后才释放锁的原理防止并发执行update，但是效率会变慢。
默认下insert 加间隙锁：http://book.51cto.com/art/200803/68128.htm ----有时候会表锁，和索引和事务隔离有关。对新增的数据间隙加锁，后面的新增操作无法写入。等待。如果这样那么默认下可以解决高并发的重复插入但是考虑到高并发下的效率就不宜。

实际MYSQL高并发的事务问题的解决办法

首先，多用户并发修改同一条记录时，肯定是后提交的用户将覆盖掉前者提交的结果了。
这个直接可以使用加锁机制去解决，乐观锁或者悲观锁。
乐观锁：
就是在数据库设计一个版本号的字段，每次修改都使其+1 ，这样在提交时比对提交前的版本号就知道是不是并发提交了，
但是有个缺点就是只能是应用中控制，如果有跨应用修改同一条数据乐观锁就没办法了，这个时候可以考虑悲观锁。
悲观锁：
就是直接在数据库层面将数据锁死，类似于oralce中使用select xxxxx from xxxx where xx=xx for update，这样其他线程将无法提交数据。
除了加锁的方式也可以使用接收锁定的方式，
思路是在数据库中设计一个状态标识位，用户在对数据进行修改前，将状态标识位标识为正在编辑的状态，这样其他用户要编辑此条记录时系统将发现有其他用户正在编辑，
则拒绝其编辑的请求，类似于你在操作系统中某文件正在执行，然后你要修改该文件时，系统会提醒你该文件不可编辑或删除。
其次，不建议在数据库层面加锁，建议通过服务端的内存锁（锁主键）。
当某个用户要修改某个id的数据时，把要修改的id存入memcache，若其他用户触发修改此id的数据时，读到memcache有这个id的值时，就阻止那个用户修改。
实际应用中，并不是让mysql去直面大并发读写，会借助“外力”，比如缓存、利用主从库实现读写分离、分表、使用队列写入等方法来降低并发读写。

秒杀的例子

总库存：4个商品
请求人：a、1个商品 b、2个商品 c、3个商品
程序如下：

beginTranse(开启事务)
try{
    $result = $dbca->query('select amount from s_store where postID = 12345');
    if(result->amount > 0){
        //quantity为请求减掉的库存数量
        $dbca->query('update s_store set amount = amount - quantity where postID = 12345');
    }
}catch($e Exception){
    rollBack(回滚)
}
commit(提交事务)

以上代码就是我们平时控制库存写的代码了，大多数人都会这么写，看似问题不大，其实隐藏着巨大的漏洞。
数据库的访问其实就是对磁盘文件的访问，数据库中的表其实就是保存在磁盘上的一个个文件，甚至一个文件包含了多张表。
例如由于高并发，当前有三个用户a、b、c三个用户进入到了这个事务中，这个时候会产生一个共享锁，所以在select的时候，这三个用户查到的库存数量都是4个，同时还要注意，mysql innodb查到的结果是有版本控制的，再其他用户更新没有commit之前(也就是没有产生新版本之前)，当前用户查到的结果依然是旧版本；
然后是update，假如这三个用户同时到达update这里，这个时候update更新语句会把并发串行化，也就是给同时到达这里的是三个用户排个序，一个一个执行，并生成排他锁，在当前这个update语句commit之前，其他用户等待执行，commit后，生成新的版本；这样执行完后，库存肯定为负数了。
但是根据以上描述，我们修改一下代码就不会出现超买现象了，代码如下：

beginTranse(开启事务)
try{
    //quantity为请求减掉的库存数量
    $dbca->query('update s_store set amount = amount - quantity where postID = 12345');
    $result = $dbca->query('select amount from s_store where postID = 12345');
    if(result->amount < 0){
       throw new Exception('库存不足');
    }
}catch($e Exception){
    rollBack(回滚)
}
commit(提交事务)

另外，更简洁的方法：

beginTranse(开启事务)
try{
    //quantity为请求减掉的库存数量
    $dbca->query('update s_store set amount = amount - quantity where amount>=quantity and postID = 12345');
}catch($e Exception){
    rollBack(回滚)
}
commit(提交事务)

MYSQL高并发的事务问题