先進的性能,說明騰訊云的新一代Redis緩存數據庫

 xinwen   2020-04-15 07:17   236 人閱讀  0 條評論

背景

當前,內存數據庫發展迅速,用戶對存儲系統的要求越來越高。 為了滿足各種業務場景的需求,騰訊云設計了新一代的內存數據庫,不僅保留了原有系統的高性能和高可用性,同時還與當前流行的Redis本機兼容。 協議和使用方法。我們試圖在解決原始解決方案的缺點的基礎上繼續進行創新,以使新系統具有易于理解,易于使用,易于維護,高可靠性和低成本的特點。它主要體現在以下幾個方面:

1.上一代自主開發的系統使用共享內存數據存儲解決方案來避免Redis使用AOF機制且恢復時間過長的問題,從而大大減少了升級和過程異常等場景的影響。同時,新的快照和流水線機制用于解決由fork機制引起的內存保留問題。

2. 在存儲引擎方面,已經對自主開發的開源解決方案進行了重新分析和創新。它不僅使用多種特定的塊存儲方法的靈活組合,而且內部數據結構還使用動態頁面管理。 與本機引擎相比,它有了很大的改進。在使用內存的同時,還減少了運行期間內存碎片的機會

3. 單進程多線程模型使操作和維護部署更加容易,同時減少了模塊數量并縮短了請求路徑

4.更精細的數據管理,以實現快速淘汰和準確的LRU功能

5.實現了強大的一致性,可以滿足金融和其他業務對數據一致性的強烈需求

6. 在集群版本模式下,支持多種數據庫方案,從而降低了用戶從主從版本遷移到集群版本的閾值。

7存儲節點可以直接轉發用戶請求,從而減少了后臺數據更改對客戶端的依賴性。 本機主從客戶端可以直接訪問群集版本,而無需修改代碼

8.我們與更多本地數據庫協議兼容,從而允許更多用戶無縫切換并體驗更多新功能

技術架構優化過程

在體系結構方面,我們將當前的兩層結構(不包括客戶端)簡化為單層,如下圖所示。

圖1架構圖

圖中的主節點是集群的管理節點。 每組母版管理一個區域中的幾個群集。

緩存是實際的數據存儲節點。該體系結構不再顯式設置訪問層,而是通過緩存轉發用戶請求。 這樣做的好處是:

·由于對不同類型的資源(CPU,網卡,內存等)的需求殷切,因此簡單的存儲或訪問模塊),無法提高當前高調機型的設備利用率?;谶@個原因,理論上,組合的單層結構可以更好地利用硬件資源并節省成本。

·減少模塊數量,可以減少很多運維操作,方便運維學生部署和規劃資源。

·路由距離數據更近,因此在緩存上執行數據遷移操作時,它可以實時響應用戶請求(轉發到最新目的地),從而減少更改對用戶請求的影響

對于某些對接入層有強烈需求的場景,例如,某項服務的客戶端連接數量非常大,我們還針對性地對其進行了優化。緩存可以降級以供純訪問計算機使用,因此可以統一使用一組代碼輕松地將其擴展為兩層結構,而無需單獨維護。

在數據分配方面,使用了所有方法,也就是說,在任何一個Cache上既有主數據又有(其他業務)備份數據,并且以碎片(粒度)(物理存儲單元)進行管理,如圖1所示。 下圖。

圖2分片分布

每個高速緩存的內存分為幾個碎片。 無論是主從版本還是群集版本,用戶的主數據或備份數據都可能屬于任何緩存。 分配策略支持跨機架和跨計算機機房。目的是:

·不再有簡單的熱備用設備,減少了低負載設備的比例,并充分利用了整個群集的網卡,CPU和其他資源

·當一個或多個節點異常時,請使用整個群集的容量進行容錯(交換流量)和恢復(在不同節點上重建備份),以避免雪球效應

·在分配期間,將考慮現有設備的活動和備用分片比率以及負載以優化打包算法,但是群集資源將更加均衡

因為CKV +與Redis協議和各種使用場景兼容,所以它也可以區分主版本和從版本以及群集版本。對于集群版本,在進行比較之后,數據哈希仍然使用預分片方法,如下圖所示。

圖3數據哈希

對于單個Shard來說,最大可管理內存為8T,由于目前設備限制,實際最大可支持512G,因此集群版支持的容量范圍為 [1G,512G] * 16384=[16T,8P]。當然,在實際應用中,需要考慮系統中預留資源等因素,分片的大小和時隙對應關系的規劃也取決于物理資源情況。

內存引擎設計,確定CKV +引擎

內存管理是內存數據庫系統中非常重要的部分。 在CKV +系統的設計階段,對引擎進行了大量討論和研究。 根據我們的經驗,它吸收了許多主流內存管理系統的優勢,并確定了當前的CKV +引擎解決方案。主要功能概述如下:

·使用共享內存在升級或過程異常期間進行快速恢復

·基于共享內存的實現的紅黑樹算法,與Redis中的Hash,Set,ZSet數據類型兼容,同時確保性能

·使用多規格塊作為(最?。祿鎯卧?,更靈活,存儲空間更小

·使用經典的頁面管理模式,優化動態分配策略,提高頁面回收率,并降低內存碎片率

·還根據頁面動態分配了附加了用戶數據的內部數據結構,從而減少了內部保留空間的浪費

圖4內存引擎

內存引擎的重要指標是內存使用情況。 我們對本機Redis存儲進行了比較測試。

測試方法:使用相同的隨機數據分別寫入Redis和CKV +的1G實例,并比較實際存儲的數據量。

樣本大?。簁ey [10.30],Value [20,100]

圖5利用率比較

測試結果表明,在簡單的String類型的情況下,兩者的存儲容量是相似的,但是在稍微復雜一些的結構中,CKV +可以存儲更多的用戶數據。

大膽嘗試,使用單進程多線程模型

對于內存數據庫,高性能仍然是主要前提,開發過程中使用的線程模型和框架對此級別具有更大的影響。因此,在設計開始時,我們就此部分也進行了大膽的嘗試。

首先,我們使用單進程多線程模型來代替大多數開源系統的單進程單線程方法。 一方面,我們可以更好地利用整個機器資源,另一方面,可以降低運維門檻。對于多線程,需要解決的主要問題如下:

·多個線程共同管理內存將不可避免地需要引入鎖,而高端模型具有更多的內核和更多的線程,并且鎖定可能會導致故障

·一個流程需要管理多個業務數據,尤其是主從版本。 每個存儲器具有大的分片容量,不可避免地具有大量的kv數據。 同時,主從版本支持一些耗時的操作。 必須最小化實例之間的交互。

·在線程之間通信或共享數據的開銷很小,例如同步路由信息

還應考慮線程上下文切換,CPU緩存命中率,IO等因素。

經過一系列研究工作,最終確定了線程模型,如下所示:每個物理核心啟動一個線程并管理多個內存分片,如下圖所示。

圖6線程模型

使用此模型的主要注意事項:

·特定的內存操作僅由一個CPU處理,以避免鎖定。 當熱點出現在分片上時,它將對其他線程管理的實例產生很小的影響。

·在管理實例數量較少的情況下,空閑的CPU可以處理網絡和磁盤IO以及請求的成都網站建設編解碼器,并提高整體資源利用率。

·線程之間沒有依賴性或競爭,以避免不必要的磨損

性能測試

性能應該是每個人都更加關注的一部分。 我們對Redis的String和ZSet數據結構進行了性能測試,結果如下。

注意:

·“單個實例”表示一個緩存僅管理一個分片,“ N實例”表示管理N個分片

所有測試均使用2400個客戶端對整個設備進行壓力測試

·測試不涉及消息轉發,即客戶端直接請求數據的設備

測試樣本分別使用10和100字節的數據

·在此測試中未啟用DPDK,以后將對其進行補充

圖7 STRING類型的讀寫性能比較

圖8 ZSET類型的讀寫性能比較

結論

騰訊云的下一代內存數據庫不僅與Redis的數據結構和使用方法完全兼容,而且還解決了本機解決方案在備份和災難恢復方面的缺點。在績效方面,我們對現狀不滿意。 我們將進一步詳細優化邏輯流程,并引入諸如DPDK之類的功能,以進一步提高系統性能。成本也是我們關注的焦點。 當前的系統架構和線程模型可以更好地適應硬件設備不斷增長的性能,并提高硬件資源的利用率。 同時,我們還將引入冷,熱數據分離等技術,以確保在前提下更好地為用戶節省成本。

本文地址:http://www.hkdealsale.com/webnews/?id=710
版權聲明:本文為原創文章,版權歸 xinwen 所有,歡迎分享本文,轉載請保留出處!

評論已關閉!