騰訊重磅開源DCache，分散式NoSQL儲存系統

來自：開源中國（ID：oschina2013）

當你在電商平臺秒殺商品或者在社交網路刷熱門話題的時候，可以很明顯感受到當前網路資料流量的恐怖，幾十萬商品剛開搶，一秒都不到就售罄；哪個大明星出軌的訊息一齣現，瞬間閱讀與轉發次數可以達到上億。作為終端使用者的我們可能會思考，服務系統是怎麼在這樣嚴峻的流量環境中存活下來的。

其實，服務系統的架構中有許多巧妙的設計來應對這樣的問題，而在這其中，通常系統都會架設快取系統，用以緩解海量訪問請求與資料帶來的衝擊，實現高效能訪問需求。

同時，隨著微服務與雲等技術的發展，分散式架構的需求變得越來越普遍，再加上今天 Web 上的資料型別已經不再單一，而且資料量也呈爆髮式增長，傳統的結構化儲存方案已經跟不上腳步，對資料庫的 SQL 操作不再滿足要求，於是 NoSQL 出現。

將這幾種技術方案整合起來，我們可以設計出分散式 NoSQL 快取系統，當前這一類系統有一些比較強大的開源方案，比如 Memcached 和 Redis，它們對整個服務系統的可用性、可擴充套件性與效能起到至關重要的作用。

聽說最近騰訊開源了一個分散式 NoSQL 儲存系統 DCache，它的典型應用場景就在分散式快取。根據官方介紹，DCache 基於 TARS 微服務治理方案，它支援 k-v、k-k-row、list、set 與 zset 多種資料結構，資料基於記憶體儲存，同時支援後接 DB 實現資料持久化。DCache 具備快速水平擴充套件能力，同時配套有 Web 運維平臺實現高效的運維操作。

我們第一時間採訪了 DCache 研發團隊成員山寶銀，希望對專案的研發背景與相關技術細節有進一步瞭解。

當前開源的分散式快取系統中，Memcached 與 Redis 是很普遍的選擇，騰訊此次為什麼要自己造一個系統呢？

山寶銀介紹，雖然 Memcached 與 Redis 本身都擁有極其強大的能力，但是存在運維困難、缺乏叢集化方案與無法應對微服務趨勢帶來的挑戰等問題。

舉個例子，當前微服務是一大趨勢，大家都在說要做微服務，它可以讓計算與儲存之間解耦，實現輕量級通訊。微服務不需要管理生命同期，而作為系統元件的 Redis 則不然，“我們做服務架構設計時希望把邏輯層和資料層分離開來，但是如果使用 Redis 做快取，快取與 DB 之間的資料一致性問題，以及快取不命中如何解決等問題都需要使用者在業務邏輯中做相關處理，這增加了一定的複雜度和難度，也增加了邏輯層和資料層的耦合度。”

另一方面，山寶銀介紹，起初面對海量資料和高效能訪問需求，騰訊內部各個團隊其實都開發了各自的快取系統，然而這些系統之間協議不統一、服務模型多樣化、不具有通用性容錯、擴充套件能力也參差不齊，所以團隊就著手研發了 DCache 這一套通用 Cache 系統，希望整體去解決業務、開發、運維和監控面臨的各種挑戰。

所以也可以看到，目前 DCache 已經應用於騰訊內部多個業務上，包括 QQ 瀏覽器、應用寶、騰訊地圖、騰訊電腦管家、手機管家與騰訊遊戲等。

SQL、分散式與 NoSQL 的取捨

SQL 是指資料庫的結構化查詢語言，它是資料庫的操作命令集，傳統的關係型資料庫都使用標準的 SQL 陳述句操作處理資料。分散式是軟體系統的一種架構樣式，在分散式系統中，多個硬體或軟體元件分佈在不同計算機上，彼此之間透過訊息傳遞進行通訊，對外表現為一個整體，提供統一化的服務。

有一種普遍的觀點是，資料庫 SQL 與分散式之間存在天然對立性，山寶銀的理解是：“分散式系統因為資料分散在不同的節點，所以像 SQL 的聯表、事務等操作需要全域性的鎖保護，這樣處理起來比較複雜，並且影響效能。”

SQL 還有與 NoSQL 的取捨問題，NoSQL 是指一類資料庫，主要用於高效能處理超海量資料，它的一大特點是資料結構簡單，以 key-value 為主，資料之間非關聯，容易做水平擴充套件。

從字面上看，NoSQL 似乎是與 SQL 對立的，做 NoSQL 似乎就意味著放棄 SQL，然而實際上 NoSQL 本意是 Not Only SQL，它不僅僅是 SQL，那麼也就可以包含 SQL 的能力。

“NoSQL 也不是一定就得放棄 SQL，其實在代理層可以增加 SQL 的解析、計算邏輯來實現 SQL 操作，但這樣會影響效能，所以還是看應用場景和業務需求。”

山寶銀為我們簡單分析了 DCache “分散式 NoSQL”的意義。在 SQL 處理方面，分散式似乎存在劣勢，然而分散式意味著可以聯結更多的廉價計算機，充分運用算力，以低成本的方式應對高強度的併發訪問請求，此外分散式架構還有不少優勢，比如避免系統單點問題導致的整體故障，實現高可用。

而另一方面，山寶銀也說到：“DCache 因為主要的標的就是高效能，SQL 操作並不是主要想解決的問題，所以 DCache 沒有實現 SQL 的功能。”

DCache 分散式策略與能力

DCache 對外提供服務的粒度是 group，一個 group 負責一部分的資料分片，至於每個 group 服務哪些資料，是根據資料的 key 做 hash 對映後所處的範圍來確定的。

DCache 會把資料的 key 透過 hash 演演算法對映到 0～4294967295 (unsigned int) 範圍內，然後把 0～4294967295 範圍均勻劃分到不同的 group 上。例如有兩個 group，key 做 hash 後的值在 0～2147483647 範圍就分發到 group1，在 2147483648～4294967295 範圍就分發到 group2。

在一個 group 內，採用主備架構，只有主節點接收讀寫請求，所以資料一致性是可以保證的，而當主機不可用時，會觸發主備自動切換，保證服務持續可用。

DCache 架構

我們疑惑 DCache 似乎強依賴於 etcd 與 TARS 等中介軟體，那它本身的核心特性與能力體現在哪裡？

山寶銀解釋，DCache 並不強依賴 etcd，“etcd 只涉及了路由服務 RouterServer 的選主，如果 RouterServer 部署單點也是可用的，而且 RouterServer 的宕機不會影響到資料的讀寫訪問，因為所有的 Proxy 與 Cache 服務都有本地的路由快取”，關於 TARS 的採用，他說：“因為 TARS 是一個非常優秀的服務開發框架，它遮蔽了底層的網路通訊細節，且自帶了名字服務等很多服務化需要的功能，對於 DCache 來說，使用已有的 TARS 框架可以更好地做到服務化，我們沒有必要去重覆的造輪子。”

至於 DCache 本身的能力，山寶銀介紹：“DCache 自身的儲存引擎具有很高的效能，而且支援後接 DB，對使用者來說，不需要再關心 DB 和快取之間的資料一致性，以及快取不命中帶來的一系列問題。”

具體來說，DCache 持久化與 Redis 不一樣，後者只是把記憶體中的資料在本地磁碟做一個備份，保證 Redis 重啟之後做資料恢復。

“Redis 持久化主要是為了資料備份。DCache 後端有了 DB 以後，業務的邏輯與後臺的資料可以完全隔開，DCache 自身會處理快取與 DB 之間的資料一致性問題。

DCache 會不斷地將 Cache 中的資料落地後端 DB，如果 Cache 中儲存空間不夠，會將已經落地 DB 的冷資料淘汰掉。在資料查詢的過程中，如果查詢 Cache 不命中，會從 DB 讀取並重新存到 Cache，以此來保證 Cache 中資料的熱點性和命中率，同時 DB 與 Cache 的穿透問題也得到解決。

另外，資料持久化到後端 DB 的能力對於一些需要做離線資料分析的業務場景也比較方便。總之你完全不用關心資料的東西，只需要把資料寫到 Cache，後端的落地由 DCache 處理。”

DCache 特性

此外，DCache 的分散式叢集化、異地映象部署、容災容錯能力在實際線上應用中都會提供非常高的價值。

用武之地

作為一個分散式儲存系統，DCache 的應用場景沒有限制在快取上，山寶銀介紹，對於有高效能 NoSQL 儲存需求的場景，都可以使用 DCache，而且因為 DCache 具備容量淘汰與過期自動清理資料的功能，對於需要儲存熱點資料（如熱門文章）與臨時資料（如有時效性的聊天記錄）的場景也可以提供很好的支援。

山寶銀也提供了 DCache 的效能資料：

目前騰訊內部包括 QQ 瀏覽器、應用寶、騰訊地圖、騰訊電腦管家、手機管家與騰訊遊戲在內的近百個業務都接入了 DCache，這些業務的體量之大可以想象，山寶銀補充：“除了提供的這一組簡單的資料，DCache 在高效可靠地支撐著近百個業務的運轉，日均呼叫量過萬億次，這也從側面說明瞭 DCache 在生產環境的效能與穩定性。”

而除了系統本身高效能、高擴充套件、高可用與資料安全的設計外，Web 視覺化的高效運維平臺也成了 DCache 不可或缺的重要能力。基於記憶體的 NoSQL 儲存系統在運維上會產生巨大的額外開銷，它需要對相關技術進行深入理解，並且在緊要關頭果斷做出正確決策。

DCache 基於 TARS 開發，所以運維平臺將 DCache 與 TARS 的服務管理統一做在了一個模組上，山寶銀介紹該運維平臺將大大提高效率，同時降低了運維門檻，關於服務的部署、上線、遷移、擴容、監控與配置這些操作都可以輕鬆實現。 

嘉賓介紹

山寶銀，騰訊後臺高階工程師，專註於分散式 NoSQL 儲存領域的技術研發工作，參與騰訊多個自研儲存系統的開發，在分散式系統、高可用與高效能服務等領域有較豐富的經驗。