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之後跳轉，後臺此時就是在做資料同步。
新浪Redis使用歷程
2009年, 使用memcache(用於非持久化內容), memcacheDB(用於持久化+計數),
memcacheDB是新浪在memcache的基礎上，使用BerkeleyDB作為資料持久化的儲存實現；
1. 面臨的問題
基於以上考慮， 選擇了Redis
2. 尋找開源軟體的方式及評判標準
Redis應用場景
1. 業務使用方式
上述四種, 從精細化控制方面，hash sets和string(counter)推薦使用, sort sets和lists(queue)不推薦使用
還可通過二次開發，進行精簡。比如: 儲存字元改為儲存整形, 16億資料, 只需要16G記憶體
儲存型別儲存在3種以內，建議不要超過3種；
將memcache +myaql 替換為Redis：
Redis作為儲存並提供查詢，後臺不再使用mysql，解決資料多份之間的一致性問題；
2. 對大資料表的儲存
（eg：140字微博的儲存）
一個庫就存唯一性id和140個字；
改進的3個步驟:
1）發現現有系統存在問題;
2）發現了新東西, 怎麼看怎麼好, 全面轉向新東西;
3）理性迴歸, 判斷哪些適合新東西, 哪些不適合, 不合適的回遷到老系統
3. 一些技巧
遇到的問題及解決辦法
(注意: 都是量特別大時候會出現的, 量小了怎麼都好說)
1.Problem: Replication中斷後, 重發-->網路突發流量
Solution: 重寫Replication程式碼, rdb+aof(滾動)
2.Problem: 容量問題
Solution: 容量規劃和M/S的sharding功能(share nothing, 抽象出來的資料物件之間的關聯資料很小)
增加一些配置, 分流, 比如: 1,2,3,4, 機器1處理%2=1的, 機器2處理%2=0的.
低於記憶體的1/2使用量, 否則就擴容（建議Redis例項使用的資料，最大不要超過記憶體的80%）
我們線上96G/128G記憶體伺服器不建議單例項容量大於20/30G。
微博應用中單表資料最高的有2T的資料，不過應用起來已經有些力不從心；
每個的埠不要超過20G；測試磁碟做save所需要的時間，需要多長時間能夠全部寫入；記憶體越大，寫的時間也就越長；
單例項記憶體容量較大後，直接帶來的問題就是故障恢復或者Rebuild從庫的時候時間較長，對於普通硬碟的載入速度而言，我們的經驗一般是redis載入1G需要1分鐘；（載入的速度依賴於資料量的大小和資料的複雜度）
Redis rewrite aof和save rdb時，將會帶來非常大且長的系統壓力，並佔用額外記憶體，很可能導致系統記憶體不足等嚴重影響效能的線上故障。
reblance: 現有資料按照上述配置重新分發。
後面使用中間層，路由HA；
注：目前官方也正在做這個事，Redis Cluster，解決HA問題；
3. Problem: bgsave or bgwriteaof的冰晶問題
Solution: 磁碟效能規劃和限制寫入的速度, 比如: 規定磁碟以200M/s的速度寫入, 細水長流, 即使到來大量資料. 但是要注意寫入速度要滿足兩個客觀限制:
符合磁碟速度
符合時間限制(保證在高峰到來之前, 就得寫完)
4.Problem: 運維問題
1）Inner Crontab: 把Crontab遷移到Redis內部, 減少遷移時候的壓力
本機多埠避免同時做 - 能做到
同一業務多埠(分佈在多機上), 避免同時做 - 做不到
2）動態升級: 先載入.so檔案, 再管理配置, 切換到新程式碼上(Config set命令)
把對redis改進的東西都打包成lib.so檔案，這樣能夠支援動態升級
自己改的時候要考慮社群的升級。當社群有新的版本，有很好用的新功能時，要能很容易的與我們改進後的版本很好的merge；
升級的前提條件: 模組化, 以模組為單位升級
載入時間取決於兩個方面: 資料大小, 資料結構複雜度. 一般, 40G資料耗時40分鐘
分散式系統的兩個核心問題: A.路由問題 B.HA問題
運維不能只講資料備份，還得考慮資料恢復所需要的時間；
增加許可權認證(管理員才有許可權)eg：flashall 許可權認證，得有密碼才能做；
當然，高速資料互動一般都不會在每次都進行許可權認證，通用的處理策略是第一次認證，後期都不用再認證；
控制hash策略(沒有key, 就找不到value; 不知道hash策略, 就無法得到key)
4）Config Dump:
記憶體中的配置項動態修改過, 按照一定策略寫入到磁碟中(Redis已支援)
5）bgsave帶來aof寫入很慢:
fdatasync在做bgsave時, 不做sync aof(會有資料出入)
6）成本問題: (22T記憶體, 有10T用來計數)
Redisscounter(16億資料佔用16G記憶體) - 全部變為整型儲存, 其餘(字串等)全不要
Redis+SSD(counterService計數服務)
順序自增, table按照順序寫, 寫滿10個table就自動落地(到SSD)
儲存分級: 記憶體分配問題, 10K和100K寫到一塊, 會有碎片. Sina已經優化到浪費只佔5%以內(已經很好了!)
5.Problem: 分散式問題
1.Config Server: 名稱空間, 特別大的告訴訪問, 都不適合用代理, 因為代理降低速度, 但是, Sina用了(單機多埠, Redis Cluster, sentinel)
Config Server放到Zookeeper上
最前面是命名服務，後面跟的是無狀態的twmemproxy（twitter的改進的，用C寫的） ,後面才是redis；
2.twmemproxy
應用不必關心連線失敗, 由代理負責重連
把Hash演算法放到代理商
代理後邊的升級, 前端不關心, 解決了HA的問題
無狀態, 多臺代理無所謂
3.AS --> Proxy -->Redis
4.Sina的Redis都是單機版, 而Redis-Cluster互動過於複雜，沒有使用
做HA的話，一定要配合監控來做，如果掛了之後，後續該如何做；
並不是追求單機效能，而是叢集的吞吐量，從而可以支援無線擴充套件；
更多Java學習資料獲取方式：轉發文章+關注私信【資料】即可獲得歡迎關注！持續推送有趣有料的技術文章~