基於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簡介

支持5種數據結構

支持strings, hashes, lists, sets, sorted sets

string是很好的存儲方式，用來做計數存儲。sets用於建立索引庫非常棒;

K-V 存儲 vs K-V 緩存

新浪微博目前使用的98%都是持久化的應用，2%的是緩存，用到了600 伺服器

Redis中持久化的應用和非持久化的方式不會差別很大：

非持久化的為8-9萬tps，那麼持久化在7-8萬tps左右;

當使用持久化時，需要考慮到持久化和寫性能的配比，也就是要考慮redis使用的內存大小和硬碟寫的速率的比例計算;

社區活躍

Redis目前有3萬多行代碼, 代碼寫的精簡，有很多巧妙的實現，作者有技術潔癖

Redis的社區活躍度很高，這是衡量開源軟體質量的重要指標，開源軟體的初期一般都沒有商業技術服務支持，如果沒有活躍社區做支撐，一旦發生問題都無處求救;

Redis基本原理

redis持久化(aof) append online file：

寫log(aof), 到一定程度再和內存合併. 追加再追加, 順序寫磁碟, 對性能影響非常小

單實例單進程

Redis使用的是單進程，所以在配置時，一個實例只會用到一個CPU;

在配置時，如果需要讓CPU使用率最大化，可以配置Redis實例數對應CPU數, Redis實例數對應埠數(8核Cpu, 8個實例, 8個埠), 以提高並發:

單機測試時, 單條數據在200位元組, 測試的結果為8~9萬tps;

Replication

過程: 數據寫到master–master存儲到slave的rdb中–slave載入rdb到內存。

存儲點(save point): 當網路中斷了, 連上之後, 繼續傳.

Master-slave下第一次同步是全傳，後面是增量同步;、

數據一致性

長期運行後多個結點之間存在不一致的可能性;

開發兩個工具程序：

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機制來實現。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！