C# 数据库并发的解决方案（通用版、EF版）

还是那句老话：十年河东，十年河西，莫欺骚年穷！~_~ 打错个字，应该是莫欺少年穷！

学历代表你的过去，能力代表你的现在，学习代表你的将来。

学无止境，精益求精。

自ASP.NET诞生以来，微软提供了不少控制并发的方法，在了解这些控制并发的方法前，我们先来简单介绍下并发！

并发：同一时间或者同一时刻多个访问者同时访问某一更新操作时，会产生并发！

针对并发的处理，又分为悲观并发处理和乐观并发处理

所谓悲观/乐观并发处理，可以这样理解：

悲观者认为：在程序的运行过程中，并发很容易发生滴，因此，悲观者提出了他们的处理模式：在我执行一个方法时，不允许其他访问者介入这个方法。（悲观者经常认为某件坏事会发生在自己身上）

乐观者认为：在程序的运行过程中，并发是很少发生滴，因此，乐观者提出了他们的处理模式：在我执行一个方法时，允许其他访问者介入这个方法。（乐观者经常认为某件坏事不会发生在自己身上）

那么在C#语言中，那些属于悲观者呢？

在C#中诸如：LOCK、Monitor、Interlocked 等锁定数据的方式，属于悲观并发处理范畴！数据一旦被锁定，其他访问者均无权访问。有兴趣的可以参考：锁、C#中Monitor和Lock以及区别

但是，悲观者处理并发的模式有一个通病，那就是可能会造成非常低下的执行效率。

在此：举个简单例子：

售票系统，小明去买票，要买北京到上海的D110次列车，如果采用悲观者处理并发的模式，那么售票员会将D110次列车的票锁定，然后再作出票操作。但是，在D110次列车车票被锁定期间，售票员去了趟厕所，或者喝了杯咖啡，其他窗口售票员是不能进行售票滴！如果采用这种处理方式的话，中国14亿人口都不用出行了，原因是买不到票 ~_~

因此：在处理数据库并发时，悲观锁还是要谨慎使用！具体还要看数据库并发量大不大，如果比较大，建议使用乐观者处理模式，如果比较小，可以适当采用悲观者处理模式！

OK。说了这么多，也就是做个铺垫，本节内容标题叫数据库并发的解决方案，我们最终还得返璞归真，从数据库并发的解决说起！

那么问题来了？

数据库并发的处理方式有哪些呢？

其实数据库的并发处理也是分为乐观锁和悲观锁，只不过是基于数据库层面而言的！关于数据库层面的并发处理大家可参考我的博客：乐观锁悲观锁应用

悲观锁：假定会发生并发冲突，屏蔽一切可能违反数据完整性的操作。[1]

乐观锁：假设不会发生并发冲突，只在提交操作时检查是否违反数据完整性。[1] 乐观锁不能解决脏读的问题。

 最常用的处理多用户并发访问的方法是加锁。当一个用户锁住数据库中的某个对象时，其他用户就不能再访问该对象。加锁对并发访问的影响体现在锁的粒度上。比如，放在一个表上的锁限制对整个表的并发访问；放在数据页上的锁限制了对整个数据页的访问；放在行上的锁只限制对该行的并发访问。可见行锁粒度最小，并发访问最好，页锁粒度最大，并发访问性能就会越低。

悲观锁：假定会发生并发冲突，屏蔽一切可能违反数据完整性的操作。[1] 悲观锁假定其他用户企图访问或者改变你正在访问、更改的对象的概率是很高的，因此在悲观锁的环境中，在你开始改变此对象之前就将该对象锁住，并且直到你提交了所作的更改之后才释放锁。悲观的缺陷是不论是页锁还是行锁，加锁的时间可能会很长，这样可能会长时间的锁定一个对象，限制其他用户的访问，也就是说悲观锁的并发访问性不好。

乐观锁：假设不会发生并发冲突，只在提交操作时检查是否违反数据完整性。[1] 乐观锁不能解决脏读的问题。 乐观锁则认为其他用户企图改变你正在更改的对象的概率是很小的，因此乐观锁直到你准备提交所作的更改时才将对象锁住，当你读取以及改变该对象时并不加锁。可见乐观锁加锁的时间要比悲观锁短，乐观锁可以用较大的锁粒度获得较好的并发访问性能。但是如果第二个用户恰好在第一个用户提交更改之前读取了该对象，那么当他完成了自己的更改进行提交时，数据库就会发现该对象已经变化了，这样，第二个用户不得不重新读取该对象并作出更改。这说明在乐观锁环境中，会增加并发用户读取对象的次数。

本篇的主旨是讲解基于C#的数据库并发解决方案（通用版、EF版），因此我们要从C#方面入手，最好是结合一个小项目

项目已为大家准备好了，如下：