MySQL-Datenbankoptimierung (3) – MySQL-pessimistisches Sperren und optimistisches Sperren (Parallelitätskontrolle)

1. Pessimistische Sperre
1. Exklusive Sperre Wenn eine Transaktion Daten verarbeitet, wird dieser Teil der Daten gesperrt, bis der Vorgang abgeschlossen ist dann entsperrt, können nur andere Transaktionsvorgänge mit diesem Teil der Daten durchgeführt werden. Dadurch wird verhindert, dass andere Prozesse die Daten in der Tabelle lesen oder ändern.

2. Implementierung: In den meisten Fällen basiert es auf dem Sperrmechanismus der Datenbank

Im Allgemeinen verwenden Sie „select ...“, um die ausgewählten Daten durch Aktualisierung zu sperren, z. B. select * from account where name="Max" for update, this sql Die Anweisung sperrt alle Datensätze in der Kontotabelle, die die Abrufbedingungen erfüllen (name="Max"). Bevor diese Transaktion festgeschrieben wird (die Sperre während der Transaktion wird aufgehoben, wenn die Transaktion festgeschrieben wird), kann die Außenwelt diese Datensätze nicht ändern.

2. Optimistische Sperre
1. Wenn jemand vor Ihnen ein Update durchführt, sollte Ihr Update abgelehnt werden -arbeiten.

2. Implementierung: Die meisten Implementierungen basieren auf dem Aufzeichnungsmechanismus der Datenversion (Version)

Spezifische Details Dies kann erreicht werden, indem ein Versionsnummern- oder Zeitstempelfeld zur Tabelle hinzugefügt wird. Beim Lesen von Daten wird der Wert des Versionsfelds zusammen mit der Version ausgelesen Der Wert wird um eins erhöht. Wenn wir ein Update einreichen, ermitteln wir die Größe der aktuellen Versionsinformationen und den zum ersten Mal entnommenen Versionswert. Wenn die aktuelle Versionsnummer der Datenbanktabelle dem zum ersten Mal entnommenen Versionswert entspricht, wird dies der Fall sein Andernfalls werden die Daten als abgelaufen betrachtet und die Aktualisierung wird abgelehnt.

3. Anwendung der pessimistischen Sperre und der optimistischen Sperre im ORM-Framework

Im Allgemeinen müssen pessimistische Sperren und optimistische Sperren durch die Einstellung von SQL-Anweisungen, Datendesign und Code implementiert werden. Beispielsweise dient das Versionsnummernfeld in optimistischen Sperren ausschließlich Datenbankoperationen, und das müssen Sie tun Kurz gesagt, das Sperren bedeutet, dass die Versionsnummer oder das Zeitstempelfeld vom Programm selbst verwaltet werden und die Selbstinkrementierung, die Größenbestimmung und die Aktualisierungsmöglichkeit alle durch Codebeurteilung implementiert werden. Die Datenbank bietet zwei Ideen, optimistisch und pessimistisch, für die Parallelitätskontrolle.

Für gängige Java-Persistenz-Frameworks verfügt dieser Mechanismus der Datenbank über eine eigene Implementierung. Am Beispiel von Hibernate fassen wir die ORM-Framework-Anwendung zusammen pessimistische Sperre und optimistische Sperre

1. Pessimistische Sperre von Hibernate:

Implementierung eines datenbankbasierten Sperrmechanismus. Die folgende Abfrageanweisung:

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

Beobachten Sie die von Hibernate während der Laufzeit generierte SQL-Anweisung :

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）！