日韩精品一区二区三区波多野结衣,精品久久久久9999无码,欧美三级,中文字幕精品一区二区精品绿巨人,国产电影自拍,亚洲国产日韩欧美在线一区,美女无遮挡撒尿,婷婷综合五月天

數(shù)據(jù)也有冷熱之分，你知道嗎？

根據(jù)訪問的頻率的高低可將數(shù)據(jù)分為熱數(shù)據(jù)和冷數(shù)據(jù)，訪問頻率高的則為熱數(shù)據(jù)，低為冷數(shù)據(jù)。如果熱、冷數(shù)據(jù)不區(qū)分，一并存儲，顯然不科學(xué)。將冷數(shù)據(jù)也存儲在昂貴的內(nèi)存中，那么你想，成本得多高呢？

有趣的是，根據(jù)我們實際的觀察，目前很多使用 Redis 的業(yè)務(wù)就是這樣操作的。

得益于高性能以及豐富的數(shù)據(jù)結(jié)構(gòu)命令，Redis 成為目前最受歡迎的 KV 內(nèi)存數(shù)據(jù)庫。但隨著業(yè)務(wù)數(shù)據(jù)量的爆炸增長，Redis 的內(nèi)存消耗也會隨之爆炸。無論客戶是自建服務(wù)器還是云服務(wù)器，內(nèi)存都是一個必須考慮的成本問題，它不僅貴還要持續(xù)購買。

此外 Redis 雖然提供了 AOF 和 RDB 兩種方案來實現(xiàn)數(shù)據(jù)的持久化，但是使用不當(dāng)可能會對性能造成影響甚至引發(fā)丟數(shù)據(jù)的問題。

好在，隨著科技的發(fā)展，持久化硬件的發(fā)展速度也在提升，持久內(nèi)存的出現(xiàn)進(jìn)一步縮小了與內(nèi)存的性能差距。或許，合理利用新型持久化技術(shù)會成為一個好的成本解決方案。

基于這一思路，為解決 Redis 可能帶來的內(nèi)存成本、容量限制以及持久化等一系列問題，騰訊云數(shù)據(jù)庫團(tuán)隊推出了新一代分布式KV存儲數(shù)據(jù)庫 KeeWiDB。本文將詳細(xì)介紹KeeWiDB 的架構(gòu)設(shè)計思路、實現(xiàn)路徑及成效。先簡單總結(jié)一下 KeeWiDB 的特性：

友好：完全兼容 Redis 協(xié)議，原先使用 Redis 的業(yè)務(wù)無需修改任何代碼便可以遷移到 KeeWiDB 上；
高性能低延遲：通過創(chuàng)新性的分級存儲架構(gòu)設(shè)計，單節(jié)點(diǎn)讀寫能力超過 18 萬 QPS，訪問延遲達(dá)到毫秒級；
更低的成本：內(nèi)核自動區(qū)分冷熱數(shù)據(jù)，冷數(shù)據(jù)存儲在相對低價的 SSD 上；
更大的容量：節(jié)點(diǎn)支持 TB 級別的數(shù)據(jù)存儲，集群支持 PB 級別的數(shù)據(jù)存儲；
保證了事務(wù)的 ACID (原子性 Atomicity、一致性 Consitency、隔離性 Isolation、持久性 Durability)四大特性；

整體架構(gòu)

KeeWiDB 的架構(gòu)由代理層和服務(wù)層兩個部分構(gòu)成：

代理層：由多個無狀態(tài)的Proxy節(jié)點(diǎn)組成，主要功能是負(fù)責(zé)與客戶端進(jìn)行交互；

服務(wù)層：由多個Server節(jié)點(diǎn)組成的集群，負(fù)責(zé)數(shù)據(jù)的存儲以及在機(jī)器發(fā)生故障時可以自動進(jìn)行故障切換。

圖：KeeWiDB整體架構(gòu)圖

代理層

客戶端通過 Proxy 連接來進(jìn)行訪問，由于 Proxy 內(nèi)部維護(hù)了后端集群的路由信息，所以 Proxy 可以將客戶端的請求轉(zhuǎn)發(fā)到正確的節(jié)點(diǎn)進(jìn)行處理，從而客戶端無需關(guān)心集群的路由變化，用戶可以像使用 Redis 單機(jī)版一樣來使用 KeeWiDB。

Proxy 的引入，還帶來了諸多優(yōu)勢：

客戶端直接和 Proxy 進(jìn)行交互，后端集群在擴(kuò)縮容場景不會影響客戶端請求；
Proxy 內(nèi)部有自己的連接池和后端 KeeWiDB 進(jìn)行交互，可大大減少 KeeWiDB 上的連接數(shù)量，同時有效避免業(yè)務(wù)短連接場景下反復(fù)建連斷連對內(nèi)核造成性能的影響；
支持讀寫分離，針對讀多寫少的場景，通過添加副本數(shù)量可以有效分?jǐn)?KeeWiDB 的訪問壓力；
支持命令攔截和審計功能，針對高危命令進(jìn)行攔截和日志審計，大幅度提高系統(tǒng)的安全性；
由于 Proxy 是無狀態(tài)的，負(fù)載較高場景下可以通過增加 Proxy 數(shù)量來緩解壓力，此外我們的 Proxy 支持熱升級功能，后續(xù) Proxy 添加了新功能或者性能優(yōu)化，存量 KeeWiDB 實例的 Proxy 都可以進(jìn)行對客戶端無感知的平滑升級；

圖：Proxy上的功能

服務(wù)層

KeeWiDB 的后端采用了集群的架構(gòu)，這是因為集群具有高可用、可擴(kuò)展性、分布式、容錯等優(yōu)質(zhì)特性；同時，在具體的實現(xiàn)上參考了 Redis 的集群模式。KeeWiDB 集群同樣由若干個分片構(gòu)成，而每個分片上又存在若干個節(jié)點(diǎn)，由這些節(jié)點(diǎn)共同組成一主多從的高可用架構(gòu)；此外每個分片的主節(jié)點(diǎn)負(fù)責(zé)集群中部分 Slot 的數(shù)據(jù)，并且可以通過動態(tài)修改主節(jié)點(diǎn)負(fù)責(zé) Slot 區(qū)間的形式來實現(xiàn)橫向的擴(kuò)縮容，為客戶提供了容量可彈性伸縮的能力。

Server內(nèi)部模型

在 Server 內(nèi)部存在一個集群管理模塊，該模塊通過 Gossip 協(xié)議與集群中的其他節(jié)點(diǎn)進(jìn)行通信，獲取集群的最新狀態(tài)信息；另外 Server 內(nèi)部存在多個工作線程，KeeWiDB 會將當(dāng)前 Server 負(fù)責(zé)的 Slot 區(qū)間按一定的規(guī)則劃分給各個工作線程進(jìn)行處理，并且每個工作線程都有自己獨(dú)立的連接管理器，事務(wù)模塊以及存儲引擎等重要組件，線程之間不存在資源共享，做到了進(jìn)程內(nèi)部的 Shared-Nothing。正是這種 Shared-Nothing 的體系結(jié)構(gòu)，減少了 KeeWiDB 進(jìn)程內(nèi)部線程之間由于競爭資源的等待時間，獲得了良好并行處理能力以及可擴(kuò)展的性能。

圖：Server內(nèi)部模塊

線程模型

KeeWiDB 的設(shè)計目的，就是為了解決 Redis 的痛點(diǎn)問題。所以大容量，高性能以及低延遲是 KeeWiDB 追求的目標(biāo)。

和數(shù)據(jù)都存放在內(nèi)存中的 Redis 不同，KeeWiDB 的數(shù)據(jù)是存儲在 PMem(Persistent Memory)和相對低價的 SSD 上。在用戶執(zhí)行讀寫訪問請求期間 KeeWiDB 都有可能會涉及到跟硬盤的交互，所以如果還像 Redis 一樣采用單進(jìn)程單線程方案的話，單節(jié)點(diǎn)的性能肯定會大打折扣。因此，KeeWiDB 采取了單進(jìn)程多線程的方案，一方面可以更好的利用整機(jī)資源來提升單節(jié)點(diǎn)的性能，另一方面也能降低運(yùn)維門檻。

多線程方案引入的核心思想是通過提高并行度來提升單節(jié)點(diǎn)的吞吐量，但是在處理用戶寫請求期間可能會涉及到不同線程操作同一份共享資源的情況，比如存儲引擎內(nèi)部為了保證事務(wù)的原子性和持久性需要寫 WAL，主從之間進(jìn)行同步需要寫 Binlog，這些日志文件在寫入的過程中通常會涉及到持久化操作，相對較慢。雖然我們也采取了一系列的優(yōu)化措施，例如使用組提交策略來降低持久化的頻率，但是優(yōu)化效果有限。

同時為了保證線程安全，在這類日志的寫入期間通常都要進(jìn)行加鎖，這樣一來，一方面雖然上層可以多線程并行的處理用戶請求，但是到了寫日志期間卻退化成了串行執(zhí)行；另一方面，申請和釋放鎖通常會涉及到用戶態(tài)和內(nèi)核態(tài)的切換，頻繁的申請釋放操作會給 CPU 帶來額外的開銷，顯然會導(dǎo)致性能問題。

圖：線程模型

正是由于進(jìn)程內(nèi)不同線程訪問同一份共享資源需要加鎖，而大量的鎖沖突無法將多線程的性能發(fā)揮到極致，所以我們將節(jié)點(diǎn)內(nèi)部負(fù)責(zé)的 Slot 區(qū)間進(jìn)行進(jìn)一步的拆分，每個工作線程負(fù)責(zé)特定一組 Slot 子區(qū)間的讀寫請求，互不沖突；此外每個工作線程都擁有自己獨(dú)立的事務(wù)模塊以及存儲引擎等重要組件，不再跨線程共享。

通過對共享資源進(jìn)行線程級別的拆分，各個線程在處理用戶請求時都可以快速的獲得所需要的資源，不發(fā)生等待事件，這無論是對單個請求延遲的降低還是多個請求并發(fā)的提升，都有巨大的好處；此外由于處理用戶請求所需的資源都在線程內(nèi)部，KeeWiDB 無需再為了線程安全而上鎖，有效規(guī)避了由于頻繁上鎖帶來的額外性能開銷。

引入?yún)f(xié)程

通過上面的章節(jié)介紹，KeeWiDB 通過進(jìn)程內(nèi)部 Shared-Nothing 的體系結(jié)構(gòu)減少了線程之間由于競爭共享資源花費(fèi)的等待時間，提升了進(jìn)程內(nèi)部的并發(fā)度。此時我們再將視角轉(zhuǎn)移到線程內(nèi)部，在業(yè)務(wù)高峰時期工作線程也需要負(fù)責(zé)處理大量的客戶端請求，由于每次請求操作都有可能會涉及到和磁盤的交互，此時如果再采用同步 IO 的形式和磁盤進(jìn)行交互的話，由于一個客戶端請求執(zhí)行的 I/O 操作就會阻塞當(dāng)前線程，此時后面所有的客戶端請求需要排隊等待處理，顯然并發(fā)度會大打折扣。

這時候也許有讀者會提出按照 KeeWiDB 目前這套進(jìn)程內(nèi)部 Shared-Nothing 的體系結(jié)構(gòu)，線程之間不存在共享資源競爭了，是不是可以通過增加線程數(shù)來緩解這個問題？想法不錯，但是大量的線程引入可能會帶來另外一些問題：

開啟過多的線程會耗費(fèi)大量的系統(tǒng)資源, 包括內(nèi)存；
線程的上下文切換涉及到用戶空間和內(nèi)核空間的切換, 大量線程的上下文切換同樣會給 CPU 帶來額外的開銷；

為了讓單個線程的性能能夠發(fā)揮到極致，不把時間浪費(fèi)在等待磁盤 I/O 上，KeeWiDB 首先考慮的是采取異步 I/O 的方案(應(yīng)用層觸發(fā) I/O 操作后立即返回，線程可以繼續(xù)處理其他事件，而當(dāng) I/O 操作已經(jīng)完成的時候會得到 I/O 完成的通知)。

很明顯，使用異步 I/O 來編寫程序性能會遠(yuǎn)遠(yuǎn)高于同步 I/O，但是異步 I/O 的缺點(diǎn)是編程模型復(fù)雜。我們常規(guī)的編碼方式是自上而下的，但是異步 I/O 編程模型大多采用異步回調(diào)的方式。

隨著項目工程的復(fù)雜度增加，由于采用異步回調(diào)編寫的代碼和常規(guī)編碼思維相悖，尤其是回調(diào)嵌套多層的時候，不僅開發(fā)維護(hù)成本指數(shù)級上升，出錯的幾率以及排查問題的難度也大幅度增加。

正是由于異步 I/O 編程模型有上面提到的種種缺點(diǎn)，我們經(jīng)過一系列調(diào)研工作之后，決定引入?yún)f(xié)程來解決我們的痛點(diǎn)，下面先來看一下cppreference中對協(xié)程的描述：

A coroutine is a function that can suspend execution to be resumed later. Coroutines are stackless: they suspend execution by returning to the caller and the data that is required to resume execution is stored separately from the stack. This allows for sequential code that executes asynchronously (e.g. to handle non-blocking I/O without explicit callbacks).

from：https://en.cppreference.com/w/cpp/language/coroutines

協(xié)程實際上就是一個可以掛起(suspend)和恢復(fù)(resume)的函數(shù)，我們可以暫停協(xié)程的執(zhí)行，去做其他事情，然后在適當(dāng)?shù)臅r候恢復(fù)到之前暫停的位置繼續(xù)執(zhí)行接下來的邏輯?？偠灾?，協(xié)程可以讓我們使用同步方式編寫異步代碼。

圖：協(xié)程切換示意圖

KeeWiDB 為每一個客戶端連接都創(chuàng)建了一個協(xié)程，以上圖為例，在工作線程內(nèi)服務(wù)三個客戶端連接，就創(chuàng)建三個協(xié)程。在[T0，T1)階段協(xié)程0正在執(zhí)行邏輯代碼，但是到了T1時刻協(xié)程0發(fā)現(xiàn)需要執(zhí)行磁盤 I/O 操作獲取數(shù)據(jù)，于是讓出執(zhí)行權(quán)并且等待 I/O 操作完成，此時協(xié)程2獲取到執(zhí)行權(quán)，并且在[T1，T2)時間段內(nèi)執(zhí)行邏輯代碼，到了T2時刻協(xié)程2讓出執(zhí)行權(quán)，并且此時協(xié)程0的 I/O 事件正好完成了，于是執(zhí)行權(quán)又回到協(xié)程0手中繼續(xù)執(zhí)行。

可以看得出來，通過引入?yún)f(xié)程，我們有效解決了由于同步 I/O 操作導(dǎo)致線程阻塞的問題，使線程盡可能的繁忙起來，提高了線程內(nèi)的并發(fā)；另外由于協(xié)程切換只涉及基本的 CPU 上下文切換，并且完全在用戶空間進(jìn)行，而線程切換涉及特權(quán)模式切換，需要在內(nèi)核空間完成，所以協(xié)程切換比線程切換開銷更小，性能更優(yōu)。

數(shù)據(jù)存儲

在文章開頭有提到在持久內(nèi)存出現(xiàn)后，進(jìn)一步縮小了與內(nèi)存的性能差距，持久內(nèi)存是一種新的存儲技術(shù)，它結(jié)合了 DRAM 的性能和字節(jié)尋址能力以及像 SSD 等傳統(tǒng)存儲設(shè)備的可持久化特性，正是這些特性使得持久內(nèi)存非常有前景，并且也非常適合用于數(shù)據(jù)庫系統(tǒng)。

圖：Dram和PMem以及SSD的性能比較

通過上圖可以看到，PMem(Persistent Memory)相對于 DRAM 有著更大的容量，但是相對于 SSD 有著更大的帶寬和更低的讀寫延遲，正是因為如此，它非常適合存儲引擎中的大容量Cache和高性能 WAL 日志。

前面有提到過日志文件在寫入的過程中涉及到的持久化操作有可能會成為整個系統(tǒng)的瓶頸，我們通過將 WAL 存放在 PMem 上，日志持久化操作耗時大幅降低，提升了服務(wù)整體的性能；此外由于 PMem 的讀寫速度比 SSD 要快1~2個數(shù)量級，在故障恢復(fù)期間，回放 WAL 的時間也大幅度的縮短，整個系統(tǒng)的可用性得到了大幅度的提升。

考慮到 KeeWiDB 作為高性能低延遲的數(shù)據(jù)庫，我們不僅需要做到平均延遲低，更要做到長尾延遲可控。

雖然在涉及到文件操作的場景下，利用 Page Cache 技術(shù)能夠大幅提升文件的讀寫速度，但是由于 Page Cache 默認(rèn)由操作系統(tǒng)調(diào)度分配，存在一定的不確定性(內(nèi)核總是積極地將所有空閑內(nèi)存都用作 Page Cache 和 Buffer Cache，當(dāng)內(nèi)存不夠用時就會使用 LRU 等算法淘汰緩存頁, 此時有可能造成文件讀寫操作有時延抖動)，在一些極端場景下可能會直接影響客戶實例的P99，P100。所以 KeeWiDB 采用了 Direct I/O的方式來繞過操作系統(tǒng)的 Page Cache 并自行維護(hù)一份應(yīng)用層數(shù)據(jù)的 Cache，讓磁盤的 IO 更加可控。

使用 Page cache 能夠大大加速文件的讀寫速度，那什么是頁面緩存（Page Cache）呢？

In computing, a page cache, sometimes also called disk cache, is a transparent cache for the pages originating from a secondary storage device such as a hard disk drive (HDD) or a solid-state drive (SSD). The operating system keeps a page cache in otherwise unused portions of the main memory (RAM), resulting in quicker access to the contents of cached pages and overall performance improvements. A page cache is implemented in kernels with the paging memory management, and is mostly transparent to applications.

from：https://en.wikipedia.org/wiki/Page_cache#cite_note-1

和大多數(shù)磁盤數(shù)據(jù)庫一樣，KeeWiDB 將 Page 作為存儲引擎磁盤管理的最小單位，將數(shù)據(jù)文件內(nèi)部劃分成若干個 Page，每個 Page 的大小為 4K，用于存儲用戶數(shù)據(jù)和一些我們存儲引擎內(nèi)部的元信息。從大容量低成本的角度出發(fā)，KeeWiDB 將數(shù)據(jù)文件存放在 SSD 上。

圖：數(shù)據(jù)頁的升溫和落冷

此外，得益于 PMem 接近于 DRAM 的讀寫速度以及支持字節(jié)尋址的能力，KeeWiDB在 PMem 上實現(xiàn)了存儲引擎的 Cache 模塊，在服務(wù)運(yùn)行期間存放業(yè)務(wù)熱數(shù)據(jù)的數(shù)據(jù)頁會被加載到 PMem 上，KeeWiDB 在處理用戶請求期間不再直接操作 SSD 上的數(shù)據(jù)頁，而是操作讀寫延遲更低的 PMem，使得 KeeWiDB 的性能以及吞吐量得到了進(jìn)一步的提升；

同時為了能夠合理高效的利用 PMem 上的空間，KeeWiDB 內(nèi)部實現(xiàn)了高效的 LRU 淘汰算法，并且通過異步刷臟的方式，將 PMem 中長時間沒有訪問的數(shù)據(jù)頁寫回到 SSD 上的數(shù)據(jù)文件中。

主從同步

文章開頭的架構(gòu)圖有提到 KeeWiDB 集群由多個分片構(gòu)成，每個分片內(nèi)部有多個節(jié)點(diǎn)，這些節(jié)點(diǎn)共同組成一主多從的高可用架構(gòu)。和 Redis 類似，用戶的請求會根據(jù) Key 被路由到對應(yīng)分片的主節(jié)點(diǎn)，主節(jié)點(diǎn)執(zhí)行完后再將請求轉(zhuǎn)化為 Binlog Record 寫入本地的日志文件并轉(zhuǎn)發(fā)給從節(jié)點(diǎn)，從節(jié)點(diǎn)通過應(yīng)用日志文件完成數(shù)據(jù)的復(fù)制。

在 Redis 的 Replication 實現(xiàn)中，從節(jié)點(diǎn)每接收一個請求都立即執(zhí)行，然后再繼續(xù)處理下一個請求，如此往復(fù)。依賴其全內(nèi)存的實現(xiàn)，單個請求的執(zhí)行耗時非常短，從節(jié)點(diǎn)的回放相當(dāng)于是單連接的 pipeline 寫入，其回放速度足以跟上主節(jié)點(diǎn)的執(zhí)行速度。但這種方式卻不適合 KeeWiDB 這樣的存儲型數(shù)據(jù)庫，主要原因如下：

存儲型數(shù)據(jù)庫的請求執(zhí)行過程中涉及到磁盤 IO，單個請求的執(zhí)行耗時本身就比較長；
主節(jié)點(diǎn)同時服務(wù)多個客戶端連接，不同連接的請求并發(fā)執(zhí)行，發(fā)揮了協(xié)程異步 IO 的優(yōu)勢，節(jié)點(diǎn)整體 QPS 有保障；
主從同步只有一個連接，由于從庫順序回放請求，無法并發(fā)，回放的 QPS 遠(yuǎn)遠(yuǎn)跟不上主節(jié)點(diǎn)處理用戶請求的 QPS；

為了提升從節(jié)點(diǎn)回放的速度，避免在主庫高負(fù)載寫入場景下，出現(xiàn)從庫追不上主庫的問題，KeeWiDB 的 Replication 機(jī)制做了以下兩點(diǎn)改進(jìn):

在從節(jié)點(diǎn)增加 RelayLog 作為中繼，將從節(jié)點(diǎn)的命令接收和回放兩個過程拆開，避免回放過程拖慢命令的接收速度；
在主節(jié)點(diǎn)記錄 Binlog 的時候增加邏輯時鐘信息，回放的時候根據(jù)邏輯時鐘確定依賴關(guān)系，將互相之間沒有依賴的命令一起放進(jìn)回放的協(xié)程池，并發(fā)完成這批命令的回放，提升從節(jié)點(diǎn)整體的回放 QPS；

圖：從庫并發(fā)回放

所謂的邏輯時鐘，對應(yīng)到 KeeWiDB 的具體實現(xiàn)里，就是我們在每一條 BinLog record 中添加了 seqnum 和 parent 兩個字段：

seqnum 是主節(jié)點(diǎn)事務(wù) commit 的序列號，每次有新的事務(wù) commit，當(dāng)前 seqnum 賦給當(dāng)前事務(wù)，全局 seqnum 自增1；
parent 由主節(jié)點(diǎn)在每個事務(wù)開始執(zhí)行前的 prepare 階段獲取，記錄此時已經(jīng) commit 的最大 seqnum，記為 max，說明當(dāng)前事務(wù)是在 max 對應(yīng)事務(wù) commit 之后才開始執(zhí)行，二者在主節(jié)點(diǎn)端有邏輯上的先后關(guān)系；

從節(jié)點(diǎn)回放 RelayLog 中的 Binlog Record 時，我們只需要簡單地將它的 parent 和 seqnum 看作一個區(qū)間，簡記為(P，S)，如果它的(P，S)區(qū)間和當(dāng)前正在回放的其它Record 的(P，S)區(qū)間有交集，說明他們在主節(jié)點(diǎn)端 Prepare 階段沒有沖突，可以把這條 Record 放進(jìn)去一塊并發(fā)地回放，反之，則這條 Record 需要阻塞等待，等待當(dāng)前正在回放的這批 Binlog Record 全部結(jié)束后再繼續(xù)。

通過在 Binlog 中添加 seqnum 和 parent 兩個字段，我們在保證數(shù)據(jù)正確性的前提下實現(xiàn)了從庫的并發(fā)回放，確保了主庫在高負(fù)載寫入場景下，從庫依舊可以輕松的追上主庫，為我們整個系統(tǒng)的高可用提供了保障。

總結(jié)

本篇文章先從整體架構(gòu)介紹了 KeeWiDB 的各個組件，然后深入 Server 內(nèi)部分析了在線程模型選擇時的一些思考以及面臨的挑戰(zhàn)，最后介紹了存儲引擎層面的數(shù)據(jù)文件以及相關(guān)日志在不同存儲介質(zhì)上的分布情況，以及 KeeWiDB 是如何解決從庫回放 Binlog 低效的問題。通過本文，相信不少讀者對 KeeWiDB 又有了進(jìn)一步的了解。那么，在接下來的文章中我們還會深入到 KeeWiDB 自研存儲引擎內(nèi)部，向讀者介紹 KeeWiDB 在存儲引擎層面如何實現(xiàn)高效的數(shù)據(jù)存儲和索引，敬請期待。

目前，KeeWiDB 正在公測階段（點(diǎn)擊閱讀原文