1. 程式人生 > >基於redis分散式快取實現(新浪微博案例)

基於redis分散式快取實現(新浪微博案例)

第一:Redis 是什麼?

Redis是基於記憶體、可持久化的日誌型、Key-Value資料庫 高效能儲存系統,並提供多種語言的API.

第二:出現背景

  • 資料結構(Data Structure)需求越來越多, 但memcache中沒有, 影響開發效率
  • 效能需求, 隨著讀操作的量的上升需要解決,經歷的過程有: 
    資料庫讀寫分離(M/S)–>資料庫使用多個Slave–>增加Cache (memcache)–>轉到Redis
  • 解決寫的問題: 
    水平拆分,對錶的拆分,將有的使用者放在這個表,有的使用者放在另外一個表;
  • 可靠性需求 
    Cache的"雪崩"問題讓人糾結 
    Cache面臨著快速恢復的挑戰

  • 開發成本需求 
    Cache和DB的一致性維護成本越來越高(先清理DB, 再清理快取, 不行啊, 太慢了!) 
    開發需要跟上不斷湧入的產品需求 
    硬體成本最貴的就是資料庫層面的機器,基本上比前端的機器要貴幾倍,主要是IO密集型,很耗硬體;

  • 維護性複雜 
    一致性維護成本越來越高; 
    BerkeleyDB使用B樹,會一直寫新的,內部不會有檔案重新組織;這樣會導致檔案越來越大;大的時候需要進行檔案歸檔,歸檔的操作要定期做; 
    這樣,就需要有一定的down time;

基於以上考慮, 選擇了Redis

第三:Redis 在新浪微博中的應用

Redis簡介

1. 支援5種資料結構

支援strings, hashes, lists, sets, sorted sets 
string是很好的儲存方式,用來做計數儲存。sets用於建立索引庫非常棒;

2. K-V 儲存 vs K-V 快取

新浪微博目前使用的98%都是持久化的應用,2%的是快取,用到了600+伺服器 
Redis中持久化的應用和非持久化的方式不會差別很大: 
非持久化的為8-9萬tps,那麼持久化在7-8萬tps左右; 
當使用持久化時,需要考慮到持久化和寫效能的配比,也就是要考慮redis使用的記憶體大小和硬碟寫的速率的比例計算;

3. 社群活躍

Redis目前有3萬多行程式碼, 程式碼寫的精簡,有很多巧妙的實現,作者有技術潔癖 
Redis的社群活躍度很高,這是衡量開源軟體質量的重要指標,開源軟體的初期一般都沒有商業技術服務支援,如果沒有活躍社群做支撐,一旦發生問題都無處求救;

Redis基本原理

redis持久化(aof) append online file: 
寫log(aof), 到一定程度再和記憶體合併. 追加再追加, 順序寫磁碟, 對效能影響非常小

1. 單例項單程序

Redis使用的是單程序,所以在配置時,一個例項只會用到一個CPU; 
在配置時,如果需要讓CPU使用率最大化,可以配置Redis例項數對應CPU數, Redis例項數對應埠數(8核Cpu, 8個例項, 8個埠), 以提高併發: 
單機測試時, 單條資料在200位元組, 測試的結果為8~9萬tps;

2. Replication

過程: 資料寫到master–>master儲存到slave的rdb中–>slave載入rdb到記憶體。 
儲存點(save point): 當網路中斷了, 連上之後, 繼續傳. 
Master-slave下第一次同步是全傳,後面是增量同步;、

3. 資料一致性

長期執行後多個結點之間存在不一致的可能性; 
開發兩個工具程式: 
1.對於資料量大的資料,會週期性的全量檢查; 
2.實時的檢查增量資料,是否具有一致性;

對於主庫未及時同步從庫導致的不一致,稱之為延時問題; 
對於一致性要求不是那麼嚴格的場景,我們只需要要保證最終一致性即可; 
對於延時問題,需要根據業務場景特點分析,從應用層面增加策略來解決這個問題; 
例如: 
1.新註冊的使用者,必須先查詢主庫; 
2.註冊成功之後,需要等待3s之後跳轉,後臺此時就是在做資料同步。

 

第四:分散式快取的架構設計

1.架構設計

由於redis是單點,專案中需要使用,必須自己實現分散式。基本架構圖如下所示:

 

 

2.分散式實現

通過key做一致性雜湊,實現key對應redis結點的分佈。

一致性雜湊的實現:

l        hash值計算:通過支援MD5與MurmurHash兩種計算方式,預設是採用MurmurHash,高效的hash計算。

l        一致性的實現:通過java的TreeMap來模擬環狀結構,實現均勻分佈

3.client的選擇

對於jedis修改的主要是分割槽模組的修改,使其支援了跟據BufferKey進行分割槽,跟據不同的redis結點資訊,可以初始化不同的ShardInfo,同時也修改了JedisPool的底層實現,使其連線pool池支援跟據key,value的構造方法,跟據不同ShardInfos,建立不同的jedis連線客戶端,達到分割槽的效果,供應用層呼叫

4.模組的說明

l        髒資料處理模組,處理失敗執行的快取操作。

l        遮蔽監控模組,對於jedis操作的異常監控,當某結點出現異常可控制redis結點的切除等操作。

整個分散式模組通過hornetq,來切除異常redis結點。對於新結點的增加,也可以通過reload方法實現增加。(此模組對於新增結點也可以很方便實現)

對於以上分散式架構的實現滿足了專案的需求。另外使用中對於一些比較重要用途的快取資料可以單獨設定一些redis結點,設定特定的優先順序。另外對於快取介面的設計,也可以跟據需求,實現基本介面與一些特殊邏輯介面。對於cas相關操作,以及一些事物操作可以通過其watch機制來實現。(參考我以前寫的redis事物介紹

 

以上是基於redis分散式架構的介紹!但是應用中讀寫都是在一起的。相關寫是在應用操作後flush或者update的,有一定的耦合。為了使讀寫分離,以及快取模組跟應用的耦合更小,考慮使用mysql binlog來重新整理快取。以下是基於binlog重新整理可性行分析以及實現過程中需要注意的地方。

 

tsk:

http://baike.baidu.com/view/4595959.htm?fr=aladdin

http://blog.me115.com/2013/12/452

http://blog.csdn.net/vhomes/article/details/8194670

歡迎關注技術公眾號:架構師成長營