《千億級高性能 KV 存儲生態圈》要點：
本文介紹了千億級高性能 KV 存儲生態圈，希望對您有用。如果有疑問，可以聯系我們。

本文源自4月20日『高效開發運維』微信群的在線分享,分享者為360Web平臺部DBA團隊的張恒,本文infoQ的『高效開發運維』公眾號首發,已授權轉載

一、背景介紹

隨著360公司業務發展,業務使用kv存儲的需求越來越大.為了應對kv存儲需求爆發式的增長和多使用場景的需求,360web平臺部致力于打造一個全方位,適用于多場景需求的kv解決方案.目前,我們線上大規模使用的kv存儲有Redis,Redis cluster以及Pika.

為什么說是爆發式的需求增長呢?早在2015年9月份,公司Redis的日訪問量還處于800億,到了2016年第三季度日訪問量已經突破2500億,2017年第一季度日訪問量已經接近4000億.短短的一年半時間,日訪問量增長了5倍.下面給大家分別簡單介紹一下Redis,Redis Cluster以及Pika的特點和使用場景.

二、kv存儲之Redis

1、Redis介紹

Redis做為大家熟知的開源內存數據庫,在很多項目中被廣泛的使用.它支持String、Hash、List、Set、Zset、Geo、Hyperloglogs等多數據結構.同時也支持主從復制、Lua腳本、事務、數據持久化、高可用和集群化等等

2、Redis特性

1)高性能：Redis雖然是單線程的,但是它同樣擁有著超高的性能.我們線上的普通PC Server上,經過測試,每秒請求數OPS能夠達到10w左右.

2)多樣化數據結構：Redis支持String、Hash、List、Set、Zset、Geo等多數據結構.

3)持久化：RDB持久化：快照式持久化方式,將內存中的全量數據dump到磁盤.它的優勢是加載速度比AOF快,劣勢是快照式的全量備份,沒有增量數據,造成數據丟失.

AOF持久化：AOF記錄Redis執行的所有寫操作命令.恢復數據的過程相當于回放這些寫操作.使用AOF的持久化方式,優勢是有靈活的刷盤策略,保證數據的安全性.劣勢是AOF文件體積比RDB大,占用磁盤多,數據加載到內存的數據慢.

4)多重數據刪除策略：

①惰性刪除：當讀/寫一個已經過期的key時,會觸發惰性刪除策略,刪除掉這個過期key.

②定期刪除：由于惰性刪除策略無法保證冷數據被及時刪掉,所以Redis會定期主動淘汰一批已過期的key.

③主動刪除：當前已用內存超過maxmemory限定時,觸發主動清理策略,該策略由啟動參數的配置決定,可配置參數及說明如下：

• volatile-lru：從已設置過期時間的樣本中根據LRU算法刪除數據 (redis3.0之前的默認策略)
• volatile-ttl：從已設置過期時間的樣本中挑選過期時間最小的數據刪除
• volatile-random：從已設置過期時間的樣本中隨機選擇數據刪除
• allkeys-lru：從樣本中根據LRU算法刪除數據
• allkeys-random：從樣本中任意選擇刪除數據
• noenviction：禁止從內存中刪除數據 (從redis3.0 開始默認策略)

maxmemory-samples 刪除數據的抽樣樣本數,redis3.0之前默認樣本數為3,redis3.0開始默認樣本數為5,該參數設置過小會導致主動刪除策略不準確,過大會消耗多余的cpu.

5)高可用：Redis自身帶有哨兵的組件,可以監控Redis主從的運行狀態和自動的故障切換,實現Redis的高可用.

3、Redis使用場景

一般場景：OPS < 10W,數據量較小

進階場景：單點寫入可以支撐,但讀取量巨大,可以采用讀寫分離,1主多從的方案；

寫入讀取量都很大,單點寫入無法支撐,可以采用Hash分片方式.

但是,無論數讀寫分離的方式還是Hash分片的方式,在的Redis的架構中沒有引入中間件或者更加智能的驅動的情況下,都需要從代碼上去保證,這一定程度上增加了開發人員的代碼復雜度.同時隨著業務的增長,擴展性也較差.那么如何更加理想的去解決這個問題,使用Redis Cluster會是一個更加簡潔有效的方案.

三、kv存儲之Redis Cluster

1、Redis Cluster介紹

Redis Cluster 是一個分布式、無中心節點的、高可用、可線性擴展的內存數據庫,Redis Cluster的功能是普通單機 Redis 的功能的一個子集.Redis Cluster為了保證一致性而犧牲了一部分容錯性： 系統會在保證對網絡斷線和節點失效具有有限抵抗力的前提下, 盡可能地保持數據的一致性.

2、Redis Cluster重要概念：

①hash slots——哈希槽

Redis 集群沒有使用一致性hash,而是引入了哈希槽(hash slot)的概念.Redis 集群一共有16384個hash slot,集群使用CRC16校驗后對16384取模來計算鍵key屬于哪個槽.

②cluster node——集群節點

集群中的每個主節點負責處理16384個hash slot中的一部分.每個node的hash slot數量可以靈活手工調整.

③cluster map——集群信息表

集群中的每個節點都記錄整個集群的Cluster map信息,集群信息包括每個節點的唯一id號,ip地址,port端口號,role 在集群中的角色,主節點負責的hash slot的范圍,節點狀態等.節點之間通過Gossip協議進行通信,傳播集群信息,并發現新節點向其他節點發送ping包,檢查目標節點是否正常運行.

3、Redis Cluster架構??

4、Redis Cluster數據路由

①client執行命令,計算key對應的hash slots

②根據本地緩存的cluster map信息,連接負責該hash slots的數據節點獲取數據

如果slot不在當前連接的節點,返回moved錯誤,重定向客戶端到新的目的服務器上獲取數據,并更新client本地緩存的cluster map

如果slot在當前節點且key存在,則執行操作結果給客戶端

如果slot遷出中,返回ask錯誤,重定向客戶端到遷移的目的服務器上獲取數據

5、使用場景??

大容量、高并發、可線性擴展

剛才僅僅是對Redis Cluster做了簡單的介紹,關于集群的創建、數據的遷移、集群的擴容和縮容、hash slots重分布、集群的reblance等日常操作,使用Redis Cluster中遇到的問題以及在改進smart driver道路上解決的問題等等,如果有同學感興趣的話,歡迎私下共同交流學習.

四、kv存儲之Pika

1、Pika是什么??

Pika 是DBA需求,基礎架構組開發的大容量、高性能、持久化、支持多數據結構的類Redis存儲系統,目前已經開源,最新版本為Pika 2.2版本.它所使用的nemo引擎本質上是對Rocksdb的改造和封裝,使其支持多數據結構的存儲,并在nemo引擎之上封裝redis接口,使其完全支持Redis協議.Pika兼容string、hash、list、zset、set等多數據結構,使用磁盤而非內存存儲數據解決了Redis由于存儲數據量巨大而導致內存不夠用的容量瓶頸.

2、Pika PK Redis??

?Pika PK Redis之優勢：

①大容量存儲：Pika數據容量受制于磁盤,最大使用空間等于磁盤空間的大小,而Redis數據容量受限于主機內存

②秒級啟動：Pika 在寫入的時候, 數據是落盤的,Pika 重啟不用加載所有數據到內存,不需要進行回放數據操作.而Redis啟動需要將所有數據從磁盤加載到內存,隨著容量增加,啟動時間遞增到分鐘級甚至更長時間.

③秒級備份：Pika的備份方式,是將所有數據文件做快照.Redis無論是用RDB還是AOF的方式來實現數據備份的目的,都需要將全量的數據寫入到磁盤,備份速度慢.

④秒刪數據：Pika的數據刪除是標記刪除,Pika Key的元信息上有版本信息,表示當前key的有效版本,已刪除的數據在Compact合并數據的過程中刪除.而單線程的Redis在大量刪除數據時候會影響線上業務,刪除大對象會阻塞住Redis的主線程,刪除速度慢.

⑤同步續傳：Pika寫入數據會有write2file日志文件,只要該文件未刪除,無需全量同步數據,均可斷點續傳數據.而Redis一旦主從同步緩沖區被循環重寫,容易導致全量數據重傳.

⑥高壓縮比：Pika存儲的數據默認會被壓縮,相對于Redis,Pika有5~10倍的壓縮比.所以Redis的數據存儲到Pika,數據體積會小很多.

⑦高性價比：相對于Redis使用昂貴的內存成本,Pika使用磁盤存儲數據,性價比極高

Pika PK Redis之劣勢：

①讀寫性能較弱：Pika是持久化的,基于磁盤的kv存儲.而Redis是內存數據庫.雖然pika是多線程的,但是在大多場景下,性能還是略遜色于Redis

②多數據結構性能損耗：Pika底層使用Rocksdb存儲引擎,它并不支持多數據結構,Pika在Rocksdb的上層進行了改造和封裝,實現了對多數據結構的支持.同時在性能上,會有一些損耗.

③兼容大部分Reids接口：Pika兼容了90% Redis接口,使其易用性得到大大提升.但是目前還沒有做到完全兼容.

3、Pika整體架構??

4、Pika使用場景??

①業務量并沒有那么大,使用Redis內存成本太高

②數據量很大,使用Redis單個服務器內存無法承載

③經常出現時間復雜度很高的請求讓Redis間歇性阻塞

④讀寫分離且不希望故障切主后影到從庫,能夠快速切換

5、Pika使用現狀?

①內部：目前Pika已經在360內部的各個業務線廣泛使用,共計覆蓋43個主業務線和76個子業務線,近千億的日訪問量和數十T的數據規模,節約了大量昂貴的服務器內存,降低了使用成本.

②社區：在業內,據不完全統計,很多著名互聯網公司也使用了Pika,例如新浪微博、美團、58同城、迅雷、萬達電商、環信…………

6、Redis如何遷移到Pika?

那么,在適用于 Pika的業務場景下,我們如何將Redis數據遷移到Pika呢?

Pika自帶的工具集,其中aof_to_pika這個工具可以幫助我們完成很平滑的這個任務.由于該工具依賴于AOF來發送數據,所以原Redis必須要開啟AOF,并關閉AOF重寫的策略.aof_to_pika通過reader線程讀取aof文件中的內容,根據設定的單次發送長度拼裝成數據塊,將要發送的數據庫加入隊列.同時sender線程不斷的從隊列中讀取數據發送到目的Pika完成數據的重放.

除了Redis的遷移工具之外.考慮有同學可能也使用到了ssdb,那么Pika也很貼心的提供了從ssdb遷移數據到Pika的工具ssdb_to_pika.

五、多場景的業務需求

最后,針對于業務多變的kv存儲需求,常常有兩個重點是我們最為關注的,一個是數據量,另一個是訪問量.圍繞著數據量和訪問量的大小,往往決定了我們是使用Redis、Redis Cluseter or Pika.

六、QA

Q1：Pika支持集群嗎?

A1：Pika目前主持主從結構,也支持codis.自身目前還不支持分布式的集群化,我們還在做多數據結構集群化的調研.

Q2：Pika 與Redis什么關系?替代嗎還是補充?看著像是補充. Pika 如果是替代Redis,那使用磁盤如何保證高性能.

A2: Pika與Redis是使用場景上互相補充的關系.目前線上的Pika機器都使用的ssd,一般場景下ops在5w以內場景都能輕松應對.

Q3：Redis持久化方式如何選取?還是不做持久化?

A3：持久化多數場景下選擇AOF方式,做不做持久化取決于業務對數據安全性的要求,畢竟純緩存的數據一旦服務器宕機或者數據庫崩潰,數據都會全部丟失.

Q4 : 張老師你好,Pika掛固態硬盤讀寫性能是否可以pk Redis?360 業務有這樣應用嗎?

A4:目前360內部使用Pika的應用,全部使用的都是SSD硬盤.

Q5 : Pika 里邊 zset 是落地的么,zset是怎么實現的呢? 對scan 類的命令支持怎樣?Pika 性能如何?

A5: 是落地的,大致原理是將一條key-score-members轉換成3條rocksdb的kv來存儲.scan是都支持的,和Redis一樣.Pika的性能我們認為還不錯,能夠滿足多數場景,但是建議大家要部署在SSD上,和內存比SSD還是便宜太多的,另外非常歡迎大家用測試比較Pika與相似項目的性能!

Q6 : 老師,像類似于fastdfs也是存儲在硬盤的,請問Pika與他們在使用場景上有什么不同呢?

A6: 就我個人知識了解,fastdfs是一個分布式文件系統,存儲小文件、圖片等,與Pika面向的場景不一樣,Pika是為了解決Redis單機內存不足而設計的一個在線數據庫,當然,只要單機磁盤容量夠,也是可以存儲二進制文件到pika的.

Q7: Pika和Aerospike相比有哪些優勢呢?Aerospike開源版本內存加持久化后,執行刪除操作,重啟后刪除的數據會重新從磁盤加載,Pika有沒有這個弊病?

A7: Pika的設計初衷其實就是為滿足業務在Redis存儲中,因為內存不足而造成業務損失,所以,我們的Pika的命令基本與Redis保持一致,并且client也是復用Redis的,這樣,業務從Redis切換到Pika,無任何復雜度,這一點,我個人看Aerospike是比不了的.另外,Pika是不會加載刪除數據.

Q8：redis 中熱鍵大鍵如何處理?發現大部分故障都源于此

A8: 熱點數據需要進行業務邏輯上的拆分或者多級緩存分擔壓力.我們線上也因為大鍵造成了一些困擾,例如：網卡帶寬被打死、del大鍵造成Redis堵塞等,從Redis本身,確實沒有太好的辦法來解決,只能從業務層面分析出現大鍵的原因,做出響應的對策,例如：對大鍵進行壓縮存儲、或者存儲大鍵到有多線程處理的pika中等等.

文章來自微信公眾號：HULK一線技術雜談

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/4182.html