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

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

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

　　訪問令牌（access_token）——允許你執(zhí)行動作、獲取用戶數(shù)據(jù)、下載用戶的好友列表等等；

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

　　過期時間（expires_in）——令牌到期時間戳或任何其他預(yù)定義時間，如果你的access_token到期了，你就不能繼續(xù)訪問所需的資源。

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

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

　　面臨的困難

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

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

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