第一：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機制來實現。
宣告：所有部落格服務於分散式框架，作為框架的技術支援及說明，框架面向企業，是大型網際網路分散式企業架構，後期會介紹linux上部署高可用叢集專案。
歡迎大家一起學習研究相關技術
願意瞭解框架技術或者原始碼的朋友直接求求交流分享技術：2042849237
Redis,Redis分散式,Redis分散式快取,Redis儲存系統,SpringMVC+Mybatis