Redis架構第五天：Redis其他問題及Redis架構總結

--------------------------------------------------其他問題---------------------------------------------------------------------

1、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，全量複制

2、AOF的阻塞問題

redis将資料寫入AOF緩沖區，單獨開一個現場做fsync操作，每秒一次

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

everysec，最多丢失2秒的資料

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

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

3、主從複制延遲問題

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

在info replication中，可以看到master和slave複制的offset，做一個內插補點就可以看到對應的延遲量

如果延遲過多，那麼就進行報警

4、主從複制風暴問題

如果一下子讓多個slave從master去執行全量複制，一份大的rdb同時發送到多個slave，會導緻網絡帶寬被嚴重占用

如果一個master真的要挂載多個slave，那盡量用樹狀結構，不要用星型結構

5、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

6、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

7、最大打開檔案句柄

ulimit -n 10032 10032

自己去上網搜一下，不同的作業系統，版本，設定的方式都不太一樣

8、tcp backlog

cat /proc/sys/net/core/somaxconn

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

-----------------------------------------------------理論小結------------------------------------------------------------

1、講解redis是為了什麼？

topic：高并發、億級流量、高性能、海量資料的場景，電商網站的商品詳情頁系統的緩存架構

商品詳情頁系統，大型電商網站，會有很多部分組成，但是支撐高并發、億級流量的，主要就是其中的大型的緩存架構

在這個大型的緩存架構中，redis是最最基礎的一層

高并發，緩存架構中除了redis，還有其他的組成部分，但是redis至關重要

大量的離散請求，随機請求，各種你未知的使用者過來的請求，上千萬使用者過來通路，每個使用者通路10次; 集中式的請求，1個使用者過來，一天通路1億次

支撐商品展示的最重要的，就是redis cluster，去抗住每天上億的請求流量，支撐高并發的通路

redis cluster在整個緩存架構中，如何跟其他幾個部分搭配起來組成一個大型的緩存系統，後面再講

2、講解的redis可以實作什麼效果？

我之前一直在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，實作能夠任意水準擴容，支撐海量資料（1T+，幾十T，10G * 600 redis = 6T），支撐很高的讀寫QPS（redis單機在幾萬QPS，10台，幾十萬QPS），高可用性（給我們每個redis執行個體都做好AOF+RDB的備份政策+容災政策，slave -> master主備切換）

1T+海量資料、10萬+讀寫QPS、99.99%高可用性

3、redis的第一套企業級的架構

如果你的資料量不大，單master就可以容納，一般來說你的緩存的總量在10G以内就可以，那麼建議按照以下架構去部署redis

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

可以支撐的資料量在10G以内，可以支撐的寫QPS在幾萬左右，可以支撐的讀QPS可以上10萬以上（随你的需求，水準擴容slave節點就可以），可用性在99.99%

4、redis的第二套企業級架構

如果你的資料量很大，比如我們課程的topic，大型電商網站的商品詳情頁的架構（對标那些國内排名前三的大電商網站，寶，東，*甯易購），資料量是很大的

海量資料

redis cluster

多master分布式存儲資料，水準擴容

支撐更多的資料量，1T+以上沒問題，隻要擴容master即可

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

支撐99.99%可用性，也沒問題，slave -> master的主備切換，備援slave去進一步提升可用性的方案（每個master挂一個slave，但是整個叢集再加個3個slave備援一下）

我們課程裡，兩套架構都講解了，後續的業務系統的開發，主要是基于redis cluster去做

5、我們現在課程講解的項目進展到哪裡了？

我們要做後續的業務系統的開發，redis的架構部署好，是第一件事情，也是非常重要的，也是你作為一個架構師而言，在對系統進行設計的時候，你必須要考慮到底層的redis的并發、性能、能支撐的資料量、可用性

redis：水準擴容，海量資料，上10萬的讀寫QPS，99.99%高可用性

從架構的角度，我們的redis是可以做到的，水準擴容，隻要機器足夠，到1T資料量，50萬讀寫QPS，99.99%

正式開始做大型電商網站的商品詳情頁系統，大規模的緩存架構設計