关于mysql:数据库漫谈四

51次阅读

共计 2211 个字符,预计需要花费 6 分钟才能阅读完成。

明天来聊一下多 PROCESS 同时更新一条数据记录时解决形式。

咱们先来给明天的问题拆成两个子问题:

1.  只有一台主数据库时多个解决(PROCESS)更新同一条记录。2.  多主架构时不同的节点上的多个解决(PROCESS)更新同一条记录。

先说第一个问题,这个其实是一个常见的问题,解决办法也是基本相同的,就是给记录加锁,先拿到锁的解决先执行,实现后开释锁,后边的解决再拿锁。

然而具体的处理过程就很有考究了,因为“”分为“ 乐观锁 ”和“ 乐观锁”。

什么是“乐观锁”(Pessimistic Lock)呢?

当要对数据库中的一条数据进行批改的时候,为了防止同时被其他人批改,最好的方法就是间接对该数据进行加锁以避免并发。

这种借助数据库锁机制,在批改数据之前先锁定,再批改的形式被称之为乐观并发管制【Pessimistic Concurrency Control,缩写“PCC”,又名“乐观锁”】。

乐观锁,正如其名,具备强烈的独占和排他个性。它指的是对数据被外界 (包含本零碎以后的其余事务,以及来自内部零碎的事务处理) 批改持激进态度。

因而,在整个数据处理过程中,将数据处于锁定状态。乐观锁的实现,往往依附数据库提供的锁机制。

之所以叫做乐观锁,是因为这是一种对数据的批改持有乐观态度的并发管制形式。总是假如最坏的状况,每次读取数据的时候都默认其余线程会更改数据,因而须要进行加锁操作,当其余线程想要拜访数据时,都须要阻塞挂起。

那什么又是“乐观锁”(Optimistic Locking)呢?

乐观锁是绝对乐观锁而言的,乐观锁假如数据个别状况下不会造成抵触,所以在数据进行提交更新的时候,才会正式对数据的抵触与否进行检测,如果发现抵触了,则返回给用户谬误的信息,让用户决定如何去做。乐观锁实用于读操作多的场景,这样能够进步程序的吞吐量。

乐观锁机制采取了更加宽松的加锁机制。乐观锁是绝对乐观锁而言,也是为了防止数据库幻读、业务解决工夫过长等起因引起数据处理谬误的一种机制,但乐观锁不会刻意应用数据库自身的锁机制,而是根据数据自身来保证数据的正确性。

从下面的阐明咱们能够明确了,乐观并发管制实际上是“先取锁再拜访”的激进策略,为数据处理的平安提供了保障。然而在效率方面,解决加锁的机制会让数据库产生额定的开销,还有减少产生死锁的机会。另外还会升高并行性,一个事务如果锁定了某行数据,其余事务就必须期待该事务处理完才能够解决那行数据。而乐观并发管制置信事务之间的数据竞争 (data race) 的概率是比拟小的,因而尽可能间接做上来,直到提交的时候才去锁定,所以不会产生任何锁和死锁。

在明确了下面针对一台主数据库时多个解决(PROCESS)更新同一条记录的解决形式之后,咱们把问题再向深推动一下。

当一个零碎的并发解决进一步提高,一台主数据库不足以满足要求的时候,就须要对数据库进行横向拓展了。

上面咱们用例子阐明一下解决这个问题的几个方向。

1.  数据库实例和存储离开,多个实例共用一个存储。2.  数据库实例和存储不离开,每个数据库实例写本人的存储,而后进行实例间同步。

在第一个方向上做的最胜利的就是 ORACLE 数据库的 RAC 架构。

ORACLE 数据库的 RAC 架构引入了“内存交融”(Cache Fusion)的概念,简略来说就是在多个数据库实例之间搭建一个高速局域网,用几个特定的 PROCESS 同步各自的 SGA。当然具体的实现形式要简单得多,能够专门写几篇文章来详述了。

第二个方向上实现的比拟好的有两个产品:ORACLE GoldenGate 和 Mysql 的双主架构。

先说 ORACLE GoldenGate。

GoldenGate 最开始并不是 ORACLE 的产品,而是一个 1995 年成立在美国旧金山的专门开发计算机容错零碎的公司,名字也是来源于旧金山驰名的金门大桥。GoldenGate 公司于 2009 年 9 月被 Oracle 收买,纳入交融中间件(Fusion Middleware)产品线中,作为 ORALCE 数据库(或其余数据库)的容灾、复制的解决方案。

下面是从网上找来的介绍 GoldenGate 的 yizhang 简略的图片,大家能够先看一下,当前有机会的话咱们再写一篇文章来专门聊一下。

而后咱们来说一下 Mysql 的双主架构。

MySQL 最早来源于 MySQL AB 公司前身的 ISAM 与 mSQL 我的项目,2008 年 1 月,MySQL AB 公司被 Sun 公司以 10 亿美金收买。2009 年 4 月,Oracle 公司以 74 亿美元收买 Sun 公司,自此 MySQL 数据库进入 Oracle 时代。
MySQL 最胜利的中央是 SQL 实现层和存储引擎离开以及 Binlog。

SQL 实现层和存储引擎离开的设计使得 Mysql 能够兼容各种其余公司开发的存储引擎,能够满足各种场景的不同须要。

而 Binlog 以及传递和复制机制则能够使 Mysql 设计出各种各样的高可用架构。

下面就是一个最简略的 Mysql 主从架构。通过这个图片咱们能够理解 Binlog 是如何工作的。

当初咱们下面的主从地位颠倒过去再做一遍,即两 ge 数据库互为主从,就实现了最简略的双主架构。

当然下面的双主架构在自增主键和批改同一记录的更新上还须要一些 Application 和数据库设计上的反对。具体如何实现我也不是这方面的专家,大家能够多上网学习一下,呵呵。

本文援用了日常更新针对锁的阐明和图片,特此感激!
https://www.jianshu.com/p/d2ac26ca6525

正文完
 0