NoSQL數(shù)據(jù)庫(kù)中怎么實(shí)現(xiàn)主主備份

這篇文章將為大家詳細(xì)講解有關(guān)NoSQL數(shù)據(jù)庫(kù)中怎么實(shí)現(xiàn)主主備份，文章內(nèi)容質(zhì)量較高，因此小編分享給大家做個(gè)參考，希望大家閱讀完這篇文章后對(duì)相關(guān)知識(shí)有一定的了解。

Tarantool  DBMS的高性能應(yīng)該很多人都聽(tīng)說(shuō)過(guò)，包括其豐富的工具套件和某些特定功能。比如，它擁有一個(gè)非常強(qiáng)大的on-disk存儲(chǔ)引擎Vinyl，并且知道怎樣處理JSON文檔。然而，大部分文章往往忽略了一個(gè)關(guān)鍵點(diǎn)：通常，Tarantool僅僅被視為存儲(chǔ)器，而實(shí)際上其***特點(diǎn)是能夠在存儲(chǔ)器內(nèi)部寫(xiě)代碼，從而高效處理數(shù)據(jù)。如果你想知道我和igorcoding是怎樣在Tarantool內(nèi)部建立一個(gè)系統(tǒng)的，請(qǐng)繼續(xù)往下看。

如果你用過(guò)Mail.Ru電子郵件服務(wù)，你應(yīng)該知道它可以從其他賬號(hào)收集郵件。如果支持OAuth協(xié)議，那么在收集其他賬號(hào)的郵件時(shí)，我們就不需要讓用戶(hù)提供第三方服務(wù)憑證了，而是用OAuth令牌來(lái)代替。此外，Mail.Ru  Group有很多項(xiàng)目要求通過(guò)第三方服務(wù)授權(quán)，并且需要用戶(hù)的OAuth令牌才能處理某些應(yīng)用。因此，我們決定建立一個(gè)存儲(chǔ)和更新令牌的服務(wù)。

我猜大家都知道OAuth令牌是什么樣的，閉上眼睛回憶一下，OAuth結(jié)構(gòu)由以下3-4個(gè)字段組成：

{  “token_type” : “bearer”,  “access_token” : “XXXXXX”,  “refresh_token” : “YYYYYY”,  “expires_in” : 3600  }

• 訪問(wèn)令牌(access_token)——允許你執(zhí)行動(dòng)作、獲取用戶(hù)數(shù)據(jù)、下載用戶(hù)的好友列表等等;

• 更新令牌(refresh_token)——讓你重新獲取新的access_token，不限次數(shù);

• 過(guò)期時(shí)間(expires_in)——令牌到期時(shí)間戳或任何其他預(yù)定義時(shí)間,如果你的access_token到期了，你就不能繼續(xù)訪問(wèn)所需的資源。

現(xiàn)在我們看一下服務(wù)的簡(jiǎn)單框架。設(shè)想有一些前端可以在我們的服務(wù)上寫(xiě)入和讀出令牌，還有一個(gè)獨(dú)立的更新器，一旦令牌到期，就可以通過(guò)更新器從OAuth服務(wù)提供商獲取新的訪問(wèn)令牌。

如上圖所示，數(shù)據(jù)庫(kù)的結(jié)構(gòu)也十分簡(jiǎn)單，由兩個(gè)數(shù)據(jù)庫(kù)節(jié)點(diǎn)(主和從)組成，為了說(shuō)明兩個(gè)數(shù)據(jù)庫(kù)節(jié)點(diǎn)分別位于兩個(gè)數(shù)據(jù)中心，二者之間由一條垂直的虛線隔開(kāi)，其中一個(gè)數(shù)據(jù)中心包含主數(shù)據(jù)庫(kù)節(jié)點(diǎn)及其前端和更新器，另一個(gè)數(shù)據(jù)中心包含從數(shù)據(jù)庫(kù)節(jié)點(diǎn)及其前端，以及訪問(wèn)主數(shù)據(jù)庫(kù)節(jié)點(diǎn)的更新器。

面臨的困難

我們面臨的主要問(wèn)題在于令牌的使用期(一個(gè)小時(shí))。詳細(xì)了解這個(gè)項(xiàng)目之后，也許有人會(huì)問(wèn)“在一小時(shí)內(nèi)更新1000萬(wàn)條記錄，這真的是高負(fù)載服務(wù)嗎?如果我們用一個(gè)數(shù)除一下，結(jié)果大約是3000rps”。然而，如果因?yàn)閿?shù)據(jù)庫(kù)維護(hù)或故障，甚至服務(wù)器故障(一切皆有可能)導(dǎo)致一部分記錄沒(méi)有得到更新，那事情將會(huì)變得比較麻煩。比如，如果我們的服務(wù)(主數(shù)據(jù)庫(kù))因?yàn)槟承┰虺掷m(xù)中斷15分鐘，就會(huì)導(dǎo)致25%的服務(wù)中斷(四分之一的令牌變成無(wú)效，不能再繼續(xù)使用);如果服務(wù)中斷30分鐘，將會(huì)有一半的數(shù)據(jù)不能得到更新;如果中斷1小時(shí)，那么所有的令牌都將失效。假設(shè)數(shù)據(jù)庫(kù)癱瘓一個(gè)小時(shí)，我們重啟系統(tǒng)，然后整個(gè)1000萬(wàn)條令牌都需要進(jìn)行快速更新。這算不算高負(fù)載服務(wù)呢?

一開(kāi)始一切都還進(jìn)展地比較順利，但是兩年后，我們進(jìn)行了邏輯擴(kuò)展，增加了幾個(gè)指標(biāo)，并且開(kāi)始執(zhí)行一些輔助邏輯…….總之，Tarantool耗盡了CPU資源。盡管所有資源都是遞耗資源，但這樣的結(jié)果確實(shí)讓我們大吃一驚。

幸運(yùn)的是，系統(tǒng)管理員幫我們安裝了當(dāng)時(shí)庫(kù)存中內(nèi)存***的CPU，解決了我們隨后6個(gè)月的CPU需求。但這只是權(quán)宜之計(jì)，我們必須想出一個(gè)解決辦法。當(dāng)時(shí)，我們學(xué)習(xí)了一個(gè)新版的Tarantool(我們的系統(tǒng)是用Tarantool  1.5寫(xiě)的，這個(gè)版本除了在Mail.Ru Group，其他地方基本沒(méi)用過(guò))。Tarantool  1.6大力提倡主主備份，于是我們想：為什么不在連接主主備份的三個(gè)數(shù)據(jù)中心分別建立一個(gè)數(shù)據(jù)庫(kù)備份呢?這聽(tīng)起來(lái)是個(gè)不錯(cuò)的計(jì)劃。

三個(gè)主機(jī)、三個(gè)數(shù)據(jù)中心和三個(gè)更新器，都分別連接自己的主數(shù)據(jù)庫(kù)。即使一個(gè)或者兩個(gè)主機(jī)癱瘓了，系統(tǒng)仍然照常運(yùn)行，對(duì)吧?那么這個(gè)方案的缺點(diǎn)是什么呢?缺點(diǎn)就是，我們將一個(gè)OAuth服務(wù)提供商的請(qǐng)求數(shù)量有效地增加到了三倍，也就是說(shuō)，有多少個(gè)副本，我們就要更新幾乎相同數(shù)量的令牌，這樣不行。最直接的解決辦法就是，想辦法讓各個(gè)節(jié)點(diǎn)自己決定誰(shuí)是leader，那樣就只需要更新存儲(chǔ)在leader上的節(jié)點(diǎn)了。

選擇leader節(jié)點(diǎn)

選擇leader節(jié)點(diǎn)的算法有很多，其中有一個(gè)算法叫Paxos，相當(dāng)復(fù)雜，不知道怎樣簡(jiǎn)化，于是我們決定用Raft代替。Raft是一個(gè)非常通俗易懂的算法，誰(shuí)能通信就選誰(shuí)做leader，一旦通信連接失敗或者其他因素，就重新選leader。具體實(shí)施辦法如下：

Tarantool外部既沒(méi)有Raft也沒(méi)有Paxos，但是我們可以使用net.box內(nèi)置模式，讓所有節(jié)點(diǎn)連接成一個(gè)網(wǎng)狀網(wǎng)(即每一個(gè)節(jié)點(diǎn)連接剩下所有節(jié)點(diǎn))，然后直接在這些連接上用Raft算法選出leader節(jié)點(diǎn)。***，所有節(jié)點(diǎn)要么成為leader節(jié)點(diǎn)，要么成為follower節(jié)點(diǎn)，或者二者都不是。

如果你覺(jué)得Raft算法實(shí)施起來(lái)有困難，下面的Lua代碼可以幫到你：

local r = self.pool.call(self.FUNC.request_vote,                      self.term, self.uuid) self._vote_count = self:count_votes(r)  if self._vote_count > self._nodes_count / 2 then     log.info(“[raft-srv] node %d won elections”, self.id)     self:_set_state(self.S.LEADER)     self:_set_leader({ id=self.id, uuid=self.uuid })     self._vote_count = 0     self:stop_election_timer()     self:start_heartbeater() else     log.info(“[raft-srv] node %d lost elections”, self.id)     self:_set_state(self.S.IDLE)     self:_set_leader(msgpack.NULL)     self._vote_count = 0     self:start_election_timer() end

現(xiàn)在我們給遠(yuǎn)程服務(wù)器發(fā)送請(qǐng)求(其他Tarantool副本)并計(jì)算來(lái)自每一個(gè)節(jié)點(diǎn)的票數(shù)，如果我們有一個(gè)quorum，我們就選定了一個(gè)leader，然后發(fā)送heartbeats，告訴其他節(jié)點(diǎn)我們還活著。如果我們?cè)谶x舉中失敗了，我們可以發(fā)起另一場(chǎng)選舉，一段時(shí)間之后，我們又可以投票或被選為leader。

只要我們有一個(gè)quorum，選中一個(gè)leader，我們就可以將更新器指派給所有節(jié)點(diǎn)，但是只準(zhǔn)它們?yōu)閘eader服務(wù)。

這樣我們就規(guī)范了流量，由于任務(wù)是由單一的節(jié)點(diǎn)派出，因此每一個(gè)更新器獲得大約三分之一的任務(wù)，有了這樣的設(shè)置，我們可以失去任何一臺(tái)主機(jī)，因?yàn)槿绻撑_(tái)主機(jī)出故障了，我們可以發(fā)起另一個(gè)選舉，更新器也可以切換到另一個(gè)節(jié)點(diǎn)。然而，和其他分布式系統(tǒng)一樣，有好幾個(gè)問(wèn)題與quorum有關(guān)。

“廢棄”節(jié)點(diǎn)

如果各個(gè)數(shù)據(jù)中心之間失去聯(lián)系了，那么我們需要有一些適當(dāng)?shù)臋C(jī)制去維持整個(gè)系統(tǒng)正常運(yùn)轉(zhuǎn)，還需要有一套機(jī)制能恢復(fù)系統(tǒng)的完整性。Raft成功地做到了這兩點(diǎn)：

假設(shè)Dataline數(shù)據(jù)中心掉線了，那么該位置的節(jié)點(diǎn)就變成了“廢棄”節(jié)點(diǎn)，也就是說(shuō)該節(jié)點(diǎn)就看不到其他節(jié)點(diǎn)了，集群中的其他節(jié)點(diǎn)可以看到這個(gè)節(jié)點(diǎn)丟失了，于是引發(fā)了另一個(gè)選舉，然后新的集群節(jié)點(diǎn)(即上級(jí)節(jié)點(diǎn))被選為leader，整個(gè)系統(tǒng)仍然保持運(yùn)轉(zhuǎn)，因?yàn)楦鱾€(gè)節(jié)點(diǎn)之間仍然保持一致性(大半部分節(jié)點(diǎn)仍然互相可見(jiàn))。

那么問(wèn)題來(lái)了，與丟失的數(shù)據(jù)中心有關(guān)的更新器怎么樣了呢?Raft說(shuō)明書(shū)沒(méi)有給這樣的節(jié)點(diǎn)一個(gè)單獨(dú)的名字，通常，沒(méi)有quorum的節(jié)點(diǎn)和不能與leader聯(lián)系的節(jié)點(diǎn)會(huì)被閑置下來(lái)。然而，它可以自己建立網(wǎng)絡(luò)連接然后更新令牌，一般來(lái)說(shuō)，令牌都是在連接模式時(shí)更新，但是，也許用一個(gè)連接“廢棄”節(jié)點(diǎn)的更新器也可以更新令牌。一開(kāi)始我們并不確定這樣做有意義，這樣不會(huì)導(dǎo)致冗余更新嗎?

這個(gè)問(wèn)題我們需要在實(shí)施系統(tǒng)的過(guò)程中搞清楚。我們的***個(gè)想法是不更新：我們有一致性、有quorum，丟失任何一個(gè)成員，我們都不應(yīng)該更新。但是后來(lái)我們有了另一個(gè)想法，我們看一下Tarantool中的主主備份，假設(shè)有兩個(gè)主節(jié)點(diǎn)和一個(gè)變量(key)X=1，我們同時(shí)在每一個(gè)節(jié)點(diǎn)上給這個(gè)變量賦一個(gè)新值，一個(gè)賦值為2，另一個(gè)賦值為3，然后，兩個(gè)節(jié)點(diǎn)互相交換備份日志(就是X變量的值)。在一致性上，這樣實(shí)施主主備份是很糟糕的(無(wú)意冒犯Tarantool開(kāi)發(fā)者)。

如果我們需要嚴(yán)格的一致性，這樣是行不通的。然而，回憶一下我們的OAuth令牌是由以下兩個(gè)重要因素組成：

• 更新令牌，本質(zhì)上***有效;

• 訪問(wèn)令牌，有效期為一個(gè)小時(shí);

我們的更新器有一個(gè)refresh函數(shù)，可以從一個(gè)更新令牌獲取任意數(shù)量的訪問(wèn)令牌，一旦發(fā)布，它們都將保持一個(gè)小時(shí)內(nèi)有效。

我們考慮一下以下場(chǎng)景：兩個(gè)follower節(jié)點(diǎn)正在和一個(gè)leader節(jié)點(diǎn)交互，它們更新自己的令牌，接收***個(gè)訪問(wèn)令牌，這個(gè)訪問(wèn)令牌被復(fù)制，于是現(xiàn)在每一個(gè)節(jié)點(diǎn)都有這個(gè)訪問(wèn)令牌，然后，連接中斷了，所以，其中一個(gè)follower節(jié)點(diǎn)變成了“廢棄”節(jié)點(diǎn)，它沒(méi)有quorum，既看不到leader也看不到其他follower，然而，我們?cè)试S我們的更新器去更新位于“廢棄”節(jié)點(diǎn)上的令牌，如果“廢棄”節(jié)點(diǎn)沒(méi)有連接網(wǎng)絡(luò)，那么整個(gè)方案都將停止運(yùn)行。盡管如此，如果發(fā)生簡(jiǎn)單的網(wǎng)絡(luò)拆分，更新器還是可以維持正常運(yùn)行。

一旦網(wǎng)絡(luò)拆分結(jié)束，“廢棄”節(jié)點(diǎn)重新加入集群，就會(huì)引發(fā)另一場(chǎng)選舉或者數(shù)據(jù)交換。注意，第二和第三個(gè)令牌一樣，也是“好的”。

原始的集群成員恢復(fù)之后，下一次更新將只在一個(gè)節(jié)點(diǎn)上發(fā)生，然后備份。換句話來(lái)說(shuō)，當(dāng)集群拆分之后，被拆分的各個(gè)部分各自獨(dú)立更新，但是一旦重新整合，數(shù)據(jù)一致性也因此恢復(fù)。通常，需要N/2+1個(gè)活動(dòng)節(jié)點(diǎn)(對(duì)于一個(gè)3節(jié)點(diǎn)集群，就是需要2個(gè)活動(dòng)節(jié)點(diǎn))去保持集群正常運(yùn)轉(zhuǎn)。盡管如此，對(duì)我們而言，即使只有1個(gè)活動(dòng)節(jié)點(diǎn)也足夠了，它會(huì)發(fā)送盡可能多的外部請(qǐng)求。

重申一下，我們已經(jīng)討論了請(qǐng)求數(shù)量逐漸增加的情況，在網(wǎng)絡(luò)拆分或節(jié)點(diǎn)中斷時(shí)期，我們能夠提供一個(gè)單一的活動(dòng)節(jié)點(diǎn)，我們會(huì)像平時(shí)一樣更新這個(gè)節(jié)點(diǎn)，如果出現(xiàn)絕對(duì)拆分(即當(dāng)一個(gè)集群被分成***數(shù)量的節(jié)點(diǎn)，每一個(gè)節(jié)點(diǎn)有一個(gè)網(wǎng)絡(luò)連接)，如上所述，OAuth服務(wù)提供商的請(qǐng)求數(shù)量將提升至三倍。但是，由于這個(gè)事件發(fā)生的時(shí)間相對(duì)短暫，所以情況不是太糟，我們可不希望一直工作在拆分模式。通常情況下，系統(tǒng)處于有quorum和網(wǎng)絡(luò)連接，并且所有節(jié)點(diǎn)都啟動(dòng)運(yùn)行的狀態(tài)。

分片

還有一個(gè)問(wèn)題沒(méi)有解決：我們已經(jīng)達(dá)到了CPU上限，最直接的解決辦法就是分片。

假設(shè)我們有兩個(gè)數(shù)據(jù)庫(kù)分片，每一個(gè)都有備份，有一個(gè)這樣的函數(shù)，給定一些key值，就可以計(jì)算出哪一個(gè)分片上有所需要的數(shù)據(jù)。如果我們通過(guò)電子郵件分片，一部分地址存儲(chǔ)在一個(gè)分片上，另一部分地址存儲(chǔ)在另一個(gè)分片上，我們很清楚我們的數(shù)據(jù)在哪里。

有兩種方法可以分片。一種是客戶(hù)端分片，我們選擇一個(gè)返回分片數(shù)量的連續(xù)的分片函數(shù)，比如CRC32、Guava或Sumbur，這個(gè)函數(shù)在所有客戶(hù)端的實(shí)現(xiàn)方式都一樣。這種方法的一個(gè)明顯優(yōu)勢(shì)在于數(shù)據(jù)庫(kù)對(duì)分片一無(wú)所知，你的數(shù)據(jù)庫(kù)正常運(yùn)轉(zhuǎn)，然后分片就發(fā)生了。

然而，這種方法也存在一個(gè)很?chē)?yán)重的缺陷。一開(kāi)始，客戶(hù)端非常繁忙。如果你想要一個(gè)新的分片，你需要把分片邏輯加進(jìn)客戶(hù)端，這里的***的問(wèn)題是，可能一些客戶(hù)端在使用這種模式，而另一些客戶(hù)端卻在使用另一種完全不同的模式，而數(shù)據(jù)庫(kù)本身卻不知道有兩種不同的分片模式。

我們選擇另一種方法—數(shù)據(jù)庫(kù)內(nèi)部分片，這種情況下，數(shù)據(jù)庫(kù)代碼變得更加復(fù)雜，但是為了折中我們可以使用簡(jiǎn)單的客戶(hù)端，每一個(gè)連接數(shù)據(jù)庫(kù)的客戶(hù)端被路由到任意節(jié)點(diǎn)，由一個(gè)特殊函數(shù)計(jì)算出哪一個(gè)節(jié)點(diǎn)應(yīng)該被連接、哪一個(gè)節(jié)點(diǎn)應(yīng)該被控制。前面提到，由于數(shù)據(jù)庫(kù)變得更加復(fù)雜，因此為了折中，客戶(hù)端就變得更加簡(jiǎn)單了，但是這樣的話，數(shù)據(jù)庫(kù)就要對(duì)其數(shù)據(jù)全權(quán)負(fù)責(zé)。此外，最困難的事就是重新分片，如果你有一大堆客戶(hù)端無(wú)法更新，相比之下，如果數(shù)據(jù)庫(kù)負(fù)責(zé)管理自己的數(shù)據(jù)，那重新分片就會(huì)變得非常簡(jiǎn)單。

具體怎樣實(shí)施呢?

六邊形代表Tarantool實(shí)體，有3個(gè)節(jié)點(diǎn)組成分片1，另一個(gè)3節(jié)點(diǎn)集群作為分片2，如果我們將所有節(jié)點(diǎn)互相連接，結(jié)果會(huì)怎樣呢?根據(jù)Raft，我們可以知道每一個(gè)集群的狀態(tài)，誰(shuí)是leader服務(wù)器誰(shuí)是follower服務(wù)器也一目了然，由于是集群內(nèi)連接，我們還可以知道其他分片(例如它的leader分片或者follower分片)的狀態(tài)?？偟膩?lái)說(shuō)，如果訪問(wèn)***個(gè)分片的用戶(hù)發(fā)現(xiàn)這并不是他需要的分片，我們很清楚地知道應(yīng)該指導(dǎo)他往哪里走。

我們來(lái)看一些簡(jiǎn)單的例子。

假設(shè)用戶(hù)向駐留在***個(gè)分片上的key發(fā)出請(qǐng)求，該請(qǐng)求被***個(gè)分片上的某一個(gè)節(jié)點(diǎn)接收，這個(gè)節(jié)點(diǎn)知道誰(shuí)是leader，于是將請(qǐng)求重新路由到分片leader，反過(guò)來(lái)，分片leader對(duì)這個(gè)key進(jìn)行讀或?qū)?，并且將結(jié)果反饋給用戶(hù)。

第二個(gè)場(chǎng)景：用戶(hù)的請(qǐng)求到達(dá)***個(gè)分片中的相同節(jié)點(diǎn)，但是被請(qǐng)求的key卻在第二個(gè)分片上，這種情況也可以用類(lèi)似的方法處理，***個(gè)分片知道第二個(gè)分片上誰(shuí)是leader，然后把請(qǐng)求送到第二個(gè)分片的leader進(jìn)行轉(zhuǎn)發(fā)和處理，再將結(jié)果返回給用戶(hù)。

這個(gè)方案十分簡(jiǎn)單，但也存在一定的缺陷，其中***的問(wèn)題就是連接數(shù)，在二分片的例子中，每一個(gè)節(jié)點(diǎn)連接到其他剩下的節(jié)點(diǎn)，連接數(shù)是6*5=30，如果再加一個(gè)3節(jié)點(diǎn)分片，那么連接數(shù)就增加到72，這會(huì)不會(huì)有點(diǎn)多呢?

我們?cè)撊绾谓鉀Q這個(gè)問(wèn)題呢?我們只需要增加一些Tarantool實(shí)例，我們叫它代理，而不叫分片或數(shù)據(jù)庫(kù)，用代理去解決所有的分片問(wèn)題：包括計(jì)算key值和定位分片領(lǐng)導(dǎo)。另一方面，Raft集群保持自包含，只在分片內(nèi)部工作。當(dāng)用戶(hù)訪問(wèn)代理時(shí)，代理計(jì)算出所需要的分片，如果需要的是leader，就對(duì)用戶(hù)作相應(yīng)的重定向，如果不是leader，就將用戶(hù)重定向至分片內(nèi)的任意節(jié)點(diǎn)。

由此產(chǎn)生的復(fù)雜性是線性的，取決于節(jié)點(diǎn)數(shù)量。現(xiàn)在一共3個(gè)節(jié)點(diǎn)，每個(gè)節(jié)點(diǎn)3個(gè)分片，連接數(shù)少了幾倍。

代理方案的設(shè)計(jì)考慮到了進(jìn)一步規(guī)模擴(kuò)展(當(dāng)分片數(shù)量大于2時(shí))，當(dāng)只有2個(gè)分片時(shí)，連接數(shù)不變，但是當(dāng)分片數(shù)量增加時(shí)，連接數(shù)會(huì)劇減。分片列表存儲(chǔ)在Lua配置文件中，所以，如果想要獲取新列表，我們只需要重載代碼就好了。

綜上所述，首先，我們進(jìn)行主主備份，應(yīng)用Raft算法，然后加入分片和代理，***我們得到的是一個(gè)單塊，一個(gè)集群，所以說(shuō)，目前這個(gè)方案看上去是比較簡(jiǎn)單的。

剩下的就是只讀或只寫(xiě)令牌的的前端了，我們有更新器可以更新令牌，獲得更新令牌后把它傳到OAuth服務(wù)提供商，然后寫(xiě)一個(gè)新的訪問(wèn)令牌。

前面說(shuō)過(guò)我們的一些輔助邏輯耗盡了CPU資源，現(xiàn)在我們將這些輔助資源移到另一個(gè)集群上。

輔助邏輯主要和地址簿有關(guān)，給定一個(gè)用戶(hù)令牌，就會(huì)有一個(gè)對(duì)應(yīng)的地址簿，地址簿上的數(shù)據(jù)量和令牌一樣，為了不耗盡一臺(tái)機(jī)器上的CPU資源，我們顯然需要一個(gè)與副本相同的集群，只需要加一堆更新地址簿的更新器就可以了(這個(gè)任務(wù)比較少見(jiàn)，因此地址簿不會(huì)和令牌一起更新)。

***，通過(guò)整合這兩個(gè)集群，我們得到一個(gè)相對(duì)簡(jiǎn)單的完整結(jié)構(gòu)：

令牌更新隊(duì)列

為什么我們本可以使用標(biāo)準(zhǔn)隊(duì)列卻還要用自己的隊(duì)列呢?這和我們的令牌更新模型有關(guān)。令牌一旦發(fā)布，有效期就是一個(gè)小時(shí)，當(dāng)令牌快要到期時(shí)，需要進(jìn)行更新，而令牌更新必須在某個(gè)特定的時(shí)間點(diǎn)之前完成。

假設(shè)系統(tǒng)中斷了，但是我們有一堆已到期的令牌，而在我們更新這些令牌的同時(shí)，又有其他令牌陸續(xù)到期，雖然我們***肯定能全部更新完，但是如果我們先更新那些即將到期的(60秒內(nèi))，再用剩下的資源去更新已經(jīng)到期的，是不是會(huì)更合理一些?(優(yōu)先級(jí)別***的是還有4-5分鐘才到期的令牌)

用第三方軟件來(lái)實(shí)現(xiàn)這個(gè)邏輯并不是件容易的事，然而，對(duì)于Tarantool來(lái)說(shuō)卻不費(fèi)吹灰之力?？匆粋€(gè)簡(jiǎn)單的方案：在Tarantool中有一個(gè)存儲(chǔ)數(shù)據(jù)的元組，這個(gè)元組的一些ID設(shè)置了基礎(chǔ)key值，為了得到我們需要的隊(duì)列，我們只需要添加兩個(gè)字段：status(隊(duì)列令牌狀態(tài))和time(到期時(shí)間或其他預(yù)定義時(shí)間)。

現(xiàn)在我們考慮一下隊(duì)列的兩個(gè)主要功能—put和take。put就是寫(xiě)入新數(shù)據(jù)。給定一些負(fù)載，put時(shí)自己設(shè)置好status和time，然后寫(xiě)數(shù)據(jù)，這就是建立一個(gè)新的元組。

至于take，是指建立一個(gè)基于索引的迭代器，挑出那些等待解決的任務(wù)(處于就緒狀態(tài)的任務(wù))，然后核查一下是不是該接收這些任務(wù)了，或者這些任務(wù)是否已經(jīng)到期了。如果沒(méi)有任務(wù)，take就切換到wait模式。除了內(nèi)置Lua，Tarantool還有一些所謂的通道，這些通道本質(zhì)上是互聯(lián)光纖同步原語(yǔ)。任何光纖都可以建立一個(gè)通道然后說(shuō)“我在這等著”，剩下的其他光纖可以喚醒這個(gè)通道然后給它發(fā)送信息。

等待中的函數(shù)(等待發(fā)布任務(wù)、等待指定時(shí)間或其他)建立一個(gè)通道，給通道貼上適當(dāng)?shù)臉?biāo)簽，將通道放置在某個(gè)地方，然后進(jìn)行監(jiān)聽(tīng)。如果我們收到一個(gè)緊急的更新令牌，put會(huì)給通道發(fā)出通知，然后take接收更新任務(wù)。

Tarantool有一個(gè)特殊的功能：如果一個(gè)令牌被意外發(fā)布，或者一個(gè)更新令牌被take接收，或者只是出現(xiàn)接收任務(wù)的現(xiàn)象，以上三種情況Tarantool都可以跟蹤到客戶(hù)端中斷。我們將每一個(gè)連接與指定給該連接的任務(wù)聯(lián)系起來(lái)，并將這些映射關(guān)系保持在會(huì)話保存中。假設(shè)由于網(wǎng)絡(luò)中斷導(dǎo)致更新過(guò)程失敗，而且我們不知道這個(gè)令牌是否會(huì)被更新并被寫(xiě)回到數(shù)據(jù)庫(kù)。于是，客戶(hù)端發(fā)生中斷了，搜索與失敗過(guò)程相關(guān)的所有任務(wù)的會(huì)話保存，然后自動(dòng)將它們釋放。隨后，任意已發(fā)布的任務(wù)都可以用同一個(gè)通道給另一個(gè)put發(fā)送信息，該put會(huì)快速接收和執(zhí)行任務(wù)。

實(shí)際上，具體實(shí)施方案并不需要太多代碼：

function put(data)     local t = box.space.queue:auto_increment({         &lsquo;r&rsquo;, -- [[ status ]]         util.time(), -- [[ time ]]         data -- [[ any payload ]]     })      return t end  function take(timeout)     local start_time = util.time()     local q_ind = box.space.tokens.index.queue     local _,t      while true do         local it = util.iter(q_ind, {&lsquo;r&rsquo;}, {iterator = box.index.GE})         _,t = it()         if t and t[F.tokens.status] ~= &lsquo;t&rsquo; then             break         end          local left = (start_time + timeout) &mdash; util.time()         if left <= 0 then return end         t = q:wait(left)         if t then break end     end     t = q:taken(t)     return t end  function queue:taken(task)     local sid = box.session.id()     if self._consumers[sid] == nil then         self._consumers[sid] = {}     end     local k = task[self.f_id]     local t = self:set_status(k, &lsquo;t&rsquo;)      self._consumers[sid][k] = {util.time(), box.session.peer(sid), t}     self._taken[k] = sid     return t end  function on_disconnect()     local sid = box.session.id     local now = util.time()      if self._consumers[sid] then         local consumers = self._consumers[sid]         for k, rec in pairs(consumers) do             time, peer, task = unpack(rec)              local v = box.space[self.space].index[self.index_primary]:get({k})             if v and v[self.f_status] == &lsquo;t&rsquo; then                 v = self:release(v[self.f_id])             end         end         self._consumers[sid] = nil     end end

Put只是接收用戶(hù)想要插入隊(duì)列的所有數(shù)據(jù)，并將其寫(xiě)入某個(gè)空間，如果是一個(gè)簡(jiǎn)單的索引式FIFO隊(duì)列，設(shè)置好狀態(tài)和當(dāng)前時(shí)間，然后返回該任務(wù)。

接下來(lái)要和take有點(diǎn)關(guān)系了，但仍然比較簡(jiǎn)單。我們建立一個(gè)迭代器，等待接收新任務(wù)。Taken函數(shù)只需要將任務(wù)標(biāo)記成“已接收”，但有一點(diǎn)很重要，taken函數(shù)還能記住哪個(gè)任務(wù)是由哪個(gè)進(jìn)程接收的。On_disconnect函數(shù)可以發(fā)布某個(gè)特定連接，或者發(fā)布由某個(gè)特定用戶(hù)接收的所有任務(wù)。

是否有可選方案 ?

當(dāng)然有。我們本可以使用任意數(shù)據(jù)庫(kù)，但是，不管我們選用什么數(shù)據(jù)庫(kù)，我們都要建立一個(gè)隊(duì)列用來(lái)處理外部系統(tǒng)、處理更新等等問(wèn)題。我們不能僅僅按需更新令牌，因?yàn)槟菢訒?huì)產(chǎn)生不可預(yù)估的工作量，不管怎樣，我們需要保持我們的系統(tǒng)充滿(mǎn)活力，但是那樣，我們就要將延期的任務(wù)也插入隊(duì)列，并且保證數(shù)據(jù)庫(kù)和隊(duì)列之間的一致性，我們還要被迫使用一個(gè)quorum的容錯(cuò)隊(duì)列。此外，如果我們把數(shù)據(jù)同時(shí)放在RAM和一個(gè)(考慮到工作量)可能要放入內(nèi)存的隊(duì)列中，那么我們就要消耗更多資源。

在我們的方案中，數(shù)據(jù)庫(kù)存儲(chǔ)令牌，隊(duì)列邏輯只需要占用7個(gè)字節(jié)(每個(gè)元組只需要7個(gè)額外的字節(jié)，就可以搞定隊(duì)列邏輯!)，如果使用其他的隊(duì)列形式，需要占用的空間就多得多了，大概是內(nèi)存容量的兩倍。

關(guān)于NoSQL數(shù)據(jù)庫(kù)中怎么實(shí)現(xiàn)主主備份就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，可以學(xué)到更多知識(shí)。如果覺(jué)得文章不錯(cuò)，可以把它分享出去讓更多的人看到。