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使用的內(nèi)存大小和硬盤寫的速率的比例計算；

3. 社區(qū)活躍

Redis目前有3萬多行代碼, 代碼寫的精簡，有很多巧妙的實現(xiàn)，作者有技術潔癖

Redis的社區(qū)活躍度很高，這是衡量開源軟件質量的重要指標，開源軟件的初期一般都沒有商業(yè)技術服務支持，如果沒有活躍社區(qū)做支撐，一旦發(fā)生問題都無處求救；

Redis基本原理

redis持久化(aof) Append online file：

寫log(aof), 到一定程度再和內(nèi)存合并. 追加再追加, 順序寫磁盤, 對性能影響非常小

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到內(nèi)存。

存儲點(save point): 當網(wǎng)絡中斷了, 連上之后, 繼續(xù)傳.

Master-slave下第一次同步是全傳，后面是增量同步；、

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

長期運行后多個結點之間存在不一致的可能性；

開發(fā)兩個工具程序：

1.對于數(shù)據(jù)量大的數(shù)據(jù)，會周期性的全量檢查；

2.實時的檢查增量數(shù)據(jù)，是否具有一致性；

對于主庫未及時同步從庫導致的不一致，稱之為延時問題；

對于一致性要求不是那么嚴格的場景，我們只需要要保證最終一致性即可；

對于延時問題，需要根據(jù)業(yè)務場景特點分析，從應用層面增加策略來解決這個問題；

例如：

1.新注冊的用戶，必須先查詢主庫；

2.注冊成功之后，需要等待3s之后跳轉，后臺此時就是在做數(shù)據(jù)同步。

新浪Redis使用歷程

2009年, 使用memcache(用于非持久化內(nèi)容), memcacheDB(用于持久化+計數(shù)),

memcacheDB是新浪在memcache的基礎上，使用BerkeleyDB作為數(shù)據(jù)持久化的存儲實現(xiàn)；

1. 面臨的問題

• 數(shù)據(jù)結構(Data Structure)需求越來越多, 但memcache中沒有, 影響開發(fā)效率
• 性能需求, 隨著讀操作的量的上升需要解決，經(jīng)歷的過程有:
• 數(shù)據(jù)庫讀寫分離(M/S)-->數(shù)據(jù)庫使用多個Slave-->增加Cache (memcache)-->轉到Redis
• 解決寫的問題：
• 水平拆分，對表的拆分，將有的用戶放在這個表，有的用戶放在另外一個表；
• 可靠性需求
• Cache的"雪崩"問題讓人糾結
• Cache面臨著快速恢復的挑戰(zhàn)
• 開發(fā)成本需求
• Cache和DB的一致性維護成本越來越高(先清理DB, 再清理緩存, 不行啊, 太慢了!)
• 開發(fā)需要跟上不斷涌入的產(chǎn)品需求
• 硬件成本最貴的就是數(shù)據(jù)庫層面的機器，基本上比前端的機器要貴幾倍，主要是IO密集型，很耗硬件；
• 維護性復雜
• 一致性維護成本越來越高；
• BerkeleyDB使用B樹，會一直寫新的，內(nèi)部不會有文件重新組織；這樣會導致文件越來越大；大的時候需要進行文件歸檔，歸檔的操作要定期做；
• 這樣，就需要有一定的down time；

基于以上考慮， 選擇了Redis

2. 尋找開源軟件的方式及評判標準

• 對于開源軟件，首先看其能做什么，但更多的需要關注它不能做什么，它會有什么問題？
• 上升到一定規(guī)模后，可能會出現(xiàn)什么問題，是否能接受？
• google code上, 國外論壇找材料(國內(nèi)比國外技術水平滯后5年）
• 觀察作者個人的代碼水平

Redis應用場景

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

• hash sets: 關注列表, 粉絲列表, 雙向關注列表(key-value(field), 排序)
• string(counter): 微博數(shù), 粉絲數(shù), ...(避免了select count(*) from ...)
• sort sets(自動排序): TopN, 熱門微博等, 自動排序
• lists(queue): push/sub提醒,...

上述四種, 從精細化控制方面，hash sets和string(counter)推薦使用, sort sets和lists(queue)不推薦使用

還可通過二次開發(fā)，進行精簡。比如: 存儲字符改為存儲整形, 16億數(shù)據(jù), 只需要16G內(nèi)存

存儲類型保存在3種以內(nèi)，建議不要超過3種；

將memcache +myaql 替換為Redis：

Redis作為存儲并提供查詢，后臺不再使用MySQL，解決數(shù)據(jù)多份之間的一致性問題；

2. 對大數(shù)據(jù)表的存儲

（eg：140字微博的存儲）

一個庫就存唯一性id和140個字；

另一個庫存id和用戶名，發(fā)布日期、點擊數(shù)等信息，用來計算、排序等，等計算出最后需要展示的數(shù)據(jù)時再到第一個庫中提取微博內(nèi)容；

改進的3個步驟:

1）發(fā)現(xiàn)現(xiàn)有系統(tǒng)存在問題;

2）發(fā)現(xiàn)了新東西, 怎么看怎么好, 全面轉向新東西;

3）理性回歸, 判斷哪些適合新東西, 哪些不適合, 不合適的回遷到老系統(tǒng)

3. 一些技巧

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

遇到的問題及解決辦法

(注意: 都是量特別大時候會出現(xiàn)的, 量小了怎么都好說)

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

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

2.Problem: 容量問題

Solution: 容量規(guī)劃和M/S的sharding功能(share nothing, 抽象出來的數(shù)據(jù)對象之間的關聯(lián)數(shù)據(jù)很小)

增加一些配置, 分流, 比如: 1,2,3,4, 機器1處理%2=1的, 機器2處理%2=0的.

低于內(nèi)存的1/2使用量, 否則就擴容（建議Redis實例使用的數(shù)據(jù)，最大不要超過內(nèi)存的80%）

我們線上96G/128G內(nèi)存服務器不建議單實例容量大于20/30G。

微博應用中單表數(shù)據(jù)最高的有2T的數(shù)據(jù)，不過應用起來已經(jīng)有些力不從心；

每個的端口不要超過20G；測試磁盤做save所需要的時間，需要多長時間能夠全部寫入；內(nèi)存越大，寫的時間也就越長；

單實例內(nèi)存容量較大后，直接帶來的問題就是故障恢復或者Rebuild從庫的時候時間較長，對于普通硬盤的加載速度而言，我們的經(jīng)驗一般是redis加載1G需要1分鐘；（加載的速度依賴于數(shù)據(jù)量的大小和數(shù)據(jù)的復雜度）

Redis rewrite aof和save rdb時，將會帶來非常大且長的系統(tǒng)壓力，并占用額外內(nèi)存，很可能導致系統(tǒng)內(nèi)存不足等嚴重影響性能的線上故障。

reblance: 現(xiàn)有數(shù)據(jù)按照上述配置重新分發(fā)。

后面使用中間層，路由HA；

注：目前官方也正在做這個事，Redis Cluster，解決HA問題；

3. Problem: bgsave or bgwriteaof的冰晶問題

Solution: 磁盤性能規(guī)劃和限制寫入的速度, 比如: 規(guī)定磁盤以200M/s的速度寫入, 細水長流, 即使到來大量數(shù)據(jù). 但是要注意寫入速度要滿足兩個客觀限制:

符合磁盤速度

符合時間限制(保證在高峰到來之前, 就得寫完)

4.Problem: 運維問題

1）Inner Crontab: 把Crontab遷移到Redis內(nèi)部, 減少遷移時候的壓力

本機多端口避免同時做 - 能做到

同一業(yè)務多端口(分布在多機上), 避免同時做 - 做不到

2）動態(tài)升級: 先加載.so文件, 再管理配置, 切換到新代碼上(Config set命令)

把對redis改進的東西都打包成lib.so文件，這樣能夠支持動態(tài)升級

自己改的時候要考慮社區(qū)的升級。當社區(qū)有新的版本，有很好用的新功能時，要能很容易的與我們改進后的版本很好的merge；

升級的前提條件: 模塊化, 以模塊為單位升級

加載時間取決于兩個方面: 數(shù)據(jù)大小, 數(shù)據(jù)結構復雜度. 一般, 40G數(shù)據(jù)耗時40分鐘

分布式系統(tǒng)的兩個核心問題: A.路由問題 B.HA問題

3）危險命令的處理: 比如: fresh all刪除全部數(shù)據(jù), 得進行控制

運維不能只講數(shù)據(jù)備份，還得考慮數(shù)據(jù)恢復所需要的時間；

增加權限認證(管理員才有權限)eg：flashall 權限認證，得有密碼才能做；

當然，高速數(shù)據(jù)交互一般都不會在每次都進行權限認證，通用的處理策略是第一次認證，后期都不用再認證；

控制hash策略(沒有key, 就找不到value; 不知道hash策略, 就無法得到key)

4）Config Dump:

內(nèi)存中的配置項動態(tài)修改過, 按照一定策略寫入到磁盤中(Redis已支持)

5）bgsave帶來aof寫入很慢:

fdatasync在做bgsave時, 不做sync aof(會有數(shù)據(jù)出入)

6）成本問題: (22T內(nèi)存, 有10T用來計數(shù))

Redisscounter(16億數(shù)據(jù)占用16G內(nèi)存) - 全部變?yōu)檎痛鎯? 其余(字符串等)全不要

Redis+SSD(counterService計數(shù)服務)

順序自增, table按照順序寫, 寫滿10個table就自動落地(到SSD)

存儲分級: 內(nèi)存分配問題, 10K和100K寫到一塊, 會有碎片. Sina已經(jīng)優(yōu)化到浪費只占5%以內(nèi)(已經(jīng)很好了!)

5.Problem: 分布式問題

1.Config Server: 命名空間, 特別大的告訴訪問, 都不適合用代理, 因為代理降低速度, 但是, Sina用了(單機多端口, Redis Cluster, sentinel)

Config Server放到Zookeeper上

最前面是命名服務，后面跟的是無狀態(tài)的twmemproxy（twitter的改進的，用C寫的） ,后面才是redis；

2.twmemproxy

應用不必關心連接失敗, 由代理負責重連

把Hash算法放到代理商

代理后邊的升級, 前端不關心, 解決了HA的問題

無狀態(tài), 多臺代理無所謂

3.AS --> Proxy -->Redis

4.Sina的Redis都是單機版, 而Redis-Cluster交互過于復雜，沒有使用

做HA的話，一定要配合監(jiān)控來做，如果掛了之后，后續(xù)該如何做；

并不是追求單機性能，而是集群的吞吐量，從而可以支持無線擴展；

經(jīng)驗總結

• 提前做好數(shù)據(jù)量的規(guī)劃, 減少sharding(互聯(lián)網(wǎng)公司一般以年為單位)
• 只存精細化數(shù)據(jù)(內(nèi)存很金貴!)
• 存儲用戶維度的數(shù)據(jù)
• 對象維度的數(shù)據(jù)要有生命周期
• 特別是數(shù)據(jù)量特別大的時候，就很有必要來進行劃分了；
• 暴露服務的常見過程: IP-->負載均衡-->域名-->命名服務(一張表: 名字+資源(IP+端口))
• 對于硬件消耗，IO、網(wǎng)絡和CPU相比，Redis最消耗的是CPU，復雜的數(shù)據(jù)類型必定帶來CPU消耗；
• 新浪微博響應時間超時目前設置為5s；（返回很慢的記錄key，需記錄下來分析，慢日志）；
• 備份的數(shù)據(jù)要定期要跑一下生產(chǎn)的數(shù)據(jù)；用來檢查備份數(shù)據(jù)的有效性；
• slave掛多了肯定會對master造成比較的影響；新浪微博目前使用的M/S是一拖一，主要用來做容災；
• 同步時，是fork出一個單獨進程來和slave進行同步；不會占用查詢的進程；
• 升級到2.6.30以后的linux內(nèi)核；
• 在2.6.30以上對軟中斷的問題處理的很好，性能提升效果明顯，差不多有15%到30%的差距；
• redis不用讀寫分離，每個請求都是單線程，為什么要進行讀寫分離。

原文地址：https://www.cnblogs.com/me115/p/3482783.html

JAVA編程技術樂園：一個分享編程知識。跟著老司機一起學習干貨技術知識，每天進步一點點，讓小的積累，帶來大的改變！

歡迎關注！持續(xù)推送有趣有料的技術文章~