国产精品美女视频免费线播放,操美女屁股,欧美性生交大片免费看APP麻豆,美女啪啪啪网站,伊人久久免费,亚洲无码成人,成人做爰黄AA片免费看三区动漫 ,91视频久久久久久久久久久久

作者：葉東富

來源：SegmentFault 思否社區(qū)

概述

分布式事務(wù)是用來解決跨數(shù)據(jù)庫、跨服務(wù)更新數(shù)據(jù)一致性問題的。那么這里的一致性指的是什么，什么是強(qiáng)一致性，什么是弱一致性，與CAP理論中的一致性概念是一樣的嗎？本文將為您深入解答相關(guān)的問題。

一致性指什么

在數(shù)據(jù)庫的理論中，事務(wù)具備大家都熟悉的ACID特性，分別如下：

Atomicity（原子性）：一個(gè)事務(wù)中的所有操作，要么全部完成，要么全部不完成，不會(huì)結(jié)束在中間某個(gè)環(huán)節(jié)。事務(wù)在執(zhí)行過程中發(fā)生錯(cuò)誤，會(huì)被恢復(fù)到事務(wù)開始前的狀態(tài)，就像這個(gè)事務(wù)從來沒有執(zhí)行過一樣。
Consistency（一致性）：在事務(wù)開始之前和事務(wù)結(jié)束以后，數(shù)據(jù)庫的完整性沒有被破壞。完整性包括外鍵約束、應(yīng)用定義的等約束不會(huì)被破壞。
Isolation（隔離性）：數(shù)據(jù)庫允許多個(gè)并發(fā)事務(wù)同時(shí)對(duì)其數(shù)據(jù)進(jìn)行讀寫和修改的能力，隔離性可以防止多個(gè)事務(wù)并發(fā)執(zhí)行時(shí)由于交叉執(zhí)行而導(dǎo)致數(shù)據(jù)的不一致。
Durability（持久性）：事務(wù)處理結(jié)束后，對(duì)數(shù)據(jù)的修改就是永久的，即便系統(tǒng)故障也不會(huì)丟失。

對(duì)于這里面的C（一致性），我們以一個(gè)非常具體的業(yè)務(wù)例子，來進(jìn)行解釋。假如我們正在處理一個(gè)轉(zhuǎn)賬業(yè)務(wù)，假設(shè)是A轉(zhuǎn)給B 30元，在本地事務(wù)的支持下，我們的用戶看到A+B的總金額，在整個(gè)轉(zhuǎn)賬前后，以及轉(zhuǎn)賬過程中，都是保持不變的。那么這個(gè)時(shí)候用戶認(rèn)為他看到的數(shù)據(jù)是一致的，符合業(yè)務(wù)約束的。

當(dāng)我們業(yè)務(wù)變復(fù)雜，引入多個(gè)數(shù)據(jù)庫和大量微服務(wù)時(shí)，上述本地事務(wù)的一致性，依舊是業(yè)務(wù)非常關(guān)心。假如一個(gè)業(yè)務(wù)更新操作，跨庫或者跨服務(wù)時(shí)，那么此時(shí)業(yè)務(wù)關(guān)心的一致性問題，就變成了分布式事務(wù)中的一致性問題。

在單機(jī)本地事務(wù)中，A+B的總金額在任何時(shí)刻去查（以常見的ReadCommitted或ReadRepeatable隔離級(jí)別），都是不變的，也就是業(yè)務(wù)約束一直都保持的這種一致性，我們稱之為強(qiáng)一致性。

無法做到強(qiáng)一致

目前在跨庫、跨服務(wù)的分布式實(shí)際應(yīng)用中，尚未看到有強(qiáng)一致性的方案。

我們來看看一致性級(jí)別最高的XA事務(wù)，是否是強(qiáng)一致的，我們以跨行轉(zhuǎn)賬（在這里，我們以跨庫更新AB來模擬）作為例子來說明，下面是一個(gè)XA事務(wù)的時(shí)序圖：

在這個(gè)時(shí)序圖中，我們?cè)谌鐖D所示的時(shí)間點(diǎn)發(fā)起查詢，那么我們查到的數(shù)據(jù)，將是A+B+30，不等于A+B，不符合強(qiáng)一致的要求。

理論上的強(qiáng)一致性

我們接下來思考，普通XA事務(wù)不是強(qiáng)一致的，但假如完全不考慮性能因素，有沒有可能在理論上做到強(qiáng)一致：

我們先看看如果我們把XA事務(wù)涉及的數(shù)據(jù)庫，隔離級(jí)別設(shè)定到Serializable，是否能到到強(qiáng)一致的效果呢？我們來看看前面的時(shí)序場(chǎng)景：

這種情況下，查到結(jié)果等于A+B，但是又有另一些場(chǎng)景出現(xiàn)了問題，如下圖所示：

按照?qǐng)D中時(shí)序查詢的結(jié)果是：A+B-30，依舊是不一致。

深入思考這個(gè)強(qiáng)一致的問題之后，有一種做法可以做到強(qiáng)一致，做法如下：

對(duì)于查詢，也采用XA事務(wù)，并且查詢數(shù)據(jù)時(shí)，采用select for update的方式，所有數(shù)據(jù)查完之后，再xa commit
為了避免死鎖，需要將涉及到的數(shù)據(jù)庫排序，訪問數(shù)據(jù)都必須要按照相同的數(shù)據(jù)庫順序來寫入和查詢

在上述策略下，我們可以看到，在時(shí)序圖任何一個(gè)時(shí)間點(diǎn)進(jìn)行查詢，獲得的結(jié)果都是A+B

在T0時(shí)間查詢，那么修改一定發(fā)生在查詢?nèi)客瓿芍螅圆樵兊玫浇Y(jié)果A+B
在T1，T2，T3查詢，那么查詢結(jié)果返回一定全部發(fā)生在修改完成之后，所以查詢得到結(jié)果也是A+B

很明顯這種理論上的強(qiáng)一致，效率極低，所有有數(shù)據(jù)交集的數(shù)據(jù)庫事務(wù)都是串行執(zhí)行，而且還需要按照特定的順序查詢/修改數(shù)據(jù)，因此成本極高，幾乎無法應(yīng)用在生產(chǎn)中。

NewSQL的強(qiáng)一致性

我們討論了跨庫、跨微服務(wù)的分布式事務(wù)是無法做到強(qiáng)一致的，其實(shí)還有一種分布式數(shù)據(jù)內(nèi)部的事務(wù)，因?yàn)槭聞?wù)跨節(jié)點(diǎn)了，也被成為分布式事務(wù)。這種分布式事務(wù)是可以做到強(qiáng)一致的，這種強(qiáng)一致是通過MVCC的技術(shù)達(dá)到的，原理和單機(jī)的數(shù)據(jù)庫類似，但復(fù)雜很多。詳細(xì)的實(shí)現(xiàn)方法可以參考谷歌的percolator

未來有沒有可能借鑒NewSQL的這種方式，來實(shí)現(xiàn)跨庫、跨微服務(wù)這類分布式事務(wù)的強(qiáng)一致性？理論上是可以的。

實(shí)現(xiàn)跨服務(wù)但不跨庫的分布式事務(wù)一致性，會(huì)相對(duì)簡(jiǎn)單一些，其中一種方式就是實(shí)現(xiàn)XA事務(wù)中的TMRESUME選項(xiàng)（因?yàn)樽罱K只有一個(gè)xa commit，不會(huì)出現(xiàn)兩個(gè)xa commit中間的不一致時(shí)間窗口）。
實(shí)現(xiàn)跨數(shù)據(jù)庫的分布式事務(wù)一致性，會(huì)困難很多，因?yàn)楦鱾€(gè)數(shù)據(jù)庫的內(nèi)部版本機(jī)制都不一樣，想要協(xié)同非常困難。

弱一致性的分類

既然現(xiàn)有的各種分布式事務(wù)方案都無法做到強(qiáng)一致，那么弱一致性之間是否有差別呢？我們進(jìn)行了以下關(guān)于一致性強(qiáng)弱的分類：

一致性由強(qiáng)到弱分別是：

XA事務(wù)>消息>TCC>SAGA

這里的消息指的是本地消息表這種類型的分布式事務(wù)，關(guān)于這四種分布式事務(wù)的介紹，參見分布式事務(wù)最經(jīng)典的七種解決方案

地址：

https://segmentfault.com/a/1190000040321750

他們的分類為：

無中間態(tài)：數(shù)據(jù)只有兩個(gè)狀態(tài)，事務(wù)前和事務(wù)后，沒有其他第三種狀態(tài)。XA、消息這兩種都是這種
有中間態(tài)：數(shù)據(jù)有中間態(tài)，例如TCC的Try，數(shù)據(jù)狀態(tài)和事務(wù)前事務(wù)后都不一樣；SAGA也有中間態(tài)，假如一個(gè)SAGA事務(wù)執(zhí)行正向操作后數(shù)據(jù)為W，又回滾了，那么W也與事務(wù)前事務(wù)后的狀態(tài)不同。
XA：XA雖然不是強(qiáng)一致，但是XA的一致性是多種分布式事務(wù)中，一致性最好的，因?yàn)樗幱诓灰恢碌臓顟B(tài)時(shí)間很短，只有一部分分支開始commit，但還沒有全部commit的這個(gè)時(shí)間窗口，數(shù)據(jù)是不一致的。因?yàn)閿?shù)據(jù)庫的commit操作耗時(shí)，通常是10ms內(nèi)，因此不一致的窗口期很短。
消息：消息型在第一個(gè)操作完成后，在所有操作完成之前，這個(gè)時(shí)間窗口是不一致的，持續(xù)時(shí)長一般比XA更久。
TCC：TCC的中間態(tài)，通常可控，可以自定義。通常情況下，這部分?jǐn)?shù)據(jù)不展示給用戶，因此一致性比后面的SAGA要好。
SAGA：SAGA如果發(fā)生回滾，而子事務(wù)中正向操作修改的數(shù)據(jù)會(huì)被用戶看到，可能給用戶帶來較差的體驗(yàn)，因此一致性是最差的。

我們這里的分類僅僅從我們關(guān)心的幾個(gè)維度進(jìn)行了歸納，適用于多數(shù)場(chǎng)景，但并不一定適用所有情況。在實(shí)際的應(yīng)用中，也可能出現(xiàn)TCC的一致性比消息更好，例如我在Try中執(zhí)行xa prepare，Confirm中執(zhí)行xa commit，Cancel中執(zhí)行xa rollback，在這種實(shí)現(xiàn)下，TCC的一致性就跟XA一樣，一致性其實(shí)高于XA。

CAP理論中的一致性

我們這里討論的一致性是指數(shù)據(jù)庫中的一致性概念，與CAP中的一致性不同。

CAP中的強(qiáng)一致性是指用戶在分布式系統(tǒng)中寫完之后，立刻去讀，如果能夠像本地讀寫那樣，讀到最新版本，那么是強(qiáng)一致性。
分布式事務(wù)中的強(qiáng)一致性，是指事務(wù)進(jìn)行的過程中，用戶讀取的數(shù)據(jù)始終滿足業(yè)務(wù)約束，目前在實(shí)際應(yīng)用中的方案，都無法做到強(qiáng)一致。

上述兩者的強(qiáng)一致性在具體的含義上是不同的，但從用戶的視角看，也有共通性，即能否像單機(jī)系統(tǒng)一樣，不需要關(guān)心分布式帶來的新問題。

讀者通常會(huì)有另一個(gè)疑問，那就是分布式事務(wù)是一個(gè)分布式系統(tǒng)，那么在CAP中的一致性如何？

當(dāng)前Paxos/Raft等分布式共識(shí)協(xié)議已經(jīng)在工業(yè)領(lǐng)域有了成熟的實(shí)現(xiàn)，當(dāng)遇見機(jī)器故障或網(wǎng)絡(luò)隔離的情況時(shí)，可以做到大約幾百個(gè)毫秒到幾秒內(nèi)選舉出新的leader，從故障中恢復(fù)。也就是說CAP中，選擇CP，在A上面只有大約幾百個(gè)毫秒的不可用時(shí)間。

因此對(duì)于NewSQL或者分布式事務(wù)這類數(shù)據(jù)敏感性應(yīng)用，一般都選擇CAP中的CP，而犧牲幾百毫秒的A。因此在這方面，分布式事務(wù)是CAP中強(qiáng)一致的。例如我們的dtm分布式事務(wù)框架，將全局事務(wù)進(jìn)度保存在CP的數(shù)據(jù)庫中（云廠商大多提供了CP的數(shù)據(jù)庫）

總結(jié)

本文詳盡的分析了分布式事務(wù)中一致性相關(guān)的問題，在確認(rèn)沒有強(qiáng)一致性方案的情況下，分析了弱一致性分類及理論上可能的強(qiáng)一致方案。

本文許多內(nèi)容屬于首創(chuàng)，如有考慮不周的地方，歡迎讀者在評(píng)論區(qū)一起探討。

我們的公號(hào)：分布式事務(wù)
我們的項(xiàng)目：https://github.com/yedf/dtm
歡迎使用dtm，或者通過dtm學(xué)習(xí)實(shí)踐分布式事務(wù)相關(guān)知識(shí)，歡迎star支持我們

點(diǎn)擊左下角閱讀原文，到 SegmentFault 思否社區(qū) 和文章作者展開更多互動(dòng)和交流，掃描下方”二維碼“或在“公眾號(hào)后臺(tái)“回復(fù)“ 入群 ”即可加入我們的技術(shù)交流群，收獲更多的技術(shù)文章~

- END -

深入剖析分布式事務(wù)一致性

概述