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

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

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

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

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

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

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

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

　　面臨的困難

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

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

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

相關電子資料下載

• 一文詳解RedisJSON和其他框架的對比 130
• 針對Ampere Altra處理器的MongoDB優化指南 143
• Redis的LRU與LFU算法實現 203
• 基于圖數據庫的配電網供電范圍分析應用研究 350
• Redis數據同步解決方案—NineData 301
• NoSQL數據庫的四種類型 1763
• 記錄關系數據庫中的半結構化數據 395
• 什么是 NoSQL數據庫？為什么要使用NoSQL數據庫？ 573
• 數據庫技術與數據庫學習筆記 384
• Redis緩存的異常原因及其處理辦法分析 311