華為云GaussDB(for Redis)揭秘第15期：為什么需要強一致

有人說，開源Redis的最終一致性已經(jīng)能滿足大部分應(yīng)用場景，也有人說，多副本的強一致代價太大，沒有必要實現(xiàn)。要筆者說，其實弱一致性已經(jīng)不滿足很多應(yīng)用場景的訴求。怎么，不信？請聽筆者娓娓道來。

1.?不一致帶來的困擾

1.1 秒殺變秒崩

分享一個電商秒殺活動中限流器的例子，在電商的秒殺活動中，為了扛住前端對數(shù)據(jù)庫的超大流量沖擊，一般使用兩種方案來保護系統(tǒng)，一個是緩存，另一個則是限流。緩存這個容易實現(xiàn)，只需要在數(shù)據(jù)庫前加一層緩存服務(wù)器，而對于限流來說，最簡單的可以使用Redis的計數(shù)器來實現(xiàn)限流功能。

具體來說，假設(shè)我們需要對某個接口限定流量為5000qps，即每秒鐘訪問的次數(shù)不能超過5000。那么我們可以這么做：在一開始的時候設(shè)置一個計數(shù)器counter為5000，并且過期時間為1s，即1s后計數(shù)器失效。每當(dāng)一個請求過來的時候，counter的值減1，判斷當(dāng)前counter的值是否等于0，如果等于，則說明請求次數(shù)過多，直接拒絕請求。如果counter計數(shù)器不存在，則重置計數(shù)器為5000，開始新一秒的接口限流，注意并發(fā)情況下計數(shù)器需要加鎖。

正常情況下，這種方案不會出現(xiàn)問題，但是針對這種秒殺活動，不怕一萬，就怕萬一，萬一Redis突然宕機怎么辦，那豈不是限流器形同虛設(shè)，所有流量全部涌向后端的數(shù)據(jù)庫，瞬間系統(tǒng)崩潰。此時聰明的你肯定會想到，給Redis搞一個備用服務(wù)器不就解決了，主服務(wù)器如果宕機，備用服務(wù)器頂上。沒錯，這種方案是對的，但是只正確了一半。為什么呢，如下圖所示。

當(dāng)給Redis配置從服務(wù)器之后，如果主服務(wù)器出現(xiàn)宕機，可以立刻切換到從服務(wù)器，但是由于開源Redis主從服務(wù)器之間的數(shù)據(jù)是異步復(fù)制的，如果網(wǎng)絡(luò)不暢，經(jīng)常發(fā)生主從數(shù)據(jù)不一致，如果此時主服務(wù)器發(fā)生宕機，切換到從服務(wù)器之后，因為限流器的判斷出錯，流量壓力很容易超出閾值，一下子涌向數(shù)據(jù)庫服務(wù)器，同樣會造成系統(tǒng)崩潰。

仔細探究這個問題產(chǎn)生，根因是在于開源Redis的一致性機制為弱一致性，在某些時間內(nèi)，主從副本數(shù)據(jù)不一致。而要徹底解決這個問題，只有真正的強一致才能解決。

1.2 難以維護的MySQL組件

其實不止Redis，就連大名鼎鼎的MySQL也逃不過弱一致的坑。MySQL的部署中，為了保證高可用性，主從熱備份是MySQL常用的部署方式。但是如果發(fā)生故障時，僅僅靠MySQL自身的同步機制，是無法保證主庫和從庫之前的數(shù)據(jù)一致的，于是出現(xiàn)了重要的輔助組件MHA(Master High Availability)，它的部署方式如下：

MHA由管理服務(wù)和Node服務(wù)組成，Node服務(wù)部署在每個MySQL節(jié)點上，MHA組件負(fù)責(zé)讓MySQL的從庫盡可能的追平主庫，提供主從一致的狀態(tài)。發(fā)生故障進行主從切換時，Manager首先為從庫補充落后的數(shù)據(jù)，然后再將用戶訪問切換到從庫，這個過程可能長達數(shù)十秒。

MHA的部署和維護都相當(dāng)復(fù)雜，如未能順利執(zhí)行故障切換或發(fā)生數(shù)據(jù)丟失，運維面臨的場面都將很棘手。其實運維同學(xué)何嘗不希望手中的系統(tǒng)穩(wěn)定運行呢？要是數(shù)據(jù)庫自身能提供強一致保障，何苦再依賴復(fù)雜的輔助組件！

2.?什么是強一致

上一節(jié)中筆者介紹了弱一致帶來各種問題，接下來這一節(jié)具體介紹下什么是強一致。在“分布式系統(tǒng)”和“數(shù)據(jù)庫”這兩個領(lǐng)域中，一致性都是重要概念，但它表達的內(nèi)容卻并不相同。對于分布式系統(tǒng)而言，一致性是在探討當(dāng)系統(tǒng)內(nèi)的一份邏輯數(shù)據(jù)存在多個物理的數(shù)據(jù)副本時，對其執(zhí)行讀寫操作會產(chǎn)生什么樣的結(jié)果，這也符合 CAP 理論對一致性的表述。而在數(shù)據(jù)庫領(lǐng)域，“一致性”與事務(wù)密切相關(guān)，又進一步細化到 ACID 四個方面。因此，當(dāng)我們談?wù)摲植际綌?shù)據(jù)庫的一致性時，實質(zhì)上是在談?wù)撌聞?wù)一致性和數(shù)據(jù)一致性兩個方面。

2.1?事務(wù)一致性

事務(wù)的一致性主要是指的事務(wù)的ACID，分別是原子性、一致性、隔離性和持久性，如下圖所示：

原子性：事務(wù)中的所有變更要么全部發(fā)生，要么一個也不發(fā)生，通過日志技術(shù)實現(xiàn)；

一致性：事務(wù)要保持?jǐn)?shù)據(jù)的完整性，它是應(yīng)用程序的屬性，依賴原子性和隔離屬性來實現(xiàn)；

隔離性：多事務(wù)并行執(zhí)行所得到的結(jié)果，與串行執(zhí)行（一個接一個）完全相同，通過并發(fā)控制技術(shù)來實現(xiàn)；

持久性：一旦事務(wù)提交，它對數(shù)據(jù)的改變將被永久保留，不應(yīng)受到任何系統(tǒng)故障的影響，通過日志技術(shù)實現(xiàn)。

2.2?數(shù)據(jù)一致性

在分布式系統(tǒng)中，為了避免網(wǎng)絡(luò)不可靠帶來的問題，通常會存儲多個數(shù)據(jù)副本，邏輯上的一份數(shù)據(jù)存儲在多個物理副本上，自然帶來了數(shù)據(jù)一致性問題。

（1）狀態(tài)視角

從狀態(tài)的視角來看，任何變更操作后，數(shù)據(jù)只有兩種狀態(tài)，所有副本一致或者不一致。在某些條件下，不一致的狀態(tài)是暫時，還會轉(zhuǎn)換到一致的狀態(tài)，而那些永遠不一致的情況幾乎不會去討論，所以習(xí)慣上大家會把不一致稱為“弱一致”。相對的，一致就叫做“強一致”了。以一個一主兩備的MySQL集群為例，“強一致”的交互過程如下：

在該模式下，主庫與備庫同步 binlog 時，主庫只有在收到兩個備庫的成功響應(yīng)后，才能夠向客戶端反饋提交成功。顯然，用戶獲得響應(yīng)時，主庫和備庫的數(shù)據(jù)副本已經(jīng)達成一致，所以后續(xù)的讀操作肯定是沒有問題的，這就是狀態(tài)視角的”強一致”的模型。

但是狀態(tài)視角的這種強一致副作用很大：第一個是性能很差，主庫必須要等備庫1和備庫2成功返回后，主庫才返回；第二個是可用性問題，如果主備節(jié)點很多，出現(xiàn)故障的概率非常高。因此狀態(tài)視角的強一致代價非常大，因此很少使用。

（2）操作視角

狀態(tài)視角的強一致降低了系統(tǒng)的可用性，因此很多系統(tǒng)選擇狀態(tài)視角的弱一致性模型，通過額外的算法（如Raft、Paxos）在不保證所有節(jié)點狀態(tài)的一致的情況下，來保證操作視角的一致性，同時提高了系統(tǒng)的可用性。通過加入一些限定條件，衍生出了若干種一致性模型：

線性一致性：操作視角實現(xiàn)真正的強一致

順序一致性：一致性強度弱于線性一致性

因果一致性：一致性強度弱于順序一致性

寫后讀一致性：一致行強度相當(dāng)，弱于因果一致性

這些一致性模型的介紹參考《高斯Redis與強一致》這篇文章。

3.?強一致的剛需場景

上一節(jié)我們介紹了什么是強一致，這一節(jié)中我們介紹介紹下我們強一致的典型應(yīng)用場景。

在常見的互聯(lián)網(wǎng)應(yīng)用中，如果數(shù)據(jù)庫服務(wù)器只部署在單個節(jié)點上，那么應(yīng)用程序所有的讀和寫都只會訪問單個節(jié)點，一份邏輯數(shù)據(jù)在物理上也只有一份，這種場景下就談不上強一致的問題。

但是隨著系統(tǒng)中業(yè)務(wù)訪問量的增加，如果是單機部署數(shù)據(jù)庫，就會導(dǎo)致I/O訪問頻率過高，數(shù)據(jù)庫就會成為系統(tǒng)的瓶頸。此時，為了降低單機磁盤的I/O訪問頻率，提高單個機器的I/O性能，通常會增加多個數(shù)據(jù)存儲節(jié)點，形成一主一從或者一主多重的架構(gòu)，

此時，我們可以將負(fù)載分布在多個從節(jié)點上，一方面可以實現(xiàn)讀寫分離，寫請求訪問主庫，讀請求訪問備庫。另一方面，還可以在主庫如果出現(xiàn)宕機的情況下進行主備切換，增強系統(tǒng)的穩(wěn)定性。在以上兩個場景中，由于一份邏輯數(shù)據(jù)在物理上有多個副本，那么如何保證多個副本之間的數(shù)據(jù)一致呢，這就是強一致需要解決的問題。

3.1?讀寫分離場景

以關(guān)系型數(shù)據(jù)庫MySQL為例，典型的部署方案為一主兩從三節(jié)點方案，主節(jié)點負(fù)責(zé)處理寫操作，兩個從節(jié)處理讀操作，分擔(dān)主庫的壓力，如下圖所示：

此時，如果系統(tǒng)沒有實現(xiàn)強一致，就有可能會遇到執(zhí)行完寫操作后，立刻去讀發(fā)現(xiàn)讀不到或者讀到舊狀態(tài)的尷尬場景，比如操作順序為以下操作：

客戶端首先通過代理向主節(jié)點 Master 進行了寫入操作，此時由于沒有實現(xiàn)強一致，寫操作寫完后立即返回；

緊接著第二步去從節(jié)點 Slave A 執(zhí)行讀操作，此時Master和Slave A之間的同步還未完成，系統(tǒng)處于非強一致的狀態(tài)，所以第二步的讀操作讀取到了舊狀態(tài)。

可以看出，在一主多備讀寫分離的場景下，如果想要保證寫入和讀取操作的準(zhǔn)確無誤，系統(tǒng)實現(xiàn)強一致是非常重要的。

3.2?主備切換場景

主備切換的場景也需要強一致來保證，以目前業(yè)內(nèi)使用最廣泛的內(nèi)存數(shù)據(jù)庫Redis為例，Redis的主從同步如下圖所示：

從上圖可以看出，當(dāng)Redis客戶端向Master服務(wù)器發(fā)送一條命令時，Master服務(wù)器立即回復(fù)客戶端命令的執(zhí)行結(jié)果，并不等待命令同步到從服務(wù)器再回復(fù)，也就是說Redis的主從同步其實是異步的。

由于Master節(jié)點存在宕機的可能，在這種情況下，如果在Master收到命令但是還沒同步到Slave服務(wù)器時發(fā)生了宕機，Redis就會發(fā)生主備切換，然后此時Master服務(wù)器和Slave服務(wù)器的數(shù)據(jù)還沒有同步，就導(dǎo)致了數(shù)據(jù)丟失的情況。可見，開源Redis弱一致性本身的缺陷和不足，而要解決這個問題，必須實現(xiàn)強一致性才能解決。

4.?高斯Redis強一致

由于開源的Redis不具備強一致的特性，導(dǎo)致開源Redis的應(yīng)用也受到了諸多限制，為了解決開源Redis弱一致的問題，GaussDB(for Redis)應(yīng)運而生。GaussDB(for Redis) 是華為云數(shù)據(jù)庫團隊自主研發(fā)的兼容Redis協(xié)議的云原生數(shù)據(jù)庫，徹底解決了開源Redis一致性問題帶來的痛點。

4.1?高斯Redis架構(gòu)

相比于開源Redis，高斯Redis采用存算分離的設(shè)計思想，計算層負(fù)責(zé)計算和協(xié)議等的處理，聚焦服務(wù)。而存儲層負(fù)責(zé)副本管理、擴縮容等處理，聚焦數(shù)據(jù)本身。高斯Redis的優(yōu)勢如下：

數(shù)據(jù)強一致：存儲層使用分布式存儲DFV，輕松實現(xiàn)了3副本強一致；

超可用：N個節(jié)點的集群最多可以掛掉N – 1個節(jié)點；

低成本：數(shù)據(jù)采用磁盤存儲并且進行壓縮，每GB的成本不到開源Redis的十分之一；

秒擴容：計算層僅需修改路由映射，無需數(shù)據(jù)搬遷，實現(xiàn)秒級擴容；

自動備份：高斯Redis可以實現(xiàn)MVCC快照備份和定期自動備份。

4.2?高斯Redis強一致的實現(xiàn)

開源Redis和高斯Redis的架構(gòu)如下圖所示：

開源Redis或者傳統(tǒng)的主從結(jié)構(gòu)如左圖所示，如果在讀寫分離的場景或者主節(jié)點出現(xiàn)宕機發(fā)生主從切換的時候，都會導(dǎo)致數(shù)據(jù)不一致的情況。

高斯Redis采用存算分離的架構(gòu)，如右圖所示，在存儲層DFV的副本管理中采用分布式共識算法實現(xiàn)了3副本的強一致。計算層調(diào)用存儲層的接口時，如果返回OK，那么即表示存儲層已經(jīng)實現(xiàn)副本強一致的復(fù)制。

5. 結(jié)語

我們在做架構(gòu)設(shè)計的時候，其實很多場景都隱藏著強一致的訴求。如朋友圈這類應(yīng)用，如果沒有實現(xiàn)強一致，朋友圈的評論很容易亂序。再比如限流器的場景，如果沒有強一致的保證，也極容易造成數(shù)據(jù)庫的崩潰。因此，必須在系統(tǒng)設(shè)計之初就認(rèn)識到強一致的重要性，才能設(shè)計出更加穩(wěn)定和可靠的系統(tǒng)。

6. 附錄

更多技術(shù)文章，關(guān)注高斯Redis官方博客：https://bbs.huaweicloud.com/community/usersnew/id_1614151726110813

擴展閱讀：

《華為云企業(yè)級Redis揭秘第七期：高斯Redis與強一致》

https://bbs.huaweicloud.com/blogs/256888

2.《華為云PB級數(shù)據(jù)庫GaussDB(for Redis)揭秘第一期：Redis與存算分離》

https://bbs.huaweicloud.com/blogs/245622

3.《Strong consistency models》

https://aphyr.com/posts/313-strong-consistency-models

4.《Redis數(shù)據(jù)一致性分析》

http://baobing.github.io/2017/12/23/Redis/Redis數(shù)據(jù)一致性分析

5.《如何解決Redis 主從數(shù)據(jù)不一致問題》

https://segmentfault.com/a/1190000013144617

6.《Don't Settle for Eventual Consistency》

https://queue.acm.org/detail.cfm?id=2610533

7.《微服務(wù)的災(zāi)難-最終一致》

https://xargin.com/disaster-of-microservice-evconst/

8.《ETCD應(yīng)用場景》

https://tonydeng.github.io/2015/10/19/etcd-application-scenarios/

MySQL Redis 云數(shù)據(jù)庫 GaussDB(for Redis) 數(shù)據(jù)庫 緩存

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。