redis深度剖析: 06 常見問題和企業級架構

一. 常見問題

一、fork耗時致使高併發請求延時

RDB和AOF的時候，其實會有生成RDB快照，AOF rewrite，耗費磁盤IO的過程，主進程fork子進程

fork的時候，子進程是須要拷貝父進程的空間內存頁表的，也是會耗費必定的時間的

通常來講，若是父進程內存有1個G的數據，那麼fork可能會耗費在20ms左右，若是是10G~30G，那麼就會耗費20 * 10，甚至20 * 30，也就是幾百毫秒的時間

info stats中的latest_fork_usec，能夠看到最近一次form的時長

redis單機QPS通常在幾萬，fork可能一會兒就會拖慢幾萬條操做的請求時長，從幾毫秒變成1秒

優化思路

fork耗時跟redis主進程的內存有關係，通常控制redis的內存在10GB之內，slave -> master，全量複製

二、AOF的阻塞問題

redis將數據寫入AOF緩衝區，單獨開一個現場作fsync操做，每秒一次

可是redis主線程會檢查兩次fsync的時間，若是距離上次fsync時間超過了2秒，那麼寫請求就會阻塞

everysec，最多丟失2秒的數據

一旦fsync超過2秒的延時，整個redis就被拖慢

優化思路

優化硬盤寫入速度，建議採用SSD，不要用普通的機械硬盤，SSD，大幅度提高磁盤讀寫的速度

三、主從複製延遲問題

主從複製可能會超時嚴重，這個時候須要良好的監控和報警機制

在info replication中，能夠看到master和slave複製的offset，作一個差值就能夠看到對應的延遲量

若是延遲過多，那麼就進行報警

四、主從複製風暴問題

若是一會兒讓多個slave從master去執行全量複製，一份大的rdb同時發送到多個slave，會致使網絡帶寬被嚴重佔用

若是一個master真的要掛載多個slave，那儘可能用樹狀結構，不要用星型結構

五、vm.overcommit_memory

0: 檢查有沒有足夠內存，沒有的話申請內存失敗

1: 容許使用內存直到用完爲止

2: 內存地址空間不能超過swap + 50%

若是是0的話，可能致使相似fork等操做執行失敗，申請不到足夠的內存空間

cat /proc/sys/vm/overcommit_memory

echo "vm.overcommit_memory=1" >> /etc/sysctl.conf

sysctl vm.overcommit_memory=1

六、swapiness

cat /proc/version，查看linux內核版本

若是linux內核版本<3.5，那麼swapiness設置爲0，這樣系統寧願swap也不會oom killer（殺掉進程）

若是linux內核版本>=3.5，那麼swapiness設置爲1，這樣系統寧願swap也不會oom killer

保證redis不會被殺掉

echo 0 > /proc/sys/vm/swappiness

echo vm.swapiness=0 >> /etc/sysctl.conf

七、最大打開文件句柄

ulimit -n 10032 10032

本身去上網搜一下，不一樣的操做系統，版本，設置的方式都不太同樣

八、tcp backlog

cat /proc/sys/net/core/somaxconn

echo 511 > /proc/sys/net/core/somaxconn

二. redis總結:

redis：持久化、複製（主從架構）、哨兵（高可用，主備切換）、redis cluster（海量數據+橫向擴容+高可用/主備切換）

持久化：高可用的一部分，在發生redis集羣災難的狀況下（好比說部分master+slave所有死掉了），如何快速進行數據恢復，快速實現服務可用，才能實現整個系統的高可用

複製：主從架構，master -> slave 複製，讀寫分離的架構，寫master，讀slave，橫向擴容slave支撐更高的讀吞吐，讀高併發，10萬，20萬，30萬，上百萬，QPS，橫向擴容

哨兵：高可用，主從架構，在master故障的時候，快速將slave切換成master，實現快速的災難恢復，實現高可用性

redis cluster：多master讀寫，數據分佈式的存儲，橫向擴容，水平擴容，快速支撐高達的數據量+更高的讀寫QPS，自動進行master -> slave的主備切換，高可用

爲何要學redis理論知識:

讓底層的緩存系統，redis，實現可以任意水平擴容，支撐海量數據（1T+，幾十T，10G * 600 redis = 6T），支撐很高的讀寫QPS（redis單機在幾萬QPS，10臺，幾十萬QPS），高可用性（給咱們每一個redis實例都作好AOF+RDB的備份策略+容災策略，slave -> master主備切換）

實現1T+海量數據、10萬+讀寫QPS、99.99%高可用性

三.  redis的第一套企業級的架構

若是你的數據量不大，單master就能夠容納，通常來講你的緩存的總量在10G之內就能夠，那麼建議按照如下架構去部署redis

redis持久化+備份方案+容災方案+replication（主從+讀寫分離）+sentinal（哨兵集羣，3個節點，高可用性）

能夠支撐的數據量在10G之內，能夠支撐的寫QPS在幾萬左右，能夠支撐的讀QPS能夠上10萬以上（隨你的需求，水平擴容slave節點就能夠），可用性在99.99%

四. redis的第二套企業級架構

若是你的數據量很大，好比咱們課程的topic，大型電商網站的商品詳情頁的架構（對標那些國內排名前三的大電商網站，*寶，*東，*寧易購），數據量是很大的

海量數據

redis cluster

多master分佈式存儲數據，水平擴容

支撐更多的數據量，1T+以上沒問題，只要擴容master便可

讀寫QPS分別都達到幾十萬都沒問題，只要擴容master便可，redis cluster，讀寫分離，支持不太好，readonly才能去slave上讀

支撐99.99%可用性，也沒問題，slave -> master的主備切換，冗餘slave去進一步提高可用性的方案（每一個master掛一個slave，可是整個集羣再加個3個slave冗餘一下）