Redis簡介

 

　　1.支持5種數據結構

　　支持strings, hashes, lists, sets, sorted setsstring是很好的存儲方式，用來做計數存儲。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應用

 

　　1.業務使用方式

　　hash sets: 關注列表, 粉絲列表, 雙向關注列表(key-value(field), 排序)

　　string(counter): 微博數, 粉絲數,(避免了select count(*) from ...)

　　sort sets(自動排序): TopN, 熱門微博等, 自動排序

　　lists(queue): push/sub提醒

　　上述四種, 從精細化控制方面，hash sets和string(counter)推薦使用, sort sets和lists(queue)不推薦使用還可通過二次開發，進行精簡。比如: 存儲字符改為存儲整形, 16億數據, 只需要16G內存存儲類型保存在3種以內，建議不要超過3種。

　　將memcache +myaql 替換為Redis：Redis作為存儲并提供查詢，后臺不再使用mysql，解決數據多份之間的一致性問題。

 

　　2.對大數據表的存儲

　　一個庫就存唯一性id和140個字;另一個庫存id和用戶名，發布日期、點擊數等信息，用來計算、排序等，等計算出最后需要展示的數據時再到第一個庫中提取微博內容。

　　改進的3個步驟:1)發現現有系統存在問題;2)發現了新東西, 怎么看怎么好, 全面轉向新東西;3)理性回歸, 判斷哪些適合新東西, 哪些不適合, 不合適的回遷到老系統。

 

　　3.一些技巧分享

　　很多應用, 可以承受數據庫連接失敗, 但不能承受處理慢。一份數據, 多份索引。解決IO瓶頸的唯一途徑: 用內存。在數據量變化不大的情況下，優先選用Redis數據庫。

 

　　常見問題及解決辦法

 

　　1.Problem: Replication中斷后, 重發-->網絡突發流量

　　Solution: 重寫Replication代碼, rdb+aof(滾動)

 

　　2.Problem: 容量問題

　　Solution: 容量規劃和M/S的sharding功能增加一些配置, 分流, 比如: 四臺機器，機器1處理%2=1的, 機器2處理%2=0的.低于內存的1/2使用量, 否則就擴容。我們線上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: 運維問題

　　Inner Crontab: 能做到把Crontab遷移到Redis內部, 減少遷移時候的壓力本機多端口避免同時做，做不到同一業務多端口(分布在多機上), 避免同時做。

　　動態升級: 先加載.so文件, 再管理配置, 切換到新代碼上把對redis改進的東西都打包成lib.so文件，這樣能夠支持動態升級自己改的時候要考慮社區的升級。當社區有新的版本，有很好用的新功能時，要能很容易的與我們改進后的版本很好的merge。升級的前提條件是模塊化。以模塊為單位升級加載時間取決于兩個方面: 數據大小，數據結構復雜度。 一般, 40G數據耗時40分鐘分布式系統的兩個核心問題:一是路由問題，二是HA問題。

　　危險命令的處理: 比如: fresh all刪除全部數據, 得進行控制運維不能只講數據備份，還得考慮數據恢復所需要的時間。增加權限認證eg：flashall 權限認證，得有密碼才能做。當然，高速數據交互一般都不會在每次都進行權限認證，通用的處理策略是第一次認證，后期都不用再認證。控制hash策略沒有key, 就找不到value。不知道hash策略, 就無法得到key。

　　Config Dump:內存中的配置項動態修改過, 按照一定策略寫入到磁盤中。

　　bgsave帶來aof寫入很慢:fdatasync在做bgsave時, 不做sync aof。

　　成本問題:Redisscounter全部變為整型存儲, 其余全不要。Redis+SSD順序自增, table按照順序寫, 寫滿10個table就自動落地。存儲分級: 內存分配問題, 10K和100K寫到一塊, 會有碎片. Sina已經優化到浪費只占5%以內。

 

　　5.Problem: 分布式問題

　　Config Server: 命名空間, 特別大的告訴訪問, 都不適合用代理, 因為代理降低速度, 但是, Sina用了Config Server放到Zookeeper上最前面是命名服務，后面跟的是無狀態的twmemproxy,后面才是Redis。

       twmemproxy應用不必關心連接失敗, 由代理負責重連把Hash算法放到代理商代理后邊的升級, 前端不關心, 解決了HA的問題無狀態, 多臺代理無所謂3.AS --> Proxy -->Redis4.Sina的Redis都是單機版, 而Redis-Cluster交互過于復雜，沒有使用做HA的話，一定要配合監控來做，如果掛了之后，后續該如何做;并不是追求單機性能，而是集群的吞吐量，從而可以支持無線擴展。

　　

        以上是Redis數據庫的相關內容，需要更加詳細的內容，可以借助更加強大的搜索引擎查找。