採訪嘉賓 | 山寶銀 算法
編輯 | h4cd數據庫
當你在電商平臺秒殺商品或者在社交網絡刷熱門話題的時候，能夠很明顯感覺到當前網絡數據流量的恐怖，幾十萬商品剛開搶，一秒都不到就售罄；哪一個大明星出軌的消息一出現，瞬間閱讀與轉發次數能夠達到上億。做爲終端用戶的咱們可能會思考，服務系統是怎麼在這樣嚴峻的流量環境中存活下來的。後端
其實，服務系統的架構中有許多巧妙的設計來應對這樣的問題，而在這其中，一般系統都會架設緩存系統，用以緩解海量訪問請求與數據帶來的衝擊，實現高性能訪問需求。瀏覽器
同時，隨着微服務與雲等技術的發展，分佈式架構的需求變得愈來愈廣泛，再加上今天 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 之間的數據一致性問題，以及緩存不命中如何解決等問題都須要使用者在業務邏輯中作相關處理，這增長了必定的複雜度和難度，也增長了邏輯層和數據層的耦合度。」
另外一方面，山寶銀介紹，起初面對海量數據和高性能訪問需求，騰訊內部各個團隊其實都開發了各自的緩存系統，然而這些系統之間協議不統1、服務模型多樣化、不具備通用性容錯、擴展能力也良莠不齊，因此團隊就着手研發了 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 存儲領域的技術研發工做，參與騰訊多個自研存儲系統的開發，在分佈式系統、高可用與高性能服務等領域有較豐富的經驗。
（點擊文末「閱讀原文」，查看DCache源代碼）
本文分享自微信公衆號 - TARS星球（TarsCloud）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。