免费视频淫片aa毛片_日韩高清在线亚洲专区vr_日韩大片免费观看视频播放_亚洲欧美国产精品完整版

前言

我們都知道數(shù)據(jù)庫的事務滿足'ACID'特性，A是指事務的原子性，C是指事務的一致性，I指事務的隔離性，D指持久性。
最開始我們的數(shù)據(jù)量都很小，所有的數(shù)據(jù)都落在一個數(shù)據(jù)庫中。MySQL數(shù)據(jù)庫單表的最大數(shù)據(jù)量在百萬條左右，隨著系統(tǒng)變大，數(shù)據(jù)越來越多，這個時候我們不得不將數(shù)據(jù)分布在不同的數(shù)據(jù)庫中存放，也就是常說的數(shù)據(jù)分片（sharding）。我們可以通過一定的分庫策略將同一個交易鏈路上的數(shù)據(jù)放到一個數(shù)據(jù)庫中，例如我們可以將一個訂單所有產(chǎn)生的數(shù)據(jù)放到一個數(shù)據(jù)庫中，按照訂單號來分庫，這樣我們在生成訂單相關數(shù)據(jù)的時候可以在單個數(shù)據(jù)庫上開啟事務來完成。
這樣看似完美的解決方案其實并不完美。例如我們想記錄用戶維度的訂單數(shù)據(jù)時，這個方案就無能為力了。于是分布式事務應運而生。

分布式系統(tǒng)CAP BASE理論

說到分布式系統(tǒng)，不得不說CAP和BASE理論，它是指導我們分布式系統(tǒng)的理論基礎。

CAP理論

加州大學伯克利分校Eric Brewer教授支持一個分布式系統(tǒng)無法滿足這樣三條特性：

1. Consistency，一致性：多個操作同時生效，不會出現(xiàn)部分生效的情況
2. Availability，可用性：客戶端的每個請求在服務端能夠正確被響應
3. Partition tolerance，分區(qū)容錯性：分區(qū)中部分節(jié)點掛了不會影響整體服務可用性，這也是分布式系統(tǒng)最基本的要求

分區(qū)容錯性是一個分布式系統(tǒng)最基本的要求，因此一般分布式系統(tǒng)都會滿足分區(qū)容錯性，否則就失去了分布式系統(tǒng)的意義。分布式系統(tǒng)一般會在一致性和可用性上做出取舍。例如犧牲一致性換區(qū)可用性，這里說的犧牲一致性是指犧牲掉系統(tǒng)的'強一致性'，最終我們的系統(tǒng)還是一致的，即所謂的'弱一致性'或者'最終一致性'。當我們的系統(tǒng)需要保證強一致性時我們不得不犧牲掉可用性：當系統(tǒng)部分節(jié)點延遲或者down機整個系統(tǒng)的服務將變得不可用，也因此系統(tǒng)數(shù)據(jù)是強一致性的。

BASE理論

BASE理論是對CAP理論的進一步擴充：

1. Basically Available（基本可用）
2. Soft state（軟狀態(tài)）
3. Eventually consistent（最終一致性）

基本可用是指我們的系統(tǒng)無法做到百分百可用，但是可以保證例如'3個9'(99.9%)可用。軟狀態(tài)是指允許我們的系統(tǒng)存在中間狀態(tài)，在最終我們的系統(tǒng)可以達到最終一致性。BASE理論強調(diào)的是系統(tǒng)的最終一致性。

分布式事務

目前分布式事務的解決方案主要有：二階段提交（2PC）、柔性補償事務（TCC）、本地消息表（異步確保）、MQ事務消息等。

二階段提交

二階段事務分為兩個階段：階段一事務協(xié)調(diào)者通知各個節(jié)點執(zhí)行事務預提交；階段二協(xié)調(diào)者根據(jù)各個節(jié)點的響應來通知各個節(jié)點提交或者回滾事務操作。
兩階段提交這種解決方案屬于犧牲了一部分可用性來換取的一致性。
優(yōu)點： 盡量保證了數(shù)據(jù)的強一致，適合對數(shù)據(jù)強一致要求很高的關鍵領域。（其實也不能100%保證強一致）
缺點： 實現(xiàn)復雜，犧牲了可用性，同步阻塞對性能影響較大，不適合高并發(fā)高性能場景。

二階段提交

補償事務（TCC）

TCC 其實就是采用的補償機制，其核心思想是：針對每個操作，都要注冊一個與其對應的確認和補償（撤銷）操作。它分為三個階段：
Try 階段主要是對業(yè)務系統(tǒng)做檢測及資源預留
Confirm 階段主要是對業(yè)務系統(tǒng)做確認提交，Try階段執(zhí)行成功并開始執(zhí)行 Confirm階段時，默認 Confirm階段是不會出錯的。即：只要Try成功，Confirm一定成功。
Cancel 階段主要是在業(yè)務執(zhí)行錯誤，需要回滾的狀態(tài)下執(zhí)行的業(yè)務取消，預留資源釋放。
舉個例子，假入 Bob 要向 Smith 轉(zhuǎn)賬，思路大概是：
我們有一個本地方法，里面依次調(diào)用

1. 首先在 Try 階段，要先調(diào)用遠程接口把 Smith 和 Bob 的錢給凍結(jié)起來。
2. 在 Confirm 階段，執(zhí)行遠程調(diào)用的轉(zhuǎn)賬的操作，轉(zhuǎn)賬成功進行解凍。
3. 如果第2步執(zhí)行成功，那么轉(zhuǎn)賬成功，如果第二步執(zhí)行失敗，則調(diào)用遠程凍結(jié)接口對應的解凍方法 (Cancel)。
   優(yōu)點： 跟2PC比起來，實現(xiàn)以及流程相對簡單了一些，但數(shù)據(jù)的一致性比2PC也要差一些
   缺點： 缺點還是比較明顯的，在2,3步中都有可能失敗。TCC屬于應用層的一種補償方式，所以需要程序員在實現(xiàn)的時候多寫很多補償?shù)拇a，在一些場景中，一些業(yè)務流程可能用TCC不太好定義及處理。

TCC柔性事務

本地消息表（異步確保）

本地消息表這種實現(xiàn)方式應該是業(yè)界使用最多的，其核心思想是將分布式事務拆分成本地事務進行處理，這種思路是來源于ebay。我們可以從下面的流程圖中看出其中的一些細節(jié)：

本地消息表

基本思路就是：
消息生產(chǎn)方，需要額外建一個消息表，并記錄消息發(fā)送狀態(tài)。消息表和業(yè)務數(shù)據(jù)要在一個事務里提交，也就是說他們要在一個數(shù)據(jù)庫里面。然后消息會經(jīng)過MQ發(fā)送到消息的消費方。如果消息發(fā)送失敗，會進行重試發(fā)送。
消息消費方，需要處理這個消息，并完成自己的業(yè)務邏輯。此時如果本地事務處理成功，表明已經(jīng)處理成功了，如果處理失敗，那么就會重試執(zhí)行。如果是業(yè)務上面的失敗，可以給生產(chǎn)方發(fā)送一個業(yè)務補償消息，通知生產(chǎn)方進行回滾等操作。
生產(chǎn)方和消費方定時掃描本地消息表，把還沒處理完成的消息或者失敗的消息再發(fā)送一遍。如果有靠譜的自動對賬補賬邏輯，這種方案還是非常實用的。
這種方案遵循BASE理論，采用的是最終一致性，筆者認為是這幾種方案里面比較適合實際業(yè)務場景的，即不會出現(xiàn)像2PC那樣復雜的實現(xiàn)(當調(diào)用鏈很長的時候，2PC的可用性是非常低的)，也不會像TCC那樣可能出現(xiàn)確認或者回滾不了的情況。
優(yōu)點： 一種非常經(jīng)典的實現(xiàn)，避免了分布式事務，實現(xiàn)了最終一致性。
缺點： 消息表會耦合到業(yè)務系統(tǒng)中，如果沒有封裝好的解決方案，會有很多雜活需要處理。

MQ事務消息

有一些第三方的MQ是支持事務消息的，比如RocketMQ，他們支持事務消息的方式也是類似于采用的二階段提交，但是市面上一些主流的MQ都是不支持事務消息的，比如 RabbitMQ 和 Kafka 都不支持。
以阿里的 RocketMQ 中間件為例，其思路大致為：
第一階段Prepared消息，會拿到消息的地址。
第二階段執(zhí)行本地事務，第三階段通過第一階段拿到的地址去訪問消息，并修改狀態(tài)。
也就是說在業(yè)務方法內(nèi)要想消息隊列提交兩次請求，一次發(fā)送消息和一次確認消息。如果確認消息發(fā)送失敗了RocketMQ會定期掃描消息集群中的事務消息，這時候發(fā)現(xiàn)了Prepared消息，它會向消息發(fā)送者確認，所以生產(chǎn)方需要實現(xiàn)一個check接口，RocketMQ會根據(jù)發(fā)送端設置的策略來決定是回滾還是繼續(xù)發(fā)送確認消息。這樣就保證了消息發(fā)送與本地事務同時成功或同時失敗。

優(yōu)點： 實現(xiàn)了最終一致性，不需要依賴本地數(shù)據(jù)庫事務。
缺點： 實現(xiàn)難度大，主流MQ不支持。

MQ事務消息

總結(jié)

1. 目前分布式事務主要有：二階段提交、TCC柔性事務、本地消息表（異步確保）和MQ事務消息等解決方案。二階段提交可以確保數(shù)據(jù)的強一致性，其他的解決方案屬于最終一致性解決方案。
2. 分布式事務雖然能保證數(shù)據(jù)的強一致性，但是性能低。使用前需要確定是否真的需要分布式事務。