基于redis分布式緩存實現(xiàn)

第一：Redis 是什么？

Redis是基于內存、可持久化的日志型、Key-Value數(shù)據(jù)庫 高性能存儲系統(tǒng)，并提供多種語言的API.

第二：出現(xiàn)背景

• 數(shù)據(jù)結構(Data Structure)需求越來越多, 但memcache中沒有, 影響開發(fā)效率

• 性能需求, 隨著讀操作的量的上升需要解決，經歷的過程有: 
  數(shù)據(jù)庫讀寫分離(M/S)–>數(shù)據(jù)庫使用多個Slave–>增加Cache (memcache)–>轉到Redis

• 解決寫的問題： 
  水平拆分，對表的拆分，將有的用戶放在這個表，有的用戶放在另外一個表；

• 可靠性需求 
  Cache的"雪崩"問題讓人糾結 
  Cache面臨著快速恢復的挑戰(zhàn)

• 開發(fā)成本需求 
  Cache和DB的一致性維護成本越來越高(先清理DB, 再清理緩存, 不行啊, 太慢了!) 
  開發(fā)需要跟上不斷涌入的產品需求 
  硬件成本最貴的就是數(shù)據(jù)庫層面的機器，基本上比前端的機器要貴幾倍，主要是IO密集型，很耗硬件；

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

基于以上考慮， 選擇了Redis

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

Redis簡介

1. 支持5種數(shù)據(jù)結構

支持strings, hashes, lists, sets, sorted sets 
string是很好的存儲方式，用來做計數(shù)存儲。sets用于建立索引庫非常棒；

2. K-V 存儲 vs K-V 緩存

新浪微博目前使用的98%都是持久化的應用，2%的是緩存，用到了600+服務器 
Redis中持久化的應用和非持久化的方式不會差別很大： 
非持久化的為8-9萬tps，那么持久化在7-8萬tps左右； 
當使用持久化時，需要考慮到持久化和寫性能的配比，也就是要考慮redis使用的內存大小和硬盤寫的速率的比例計算；

3. 社區(qū)活躍

Redis目前有3萬多行代碼, 代碼寫的精簡，有很多巧妙的實現(xiàn)，作者有技術潔癖 
Redis的社區(qū)活躍度很高，這是衡量開源軟件質量的重要指標，開源軟件的初期一般都沒有商業(yè)技術服務支持，如果沒有活躍社區(qū)做支撐，一旦發(fā)生問題都無處求救；

Redis基本原理

redis持久化(aof) append online file： 
寫log(aof), 到一定程度再和內存合并. 追加再追加, 順序寫磁盤, 對性能影響非常小

1. 單實例單進程

Redis使用的是單進程，所以在配置時，一個實例只會用到一個CPU； 
在配置時，如果需要讓CPU使用率最大化，可以配置Redis實例數(shù)對應CPU數(shù), Redis實例數(shù)對應端口數(shù)(8核Cpu, 8個實例, 8個端口), 以提高并發(fā): 
單機測試時, 單條數(shù)據(jù)在200字節(jié), 測試的結果為8~9萬tps；

2. Replication

過程: 數(shù)據(jù)寫到master–>master存儲到slave的rdb中–>slave加載rdb到內存。 
存儲點(save point): 當網絡中斷了, 連上之后, 繼續(xù)傳. 
Master-slave下第一次同步是全傳，后面是增量同步；、

3. 數(shù)據(jù)一致性

長期運行后多個結點之間存在不一致的可能性； 
開發(fā)兩個工具程序： 
1.對于數(shù)據(jù)量大的數(shù)據(jù)，會周期性的全量檢查； 
2.實時的檢查增量數(shù)據(jù)，是否具有一致性；

對于主庫未及時同步從庫導致的不一致，稱之為延時問題； 
對于一致性要求不是那么嚴格的場景，我們只需要要保證最終一致性即可； 
對于延時問題，需要根據(jù)業(yè)務場景特點分析，從應用層面增加策略來解決這個問題； 
例如： 
1.新注冊的用戶，必須先查詢主庫； 
2.注冊成功之后，需要等待3s之后跳轉，后臺此時就是在做數(shù)據(jù)同步。

第四：分布式緩存的架構設計

1.架構設計

由于redis是單點，項目中需要使用，必須自己實現(xiàn)分布式。基本架構圖如下所示：

2.分布式實現(xiàn)

通過key做一致性哈希，實現(xiàn)key對應redis結點的分布。

一致性哈希的實現(xiàn)：

l        hash值計算：通過支持MD5與MurmurHash兩種計算方式，默認是采用MurmurHash，高效的hash計算.

l        一致性的實現(xiàn)：通過java的TreeMap來模擬環(huán)狀結構，實現(xiàn)均勻分布

3.client的選擇

對于jedis修改的主要是分區(qū)模塊的修改，使其支持了跟據(jù)BufferKey進行分區(qū)，跟據(jù)不同的redis結點信息，可以初始化不同的 ShardInfo，同時也修改了JedisPool的底層實現(xiàn)，使其連接pool池支持跟據(jù)key,value的構造方法，跟據(jù)不同 ShardInfos，創(chuàng)建不同的jedis連接客戶端，達到分區(qū)的效果，供應用層調用

4.模塊的說明

l        臟數(shù)據(jù)處理模塊，處理失敗執(zhí)行的緩存操作。

l        屏蔽監(jiān)控模塊，對于jedis操作的異常監(jiān)控，當某結點出現(xiàn)異?？煽刂苧edis結點的切除等操作。

整個分布式模塊通過hornetq，來切除異常redis結點。對于新結點的增加，也可以通過reload方法實現(xiàn)增加。（此模塊對于新增結點也可以很方便實現(xiàn)）

對于以上分布式架構的實現(xiàn)滿足了項目的需求。另外使用中對于一些比較重要用途的緩存數(shù)據(jù)可以單獨設置一些redis結點，設定特定的優(yōu)先級。另外對 于緩存接口的設計，也可以跟據(jù)需求，實現(xiàn)基本接口與一些特殊邏輯接口。對于cas相關操作，以及一些事物操作可以通過其watch機制來實現(xiàn)。

聲明：所有博客服務于分布式框架，作為框架的技術支持及說明，框架面向企業(yè)，是大型互聯(lián)網分布式企業(yè)架構，后期會介紹linux上部署高可用集群項目。

歡迎大家一起學習研究相關技術，源碼獲取請加求求（企鵝）: 2042849237

更多詳細源碼參考來源：http://×××/technology