華為云企業(yè)級Redis揭秘第15期：Redis為什么需要強(qiáng)一致？

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

1.不一致帶來的困擾

1.1 秒殺變秒崩

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

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

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

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

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

1.2 難以維護(hù)的MySQL組件

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

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

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

2.什么是強(qiáng)一致

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

2.1 事務(wù)一致性

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

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

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

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

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

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

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

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

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

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

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

（2）操作視角

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

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

順序一致性：一致性強(qiáng)度弱于線性一致性

因果一致性：一致性強(qiáng)度弱于順序一致性

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

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

3.強(qiáng)一致的剛需場景

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

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

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

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

3.1 讀寫分離場景

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

此時(shí)，如果系統(tǒng)沒有實(shí)現(xiàn)強(qiáng)一致，就有可能會遇到執(zhí)行完寫操作后，立刻去讀，然后發(fā)現(xiàn)讀不到或者讀到舊狀態(tài)的尷尬場景，比如操作順序?yàn)橐韵虏僮鳎?/p>

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

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

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

3.2 主備切換場景

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

復(fù)客戶端命令的執(zhí)行結(jié)果，并不等待命令同步到從服務(wù)器再回復(fù)，也就是說Redis的主從同步其實(shí)是異步的。

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

4.高斯Redis強(qiáng)一致

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

4.1 高斯Redis架構(gòu)

高斯Redis的整體架構(gòu)如下：

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

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

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

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

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

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

4.2 高斯Redis強(qiáng)一致的實(shí)現(xiàn)

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

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

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

5.結(jié)語

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

6.附錄

杭州/西安/深圳簡歷投遞：yuwenlong4@huawei.com

更多產(chǎn)品信息：GaussDB(for Redis)官網(wǎng)

更多技術(shù)文章：GaussDB(for Redis)博客

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)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。