面試題1：說(shuō)說(shuō)什么分布式事務(wù)？解釋一下什么是CAP？

現(xiàn)在互聯(lián)網(wǎng)開(kāi)發(fā)多使用微服務(wù)架構(gòu)，一個(gè)簡(jiǎn)單的操作，在服務(wù)端可能就是由多個(gè)服務(wù)和數(shù)據(jù)庫(kù)實(shí)例協(xié)同完成的。但在一致性要求較高且高QPS的場(chǎng)景下，多個(gè)獨(dú)立操作之間的一致性問(wèn)題和服務(wù)高可用問(wèn)題就顯得格外棘手。

基于對(duì)水平擴(kuò)容能力和成本考慮，針對(duì)除非敏感業(yè)務(wù)（如支付、轉(zhuǎn)賬等）外的大量其他業(yè)務(wù)，傳統(tǒng)的強(qiáng)一致的解決方案逐漸被淘汰。

其理論依據(jù)就是CAP原理。在分布式系統(tǒng)中，同時(shí)滿足CAP定律中的一致性 Consistency、可用性 Availability和分區(qū)容錯(cuò)性 Partition Tolerance三者是不可能的。在絕大多數(shù)的場(chǎng)景，為了可用性和分區(qū)容錯(cuò)性，都需要犧牲強(qiáng)一致性來(lái)?yè)Q取系統(tǒng)的高可用性，系統(tǒng)往往只需要保證最終一致性。

CAP理解：

Consistency：一致性就是在客戶端任何時(shí)候看到各節(jié)點(diǎn)的數(shù)據(jù)都是一致的。

Availability：可用性就是在任何時(shí)刻都可以提供讀寫。

Partition Tolerance：分區(qū)容錯(cuò)性是在網(wǎng)絡(luò)故障、某些節(jié)點(diǎn)不能通信的時(shí)候系統(tǒng)仍能繼續(xù)工作。

具體地講在分布式系統(tǒng)中，在任何數(shù)據(jù)庫(kù)設(shè)計(jì)中，一個(gè)Web應(yīng)用最多只能同時(shí)支持上面的兩個(gè)屬性。顯然，任何橫向擴(kuò)展策略都要依賴于數(shù)據(jù)分區(qū)。因此，設(shè)計(jì)人員必須在一致性與可用性之間做出選擇。

AP（高可用&&分區(qū)容錯(cuò)）:

允許至少一個(gè)節(jié)點(diǎn)更新?tīng)顟B(tài)會(huì)導(dǎo)致數(shù)據(jù)不一致，即喪失了C性質(zhì)（一致性）。會(huì)導(dǎo)致全局的數(shù)據(jù)不一致。

CP（一致&&分區(qū)容錯(cuò)）:

為了保證數(shù)據(jù)一致性，將分區(qū)一側(cè)的節(jié)點(diǎn)設(shè)置為不可用，那么又喪失了A性質(zhì)（可用性）。分區(qū)同步會(huì)導(dǎo)致同步時(shí)間無(wú)限延長(zhǎng)（也就是等數(shù)據(jù)同步完成之后才能正常訪問(wèn)）

CA（一致&&高可用）:

兩個(gè)節(jié)點(diǎn)可以互相通信，才能既保證C（一致性）又保證A（可用性），這又會(huì)導(dǎo)致喪失P性質(zhì)（分區(qū)容錯(cuò)性）。這樣的話就分布式節(jié)點(diǎn)受阻，無(wú)法部署子節(jié)點(diǎn),放棄了分布式系統(tǒng)的可擴(kuò)展性。因?yàn)榉植际较到y(tǒng)與單機(jī)系統(tǒng)不同，它涉及到多節(jié)點(diǎn)間的通訊和交互，節(jié)點(diǎn)間的分區(qū)故障是必然發(fā)生的，所以在分布式系統(tǒng)中分區(qū)容錯(cuò)性是必須要考慮的。

分布式事務(wù)服務(wù)

分布式事務(wù)服務(wù)（Distributed Transaction Service，DTS）是一個(gè)分布式事務(wù)框架，用來(lái)保障在大規(guī)模分布式環(huán)境下事務(wù)的最終一致性。

CAP理論告訴我們?cè)诜植际酱鎯?chǔ)系統(tǒng)中，最多只能實(shí)現(xiàn)上面的兩點(diǎn)。而由于當(dāng)前的網(wǎng)絡(luò)硬件肯定會(huì)出現(xiàn)延遲丟包等問(wèn)題，所以分區(qū)容忍性是我們必須需要實(shí)現(xiàn)的，所以我們只能在一致性和可用性之間進(jìn)行權(quán)衡。

為了保障系統(tǒng)的可用性，互聯(lián)網(wǎng)系統(tǒng)大多將強(qiáng)一致性需求轉(zhuǎn)換成最終一致性的需求，并通過(guò)系統(tǒng)執(zhí)行冪等性的保證，保證數(shù)據(jù)的最終一致性。

追問(wèn)1：怎么理解強(qiáng)一致性、弱一致性和最終一致性？

強(qiáng)一致性：當(dāng)更新操作完成之后，任何多個(gè)后續(xù)進(jìn)程或者線程的訪問(wèn)都會(huì)返回最新的更新過(guò)的值。這種是對(duì)用戶最友好的，就是用戶上一次寫什么，下一次就保證能讀到什么。根據(jù) CAP 理論，這種實(shí)現(xiàn)需要犧牲可用性。

弱一致性：系統(tǒng)并不保證后續(xù)進(jìn)程或者線程的訪問(wèn)都會(huì)返回最新的更新過(guò)的值。系統(tǒng)在數(shù)據(jù)寫入成功之后，不承諾立即可以讀到最新寫入的值，也不會(huì)具體的承諾多久之后可以讀到。

最終一致性：弱一致性的特定形式。系統(tǒng)保證在沒(méi)有后續(xù)更新的前提下，系統(tǒng)最終返回上一次更新操作的值。在沒(méi)有故障發(fā)生的前提下，不一致窗口的時(shí)間主要受通信延遲，系統(tǒng)負(fù)載和復(fù)制副本的個(gè)數(shù)影響。DNS 是一個(gè)典型的最終一致性系統(tǒng)。

  最終一致性是指系統(tǒng)中所有的副本經(jīng)過(guò)一段時(shí)間的異步同步之后，最終能夠達(dá)到一個(gè)一致性的狀態(tài)，也就是說(shuō)在數(shù)據(jù)的一致性上存在一個(gè)短暫的延遲。

  幾乎所有的互聯(lián)網(wǎng)系統(tǒng)采用的都是終一致性，只有在實(shí)在無(wú)法使用終一致性，才使用強(qiáng)一致性或事務(wù)，比如，對(duì)于決定系統(tǒng)運(yùn)行的敏感數(shù)據(jù)，需要考慮采用強(qiáng)一致性，對(duì)于與錢有關(guān)的支付系統(tǒng)或金融系統(tǒng)的數(shù)據(jù)，需要考慮采用事務(wù)。

  也就是說(shuō)能夠使用最終一致性的業(yè)務(wù)就盡量使用最終一致性，因?yàn)閺?qiáng)一致性會(huì)降低系統(tǒng)的可用性。

面試題2：了解BASE理論么？

在分布式系統(tǒng)中，我們往往追求的是可用性，它的重要程序比一致性要高，那么如何實(shí)現(xiàn)高可用性呢？前人已經(jīng)給我們提出來(lái)了另外一個(gè)理論，就是BASE理論，它是用來(lái)對(duì)CAP定理進(jìn)行進(jìn)一步擴(kuò)充的。BASE理論指的是：

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

BASE理論是對(duì)CAP中的一致性和可用性進(jìn)行一個(gè)權(quán)衡的結(jié)果，是對(duì)互聯(lián)網(wǎng)大規(guī)模分布式系統(tǒng)的實(shí)踐總結(jié)，強(qiáng)調(diào)可用性。

理論的核心思想就是：基本可用（Basically Available）和最終一致性（Eventually consistent）。雖然無(wú)法做到強(qiáng)一致，但每個(gè)應(yīng)用都可以根據(jù)自身的業(yè)務(wù)特點(diǎn)，采用適當(dāng)?shù)姆绞絹?lái)使系統(tǒng)達(dá)到最終一致性（Eventual consistency）。

追問(wèn)1：基于BASE理論，舉幾個(gè)實(shí)際的例子

我們以12306訂票系統(tǒng)為例

1.流量削峰

  可以在不同的時(shí)間，出售不同區(qū)域的票，將訪問(wèn)請(qǐng)求錯(cuò)開(kāi)，削弱請(qǐng)求峰值。比如，在春運(yùn)期間，深圳出發(fā)的火車票在 8 點(diǎn)開(kāi)售，北京出發(fā)的火車票在 9 點(diǎn)開(kāi)售。

2.延遲響應(yīng)

  在春運(yùn)期間，自己提交的購(gòu)票請(qǐng)求，往往會(huì)在隊(duì)列中排隊(duì)等待處理，可能幾分鐘或十幾分鐘后，系統(tǒng)才開(kāi)始處理，然后響應(yīng)處理結(jié)果。

3.體驗(yàn)降級(jí)

  比如用小圖片來(lái)替代原始圖片，通過(guò)降低圖片的清晰度和 大小，提升系統(tǒng)的處理能力。

4.過(guò)載保護(hù)

  比如把接收到的請(qǐng)求放在指定的隊(duì)列中排隊(duì)處理，如果請(qǐng)求等 待時(shí)間超時(shí)了（假設(shè)是 100ms），這個(gè)時(shí)候直接拒絕超時(shí)請(qǐng)求；再比如隊(duì)列滿了之后，就 清除隊(duì)列中一定數(shù)量的排隊(duì)請(qǐng)求，保護(hù)系統(tǒng)不過(guò)載，實(shí)現(xiàn)系統(tǒng)的基本可用。

 面試題3：實(shí)現(xiàn)分布式事務(wù)一致性（Consistency）的方法有哪些?

為了解決分布式系統(tǒng)的一致性問(wèn)題，在長(zhǎng)期的探索研究過(guò)程中，涌現(xiàn)出了一大批經(jīng)典的一致性協(xié)議和算法，其中最著名的就是二階段提交協(xié)議、三階段提交協(xié)議和Paxos算法。

追問(wèn)1：說(shuō)一下二階段提交（2PC）的原理吧

二階段提交（two-phase commit）增加了事務(wù)處理器和事務(wù)執(zhí)行者的角色。由事務(wù)處理器來(lái)進(jìn)行整個(gè)事務(wù)的處理。主要流程如下面的圖

兩階段提交協(xié)議

prepare(準(zhǔn)備階段)

當(dāng)開(kāi)始事務(wù)調(diào)用的時(shí)候，事務(wù)處理器向事務(wù)執(zhí)行者（有可能是數(shù)據(jù)庫(kù)本身支持）發(fā)出命令，事務(wù)執(zhí)行者進(jìn)行prepare操作。

當(dāng)所有事務(wù)執(zhí)行者都完成了prepare操作，就進(jìn)行下一步行為。

如果有一個(gè)事務(wù)執(zhí)行者在執(zhí)行prepare的時(shí)候失敗了，那么通知事務(wù)處理器，事務(wù)處理器再通知所有的事務(wù)執(zhí)行者執(zhí)行回滾操作。

commit(提交階段)

當(dāng)所有事務(wù)執(zhí)行者都prepare成功以后，事務(wù)處理器會(huì)再次發(fā)送commit請(qǐng)求給事務(wù)執(zhí)行者，所有事務(wù)執(zhí)行者進(jìn)行commit處理。

當(dāng)所有commit處理都成功了，那么事務(wù)執(zhí)行結(jié)束。

如果有一個(gè)事務(wù)執(zhí)行者的commit處理不成功，這個(gè)時(shí)候就要通知事務(wù)處理器，事務(wù)處理器通知所有的事務(wù)執(zhí)行者執(zhí)行回滾(abort)操作。

但是兩階段提交的詬病就是在于性能問(wèn)題。比如由于執(zhí)行鏈比較長(zhǎng)，鎖定資源的時(shí)間也變長(zhǎng)了。所以在高性能的系統(tǒng)中都會(huì)避免使用二階段提交。

總結(jié)

本篇文章就到這里了，希望能給你帶來(lái)幫助，也希望您能夠多多關(guān)注腳本之家的更多內(nèi)容!

最新評(píng)論