Optimisation de la base de données MySQL (3) : verrouillage pessimiste MySQL et verrouillage optimiste (contrôle de concurrence)

1. Verrouillage pessimiste
1. Verrouillage exclusif Lorsqu'une transaction opère sur des données, cette partie des données est verrouillée jusqu'à ce que l'opération soit terminée et. puis déverrouillé, seules les autres opérations de transaction peuvent opérer sur cette partie des données. Cela empêchera d'autres processus de lire ou de modifier les données du tableau.

2. Mise en œuvre : Dans la plupart des cas, elle s'appuie sur le mécanisme de verrouillage de la base de données

Utilisez généralement select ...pour la mise à jour verrouille les données sélectionnées, par exemple select * from account which name="Max" pour la mise à jour, ce sql L'instruction verrouille tous les enregistrements de la table des comptes qui répondent aux conditions de récupération (name="Max"). Avant que cette transaction ne soit validée (le verrou pendant la transaction sera libéré lorsque la transaction sera validée), le monde extérieur ne peut pas modifier ces enregistrements.

2. Verrouillage optimiste
1. Si quelqu'un met à jour avant vous, votre mise à jour doit être rejetée Permet à l'utilisateur de refaire. -fonctionner.

2. Mise en œuvre : La plupart des implémentations sont basées sur le mécanisme d'enregistrement de la version des données (Version)

Détails spécifiques peut être Ceci est réalisé en ajoutant un champ de numéro de version ou d'horodatage au tableau Lors de la lecture des données, la valeur du champ de version est lue ensemble à chaque fois que les données sont mises à jour. la valeur est incrémentée de un. Lorsque nous soumettons une mise à jour, nous déterminons la taille des informations de version actuelle et la valeur de version supprimée pour la première fois. Si le numéro de version actuel de la table de base de données est égal à la valeur de version supprimée pour la première fois, ce sera le cas. être mis à jour. Dans le cas contraire, il sera considéré comme des données expirées et rejeté. La mise à jour permettra aux utilisateurs de ré-opérer.

3. Application du verrouillage pessimiste et du verrouillage optimiste dans le cadre ORM

En général, les verrous pessimistes et optimistes doivent être implémentés via la configuration des instructions SQL, de la conception des données et du code. Par exemple, le champ du numéro de version dans les verrous optimistes est uniquement destiné aux opérations de base de données, et vous devez le faire. implémentez vous-même l'optimisme. En bref, le verrouillage signifie que le champ du numéro de version ou de l'horodatage est géré par le programme lui-même, et que l'auto-incrémentation, la détermination de la taille et l'opportunité de mettre à jour sont tous implémentés par jugement de code. La base de données fournit deux idées, optimiste et pessimiste, pour le contrôle de la concurrence.

Pour les frameworks de persistance Java courants, ce mécanisme de base de données a sa propre implémentation. En prenant Hibernate comme exemple, résumez l'Application du framework ORM de pessimiste. verrouillage et verrouillage optimiste

1. Le verrouillage pessimiste d'Hibernate :

Mise en place d'un mécanisme de verrouillage basé sur une base de données. L'instruction de requête suivante :

String hqlStr ="from TUser as user where user.name=Max";
Query query = session.createQuery(hqlStr);
query.setLockMode("user",LockMode.UPGRADE); //加锁
List userList = query.list();//执行查询，获取数据

Observez l'instruction SQL générée par Hibernate pendant l'exécution :

select tuser0_.id as id, tuser0_.name as name, tuser0_.group_id as group_id, tuser0_.user_type as user_type, 
tuser0_.sex as sex from t_user tuser0_ where (tuser0_.name='Erica' ) for update

     这里Hibernate通过使用数据库的for update子句实现了悲观锁机制。对返回的所有user记录进行加锁。
2、Hibernate的加锁模式有：
     Ø LockMode.NONE ： 无锁机制。
     Ø LockMode.WRITE ：Hibernate在写操作（Insert和Update）时会自动获取写锁。
     Ø LockMode.READ ： Hibernate在读取记录的时候会自动获取。
     这三种锁机制一般由Hibernate内部使用，如Hibernate为了保证Update过程中对象不会被外界修改，会在save方法实现中自动为目标对象加上WRITE锁。
     Ø LockMode.UPGRADE ：利用数据库的for update子句加锁。
     Ø LockMode. UPGRADE_NOWAIT ：Oracle的特定实现，利用Oracle的for update nowait子句实现加锁。
     注意，只有在查询开始之前（也就是Hiberate 生成SQL 之前）设定加锁，才会真正通过数据库的锁机制进行加锁处理，否则，数据已经通过不包含for update子句的Select SQL加载进来，所谓数据库加锁也就无从谈起。

3、Hibernate的乐观锁

     Hibernate 在其数据访问引擎中内置了乐观锁实现。如果不用考虑外部系统对数据库的更新操作，利用Hibernate提供的透明化乐观锁实现，将大大提升我们的生产力。Hibernate中可以通过class描述符的optimistic-lock属性结合version描述符指定。具体实现方式如下：
     现在，我们为之前示例中的TUser加上乐观锁机制。
实现一、 配置optimistic-lock属性：

<hibernate-mapping>
     <class name="org.hibernate.sample.TUser" table="t_user" dynamic-update="true" dynamic-insert="true" optimistic-lock="version">
           ……
     </class>
</hibernate-mapping>

optimistic-lock属性有如下可选取值：
     Ø none：无乐观锁
     Ø version：通过版本机制实现乐观锁
     Ø dirty：通过检查发生变动过的属性实现乐观锁
     Ø all：通过检查所有属性实现乐观锁

     通过version实现的乐观锁机制是Hibernate官方推荐的乐观锁实现，同时也是Hibernate中，目前唯一在数据对象脱离Session发生修改的情况下依然有效的锁机制。因此，一般情况下，我们都选择version方式作为Hibernate乐观锁实现机制。
实现二、添加一个Version属性描述符

<hibernate-mapping>
     <class name="org.hibernate.sample.TUser" table="t_user"   dynamic-update="true" dynamic-insert="true" optimistic-lock="version"> 
	<id name="id" column="id" type="java.lang.Integer">
		<generator class="native"/>
	</id>
	<version column="version" name="version" type="java.lang.Integer"/>
……
     </class>
</hibernate-mapping>

     注意version 节点必须出现在ID 节点之后。这里声明了一个version属性，用于存放用户的版本信息，保存在TUser表的version字段中。

测试：

     此时如果我们尝试编写一段代码，更新TUser表中记录数据，如：

Criteria criteria = session.createCriteria(TUser.class);
criteria.add(Expression.eq("name","Max"));
List userList = criteria.list();
TUser user =(TUser)userList.get(0);
Transaction tx = session.beginTransaction();
user.setUserType(1); //更新UserType字段
tx.commit();

     每次对TUser进行更新的时候，我们可以发现，数据库中的version都在递增。而如果我们尝试在tx.commit 之前，启动另外一个Session，对名为Max的用户进行操作，下面模拟并发更新时的情况：

Session session= getSession();
Criteria criteria = session.createCriteria(TUser.class);
criteria.add(Expression.eq("name","Max"));
Session session2 = getSession();
Criteria criteria2 = session2.createCriteria(TUser.class);
criteria2.add(Expression.eq("name","Max"));
List userList = criteria.list();
List userList2 = criteria2.list();TUser user =(TUser)userList.get(0);
TUser user2 =(TUser)userList2.get(0);
Transaction tx = session.beginTransaction();
Transaction tx2 = session2.beginTransaction();
user2.setUserType(99);
tx2.commit();
user.setUserType(1);
tx.commit();

     执行并发更新的代码，在tx.commit()处抛出StaleObjectStateException异常，并指出版本检查失败，当前事务正在试图提交一个过期数据。通过捕捉这个异常，我们就可以在乐观锁校验失败时进行相应处理。

     这就是hibernate实现悲观锁和乐观锁的主要方式。

四、总结

     悲观锁相对比较谨慎，设想现实情况应该很容易就发生冲突，所以我还是独占数据资源吧。

     乐观锁就想得开而且非常聪明，应该是不会有什么冲突的，我对表使用一个时间戳或者版本号，每次读、更新操作都对这个字段进行比对，如果在我之前已经有人对数据进行更新了，那就让它更新，大不了我再读一次或者再更新一次。

     乐观锁的管理跟SVN管理代码版本的原理很像，如果在我提交代码之前用本地代码的版本号与服务器做对比，如果本地版本号小于服务器上最新版本号，则提交失败，产生冲突代码，让用户决定选择哪个版本继续使用。
     在实际生产环境里边,如果并发量不大且不允许脏读，可以使用悲观锁；但如果系统的并发非常大的话,悲观锁定会带来非常大的性能问题,所以我们就要选择乐观锁定的方法        另外，Mysql在处理并发访问数据上，还有添加读锁（共享锁）、写锁（排它锁），控制锁粒度【表锁（table lock）、行级锁（row lock）】等实现，有兴趣可以继续研究。

 以上就是MySQL数据库优化（三）—MySQL悲观锁和乐观锁（并发控制）的内容，更多相关内容请关注PHP中文网（www.php.cn）！