Redis簡(jiǎn)介

 

　　1.支持5種數(shù)據(jù)結(jié)構(gòu)

　　支持strings, hashes, lists, sets, sorted setsstring是很好的存儲(chǔ)方式，用來(lái)做計(jì)數(shù)存儲(chǔ)。sets用于建立索引庫(kù)非常棒。

 

　　2.K-V 存儲(chǔ) vs K-V 緩存

　　新浪微博目前使用的98%都是持久化的應(yīng)用，2%的是緩存，用到了600+服務(wù)器Redis中持久化的應(yīng)用和非持久化的方式不會(huì)差別很大：非持久化的為8-9萬(wàn)tps，那么持久化在7-8萬(wàn)tps左右;當(dāng)使用持久化時(shí)，需要考慮到持久化和寫性能的配比，也就是要考慮redis使用的內(nèi)存大小和硬盤寫的速率的比例計(jì)算。

 

　　3.社區(qū)活躍

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

 

　　Redis基本原理

 

　　Redis持久化(aof) append online file：寫log(aof), 到一定程度再和內(nèi)存合并. 追加再追加, 順序?qū)懘疟P, 對(duì)性能影響非常小。

 

　　1. 單實(shí)例單進(jìn)程

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

 

　　2. Replication

　　過(guò)程: 數(shù)據(jù)寫到master-->master存儲(chǔ)到slave的rdb中-->slave加載rdb到內(nèi)存。存儲(chǔ)點(diǎn)(save point): 當(dāng)網(wǎng)絡(luò)中斷了, 連上之后, 繼續(xù)傳.Master-slave下第一次同步是全傳，后面是增量同步。

 

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

　　長(zhǎng)期運(yùn)行后多個(gè)結(jié)點(diǎn)之間存在不一致的可能性。開(kāi)發(fā)兩個(gè)工具程序：1.對(duì)于數(shù)據(jù)量大的數(shù)據(jù)，會(huì)周期性的全量檢查。2.實(shí)時(shí)的檢查增量數(shù)據(jù)，是否具有一致性。

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

 

 

　　Redis應(yīng)用

 

　　1.業(yè)務(wù)使用方式

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

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

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

　　lists(queue): push/sub提醒

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

　　將memcache +myaql 替換為Redis：Redis作為存儲(chǔ)并提供查詢，后臺(tái)不再使用mysql，解決數(shù)據(jù)多份之間的一致性問(wèn)題。

 

　　2.對(duì)大數(shù)據(jù)表的存儲(chǔ)

　　一個(gè)庫(kù)就存唯一性id和140個(gè)字;另一個(gè)庫(kù)存id和用戶名，發(fā)布日期、點(diǎn)擊數(shù)等信息，用來(lái)計(jì)算、排序等，等計(jì)算出最后需要展示的數(shù)據(jù)時(shí)再到第一個(gè)庫(kù)中提取微博內(nèi)容。

　　改進(jìn)的3個(gè)步驟:1)發(fā)現(xiàn)現(xiàn)有系統(tǒng)存在問(wèn)題;2)發(fā)現(xiàn)了新東西, 怎么看怎么好, 全面轉(zhuǎn)向新東西;3)理性回歸, 判斷哪些適合新東西, 哪些不適合, 不合適的回遷到老系統(tǒng)。

 

　　3.一些技巧分享

　　很多應(yīng)用, 可以承受數(shù)據(jù)庫(kù)連接失敗, 但不能承受處理慢。一份數(shù)據(jù), 多份索引。解決IO瓶頸的唯一途徑: 用內(nèi)存。在數(shù)據(jù)量變化不大的情況下，優(yōu)先選用Redis數(shù)據(jù)庫(kù)。

 

　　常見(jiàn)問(wèn)題及解決辦法

 

　　1.Problem: Replication中斷后, 重發(fā)-->網(wǎng)絡(luò)突發(fā)流量

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

 

　　2.Problem: 容量問(wèn)題

　　Solution: 容量規(guī)劃和M/S的sharding功能增加一些配置, 分流, 比如: 四臺(tái)機(jī)器，機(jī)器1處理%2=1的, 機(jī)器2處理%2=0的.低于內(nèi)存的1/2使用量, 否則就擴(kuò)容。我們線上96G/128G內(nèi)存服務(wù)器不建議單實(shí)例容量大于20/30G。微博應(yīng)用中單表數(shù)據(jù)最高的有2T的數(shù)據(jù)，不過(guò)應(yīng)用起來(lái)已經(jīng)有些力不從心。每個(gè)的端口不要超過(guò)20G。測(cè)試磁盤做save所需要的時(shí)間，需要多長(zhǎng)時(shí)間能夠全部寫入。內(nèi)存越大，寫的時(shí)間也就越長(zhǎng)。單實(shí)例內(nèi)存容量較大后，直接帶來(lái)的問(wèn)題就是故障恢復(fù)或者Rebuild從庫(kù)的時(shí)候時(shí)間較長(zhǎng)，對(duì)于普通硬盤的加載速度而言，我們的經(jīng)驗(yàn)一般是redis加載1G需要1分鐘。Redis rewrite aof和save rdb時(shí)，將會(huì)帶來(lái)非常大且長(zhǎng)的系統(tǒng)壓力，并占用額外內(nèi)存，很可能導(dǎo)致系統(tǒng)內(nèi)存不足等嚴(yán)重影響性能的線上故障。

　　reblance: 現(xiàn)有數(shù)據(jù)按照上述配置重新分發(fā)。后面使用中間層，路由HA;注：目前官方也正在做這個(gè)事，Redis Cluster，解決HA問(wèn)題。

 

　　3.Problem: bgsave or bgwriteaof的冰晶問(wèn)題

　　Solution: 磁盤性能規(guī)劃和限制寫入的速度, 比如: 規(guī)定磁盤以200M/s的速度寫入, 細(xì)水長(zhǎng)流, 即使到來(lái)大量數(shù)據(jù). 但是要注意寫入速度要滿足兩個(gè)客觀限制:符合磁盤速度符合時(shí)間限制。

 

　　4.Problem: 運(yùn)維問(wèn)題

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

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

　　危險(xiǎn)命令的處理: 比如: fresh all刪除全部數(shù)據(jù), 得進(jìn)行控制運(yùn)維不能只講數(shù)據(jù)備份，還得考慮數(shù)據(jù)恢復(fù)所需要的時(shí)間。增加權(quán)限認(rèn)證eg：flashall 權(quán)限認(rèn)證，得有密碼才能做。當(dāng)然，高速數(shù)據(jù)交互一般都不會(huì)在每次都進(jìn)行權(quán)限認(rèn)證，通用的處理策略是第一次認(rèn)證，后期都不用再認(rèn)證?？刂苃ash策略沒(méi)有key, 就找不到value。不知道hash策略, 就無(wú)法得到key。

　　Config Dump:內(nèi)存中的配置項(xiàng)動(dòng)態(tài)修改過(guò), 按照一定策略寫入到磁盤中。

　　bgsave帶來(lái)aof寫入很慢:fdatasync在做bgsave時(shí), 不做sync aof。

　　成本問(wèn)題:Redisscounter全部變?yōu)檎痛鎯?chǔ), 其余全不要。Redis+SSD順序自增, table按照順序?qū)? 寫滿10個(gè)table就自動(dòng)落地。存儲(chǔ)分級(jí): 內(nèi)存分配問(wèn)題, 10K和100K寫到一塊, 會(huì)有碎片. Sina已經(jīng)優(yōu)化到浪費(fèi)只占5%以內(nèi)。

 

　　5.Problem: 分布式問(wèn)題

　　Config Server: 命名空間, 特別大的告訴訪問(wèn), 都不適合用代理, 因?yàn)榇斫档退俣? 但是, Sina用了Config Server放到Zookeeper上最前面是命名服務(wù)，后面跟的是無(wú)狀態(tài)的twmemproxy,后面才是Redis。

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

　　

        以上是Redis數(shù)據(jù)庫(kù)的相關(guān)內(nèi)容，需要更加詳細(xì)的內(nèi)容，可以借助更加強(qiáng)大的搜索引擎查找。