「百變」Redis帶你見識不同場景下的產品技術架構

原標題：「百變」Redis帶你見識不同場景下的產品技術架構

2018飛天技術匯24期-雲資料庫Redis產品發佈會，由阿里雲資料庫技術組技術專家王歡、懷聽、樑盼分別帶來以「Redis全球多活產品」、「Redis混合儲存產品」、「Redis多執行緒效能增強版」為題的演講。本文對Redis進行了簡單的介紹，進而針對不同的應用場景研製出不同的產品，並對不同產品分別進行了詳細地介紹。

以下內容根據精彩視訊分享整理而成。

Redis簡介

Redis 是一個高效能的key-value資料庫，Redis的優勢有很多，例如，它的效能極高 ，Redis能讀的速度是110000次/s,寫的速度是81000次/s ；它具有豐富的資料型別，可支援二進制案例的 Strings、Lists、Hashes、Sets 及 Ordered Sets 資料型別操作；它的所有操作都是原子性的，意思就是要麼成功執行要麼失敗完全不執行；它還具有豐富的特性， 即支援 publish/subscribe、通知、key過期等等特性。

Redis 與其他key – value 快取產品有三個共同特點：一是Redis支援資料的持久化，可以將記憶體中的資料儲存在磁碟中，重啟的時候可以再次載入進行使用；二是Redis不僅僅支援簡單的key-value型別的資料，同時還提供list、set、zset、hash等數據結構的儲存；三是Redis支援資料的備份，即master-slave模式的資料備份。

Redis與其他key-value儲存的不同點在於Redis有著更為複雜的數據結構並且提供對它們的原子性操作，這是一個不同於其他資料庫的進化路徑。Redis的資料型別都是基於基本數據結構的同時對程式設計師是透明的，無需進行額外的抽象。另外的一個不同點在於Redis在記憶體中執行時可以持久化到磁碟中，所以在對不同資料集進行高速讀寫時需要權衡記憶體，因為資料量不能大於硬體記憶體。因此，與磁碟上相同的複雜數據結構相比，在記憶體中操作起來更為簡單，這樣Redis可以做很多內部複雜性很強的事情。同時，在磁碟格式方面它們是緊湊以追加的方式產生的，因為他們並不需要進行隨機訪問。

Redis全球多活產品

Redis全球多活產品是指多個Redis例項分佈在全球不同的區域，它是阿里雲自研、基於雲資料庫Redis版(ApsaraDB for Redis)、100%相容 Redis 協議的多活資料庫系統。通過資料同步通道，把多個Redis例項組網成1個邏輯上的 Redis 多活例項，多活例項內的所有例項均可讀寫並保持實時資料同步。資料同步通道通過內網打通，具有高可靠、高安全、低延遲的特性。子例項間通過CRDT（Conflict-free Replicated Data Type）機制檢測並解決資料衝突，保障資料最終一致性。Redis全球多活產品輕鬆支援異地多個站點同時對外提供服務的業務場景，助力企業快速複製阿里巴巴異地多活架構。

高可用架構演練之路

程式在執行過程中總會遇到各種各樣的問題，例如程式bug、機器故障、機房斷電起火故障等，業務上要求發生這些故障時要保證資料一致性和業務可用性，所以就有了架構演練之路，即單可用區-同城容災-兩地三中心-異地多活。

由於單可用區架構無法應對機房出現故障，就有了同城容災的架構。同城容災架構由於無法應對地域級別的問題，接著就有了兩地三中心架構。由於許多金融業務要求資料儲存在不同的地域中，同時對故障恢復時間有要求，因此兩地三中心架構就在同城容災基礎上加了一個standby中心，但依舊存在幾個缺陷，即冷備中心不工作，關鍵時刻不敢切的缺陷；冷備中心不工作，成本浪費的缺陷；本質上資料仍然單點寫，資料庫瓶頸無法解的缺陷；資源、容災、擴充套件無法解決的缺陷。

後來有了異地多活架構，它是指所有的中心都提供業務服務，底層的資料能夠相互同步，因此存在著許多優點，例如，所有中心工作，切換有保障；所有中心工作，成本低；彈性伸縮，增加/減少中心個數；故障獨立性導致中心不可用時，隻影響部分使用者。

產品架構

異地多活產品架構圖如上圖所示，它是由雲資料庫Redis版例項、同步通道和通道管理器三部分組成。由於異地多活是由多個Redis例項組成，因此可以實現每個子例項之間實時資料同步、每個子例項資料最終一致、每個子例項均可讀寫等功能。

在異地多活構架中，對Redis進行了aof binlog增加oplog和CRDT策略merge key的改造，其中aof binlog增加oplog中包含gtid和邏輯時鐘資訊，解決了迴圈同步、Exactly-once Apply的問題；CRDT策略merge key中解決了一致性的問題。

異地多活產品具有高可用、高效能、資料最終一致以及功能豐富的特性，具體介紹如下：

• 高可用 高可用是指同步通道支援斷點續傳，它最高可容忍天級別的隔斷，且隔斷之後資料還可以在斷點處繼續同步；同時，同步通道還可以自適應處理子例項異常，例如主備切換、備庫重搭等。
• 高效能 高效能是指它具有非同步複製同步不影響Redis自身讀寫效能，因為它本身定位就具有高效能、高吞吐、低延遲的效能，高吞吐是指它具有標準版Redis使得單向同步鏈路高達10萬TPS以及隨Redis節點數線性擴充套件的叢集版Redis。低延遲是指洲際內地域僅需百毫秒，更厲害的是跨洲際地域僅需 1秒級。
• 最終一致性 爲了解決過去的架構由於非同步同步的邏輯產生的一致性問題，最終引進了CRDT(Conflict-Free Replicated Data Types)策略，它可支援最終一致性的資料型別有 String/Counter、Hash、Set、Zset、Geo、hyperloglog等。
• 功能豐富 異地多活產品增加了支援 Redis 例項型別、同步中的子例項支援變配規格、新增與刪除子例項等新功能，其中支援的 Redis 例項型別包括標準版、叢集版以及讀寫分離版。

業務設計

異地多活業務具有不同的業務有不同的業務設計要求，它必須允許多個地域具有同時修改同一份資料的功能，例如全域性session、全域性PV、使用者收藏夾、購物車、地理位置資訊、收藏夾、歷史搜尋記錄、彈幕、評論等。同時，它還需要做資料切分，要求一份資料只允許有1個寫入點。

多活業務設計的要點有自包含性、鬆耦合性和路由規則一致性，即多活業務設計的所有計算與資料必須在1箇中心內完成；跨單元之間只能進行服務呼叫，不能直接訪問資料庫或其他儲存；路由必須是入口路由或者微服務呼叫路由。

Redis混合儲存產品

Redis混合儲存例項是阿里雲自主研發的完全相容Redis協議和特性的混合儲存產品。通過將部分冷資料儲存到磁碟，在保證絕大部分訪問效能不下降的基礎上，大大降低了使用者成本，並突破了記憶體對Redis單例項資料量的限制。

技術架構

它的資料型別是將熱資料儲存在記憶體裡，將冷資料儲存在磁碟裏面，顧名思義，熱資料就是指頻繁訪問到的資料。因為所有的Redis都會訪問到Keys，相對來說Keys的訪問天生就比Values大許多，因此Redis混合儲存產品是將所有的Keys、常訪問的Values放到記憶體裡儲存，而不經常訪問的Values放到磁碟裡儲存。在業務場景裏面，Keys只佔十幾個位元組，但Values卻佔幾百甚至幾千個位元組，所以將所有的Keys放到記憶體裡對整體效能能夠提高很多。

Redis混合儲存架構如上圖所示，從業務模型來看，我們把Redis混合儲存架構分為三層，第一層是計算層，它包含所有Redis的網路連線、協議解析、定時任務、命令處理、過期、淘汰、同步等業務邏輯；第二層是資料層，它包含熱資料表示、冷熱資料交換、冷資料編解碼；第三層是儲存層，它包含儲存引擎、檔案系統以及硬體管理。

其中，資料層進行冷熱交換是爲了保證相容性，因為所有Redis的業務邏輯是採用主執行緒來處理的，所有實際的IO是由後臺來執行的，進而也不會阻擋主執行緒的執行。在熱資料轉換成冷資料的過程中，資料量小於記憶體時，Redis混合儲存會把所有的Keys和Values放到記憶體裏面，這樣可以達到效能最高。當資料量越來越大時，記憶體裡會出現存不下的現象，這時會按照最近的訪問頻率篩選出一些很少被訪問到的Values，然後由主執行緒生成IO任務，接著後臺的IO執行緒拿到這些任務儲存到磁碟中，最後主線會將這些Values釋放掉。在冷資料轉換成熱資料的過程中，收到使用者請求後，首先判斷任務請求會訪問到哪些Values,然後看這些Values是否都在記憶體裏面，如果部分Values不在，會對這些Values生成IO任務，然後主執行緒將客戶端掛起，接著繼續處理其它客戶端的請求，當此執行緒拿到這些任務後，會把資料從磁碟裏面載入到記憶體裏面，同時通知給主執行緒，主執行緒收到這些通知之後會將掛起的客戶端喚醒繼續處理其他使用者請求。

對於儲存層而言，磁碟上的儲存是跟阿里巴巴的伺服器研發團隊共建的一個使用者態的儲存引擎，稱為FusionEngine。它是由業務定製一個RocksDB，然後通過底層的一個使用者固態的檔案系統來縮短使用者的IO路徑，進而避免了核心的開銷。在業務場景裏面，FusionEngine的效能比過去的檔案系統性能提升了約80%左右，因此整體的Redis混合儲存效能也得到了有效的提升。

產品特性

Redis混合儲存產品的底層實線是支援冷熱資料任意配比的，即可以任意的匹配記憶體佔用多少和磁碟佔用多少，進而在效能和成本上達到一個平衡。在應用中，所有的資料量不能超過記憶體加磁碟的容量。此產品適用於Values比較大的場景，因為Values對效能的影響不是很大，所以也比較適合資料訪問冷熱不均的場景。目前混合儲存開通的區域有華北2（北京）的可用區D、華東1（杭州）的可用區E、華南1（深圳）的可用區C。

應用場景

Redis混合儲存產品應用的場景包含電商類應用、直播類應用、網際網路類應用，對於電商類應用而言，它的活躍商品資料存放到記憶體中，冷門商品資料存放到磁碟中；對於直播類應用而言，它的活躍直播間和熱門直播間的資料存放到記憶體中，下線直播間和冷門直播間的資料存放到磁碟中；對於網際網路類應用而言，它的首頁和熱門貼資料存放到記憶體中，冷門帖子存放到磁碟中。

Redis多執行緒效能增強版

Redis多執行緒效能增強版突破了Redis單執行緒的效能瓶頸，且100%相容原生Redis，業務無需修改任何程式碼。通過將命令解析，讀寫，響應等事件分發給多個IO執行緒併發處理，實現處理效能質的飛躍。

技術架構

原生的Redis是進行序列處理的，當它接收到一個請求時，會嘗試連線讀取到一部分資料，並對這部分資料進行解析，如果解析到一個完整的資料，就會對這個資料進行處理。當這個數據處理完之後，會生成對資料的一個響應，針對這個響應在傳送給客戶端。原生的Redis存在一個缺陷，就是不能做到併發。相對而言，Redis多執行緒做的一個Master-Slave架構就能夠做到併發，它是將Master數據處理完之後，將資料同步到Slave上。

如上圖所示，Redis多執行緒效能增強版是由主執行緒、多個IO執行緒和WORKER執行緒組成，主執行緒主要負責接受連線，建立client，將連線轉發給IO執行緒。IO執行緒負責處理連線的讀寫事件，解析命令，將解析的完整命令轉發給WORKER執行緒處理，傳送response包，負責刪除連線等；WORKER執行緒負責命令的處理，生成客戶端回包，定時器事件的執行等。

線上程間資料在進行交換的過程中，一個IO執行緒在獲取到連線之後，就開始嘗試在這個連線上讀取請求，然後對請求做一個解析，若解析到是一個完整的請求，就會將請求放到佇列裏面。接著，IO執行緒通知WORKER執行緒有新的命令需要處理，這個通知是通過管道來進行的。最後，WORKER執行緒接受到命令後就會對其進行處理，處理完之後會形成對命令的響應，並將響應放到佇列裏面，同樣，WORKER執行緒也會通知IO執行緒。

產品特性

IO執行緒越多，Redis多執行緒的效能越好，但是IO執行緒與Redis多執行緒的效能並不是線性的，當IO執行緒達到一定的數量時，WORKER就會達到一個瓶頸。因此，IO執行緒最多支援多達6個，預設情況下只有一個IO執行緒。另外需要注意的是，執行緒數個數跟規格是繫結的，一旦選定例項建立完畢後無法動態修改，如需修改，就需要通過升級規格的方式完成。

Redis多執行緒並不是在所有的場景中都適用，Redis多執行緒只適用於主從版無法滿足效能需求時、叢集版shard節點成為效能瓶頸時、讀寫分離版本有熱寫瓶時以及同步延遲等問題時。

應用場景

Redis多執行緒效能增強版主要應用在電商類應用、直播類應用中，對於電商類應用而言，適用於秒殺場景和庫存計數；對於直播類應用而言，主要適用於熱點直播間和明星大V的直播。

end返回搜狐，檢視更多

責任編輯：