點(diǎn)擊上方“朱小廝的博客”，選擇“設(shè)為星標(biāo)”

做積極的人，而不是積極廢人

一個(gè)老外的有關(guān)Redis的博客文章中提到一個(gè)有趣的事情：它們在測試期間獲得的延遲圖。為了持久化Redis的數(shù)據(jù)到磁盤（例如：RDB持久化），Redis需要調(diào)用fork()系統(tǒng)命令。 通常使用物理服務(wù)器和大多數(shù)虛擬機(jī)管理程序進(jìn)行fork是很快的，即使很大的進(jìn)程也是如此。 然而，Xen的fork()速度很慢，因此對于某些EC2實(shí)例類型（以及其他虛擬服務(wù)器提供程序），每次父進(jìn)程調(diào)用fork()以便進(jìn)行RDB持久化時(shí)，可能會(huì)出現(xiàn)嚴(yán)重的延遲峰值。 如下圖所示，清晰的展示了延遲峰值：

stripe-latency.png

您可以想象一下，如果您在fork()的時(shí)候做一個(gè)延遲測試，那么在父進(jìn)程fork()的時(shí)候，所有請求將延遲一秒（以上圖為例）。 這將產(chǎn)生大量具有高延遲的樣本，并且將影響99%的結(jié)果。

要更改實(shí)例類型，配置，設(shè)置或其他任何內(nèi)容以改善此行為是一個(gè)好主意，并且有些用例即使單個(gè)請求具有過高延遲也是不可接受的。然而很明顯的是，每30分鐘發(fā)生1秒的延遲峰值不是很明顯，因?yàn)檫@與在請求中均勻分布延遲峰值有很大不同。

如果是均勻分布的峰值，如果訪問某個(gè)頁面需要對Redis服務(wù)器執(zhí)行大量請求，則訪問頁面很可能會(huì)碰到延遲：這會(huì)嚴(yán)重影響服務(wù)質(zhì)量。

然而，如上圖所示，每運(yùn)行30分鐘后1秒的延遲是完全不同的事情。具有良好延遲表現(xiàn)的百分比隨著請求數(shù)量的增加而變得更好，因?yàn)檎埱笤蕉?#xff0c;這個(gè)延遲就越不可能在樣本中過度表示出來，反而會(huì)被隱藏。如果您每分鐘只有1個(gè)請求，并且其中一個(gè)請求恰好碰到fork()導(dǎo)致的高延遲，那就會(huì)讓延遲測試結(jié)果非常難看。

另外：大多數(shù)頁面瀏覽不受影響。 因?yàn)槲ㄒ荒菐讉€(gè)用戶碰到1秒延遲的，是剛好他們的請求和fork()在同一時(shí)間，其他用戶的請求只會(huì)有極低的概率碰到這樣糟糕的事情。 另外請注意，與fork()撞上的頁面訪問（即使由100個(gè)請求組成）也不會(huì)延遲超過一秒，因?yàn)閒ork()完成后請求就會(huì)完成，并不需要等到RDB持久化完成。

只有fork()會(huì)導(dǎo)致延遲毛刺，fork出來的子進(jìn)程在生成RDB文件過程中，并不會(huì)對系統(tǒng)有很大的影響。除非子進(jìn)程生成RDB文件的過程中（這個(gè)過程使用了操作系統(tǒng)的copy-on-write機(jī)制）有大量的寫入，而且服務(wù)器可用內(nèi)存不多，這時(shí)候可能會(huì)發(fā)生swapping導(dǎo)致出現(xiàn)延遲。

在當(dāng)今最流行的運(yùn)行時(shí)環(huán)境EC2實(shí)例中，fork延遲是Redis用戶最糟糕的體驗(yàn)之一，所以redis作者正著手測試Redis和EC2：相信很快就會(huì)在Redis官方文檔中有對EC2進(jìn)行特定優(yōu)化的說明 ，到時(shí)候會(huì)有比在master-slaves中禁用持久性操作更安全的方案。

如果您現(xiàn)在需要EC2 + Redis主機(jī)并且已禁用持久性，則最簡單的部署方式是禁用Redis實(shí)例的自動(dòng)重啟，并使用Sentinel進(jìn)行故障轉(zhuǎn)移，以便崩潰的主服務(wù)器不會(huì)自動(dòng)返回可用狀態(tài)。 在檢查故障轉(zhuǎn)移成功并且有新的可用的master后，系統(tǒng)管理員可以手動(dòng)重新啟動(dòng)實(shí)例。

需要說明的是，并非所有EC2實(shí)例都是相同的，恰恰相反，各種EC2實(shí)例fork表現(xiàn)差異還很大。如下圖所示，是老外做的一些測試：

image.png

圖片來自：https://redislabs.com/blog/testing-fork-time-on-awsxen-infrastructure/#.VFJQ-JPF8yF

• 總結(jié)

Redis持久化時(shí)調(diào)用fork可能引起嚴(yán)重的延遲（RDB持久化以及AOF rewrite都會(huì)調(diào)用fork命令）；
只是fork時(shí)引起延遲，fork完成后，子進(jìn)程生成RDB/AOF文件的過程并不會(huì)引起延遲；
即使Redis是單線程處理命令，但是服務(wù)器配置最好還是需要雙核，如果有多個(gè)Redis實(shí)例，那么核心數(shù)相應(yīng)的翻倍；
除了fork會(huì)引起延遲外，Redis中那些時(shí)間復(fù)雜度為O(n)的也會(huì)引起性能毛刺，例如keys命令等。

文章參考：http://antirez.com/news/83

想知道更多？掃描下面的二維碼關(guān)注我

相關(guān)推薦：

• 這才是實(shí)現(xiàn)分布式鎖的正確姿勢

• Redis分布式鎖最牛逼的實(shí)現(xiàn)

• Redission實(shí)現(xiàn)Redis分布式鎖的N種姿勢

• 基于數(shù)據(jù)庫實(shí)現(xiàn)的分布式鎖

• 基于Redis實(shí)現(xiàn)的分布式鎖
  

>>>Learn More<<

喜歡就點(diǎn)個(gè)"在看"唄^_^

總結(jié)

以上是生活随笔為你收集整理的Redis在持久化时产生的延迟的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。