以下文章基于Redis3.0以上版本源碼進(jìn)行分析解讀
我們?cè)谏弦黄恼?a href="http://www.itdecent.cn/p/29dd668c3ca6" target="_blank">Redis之EventLoop分析中知道:
- Reids Server中所有的操作都是通過(guò)Event Loop單線程串行調(diào)度的
- Event Loop中每個(gè)loop中除了處理當(dāng)前io event外, 還會(huì)處理內(nèi)存回收、RDB刷出及復(fù)制等邏輯
由此可知，影響Redis單點(diǎn)性能的操作主要會(huì)有以下幾個(gè)方面:
- Blocking Command的處理(blpop、pubsub...)
- 內(nèi)存數(shù)據(jù)的頻繁刷出(RDB/AOF)
先來(lái)分析一下為什么Blocking Command會(huì)對(duì)性能有很大影響
遍歷所有的key和blocked client
redis中block command偵聽(tīng)數(shù)據(jù)結(jié)構(gòu)&處理邏輯
- redis server會(huì)有一個(gè)全局鏈表 readkeys, 保存了所有被blpop block的key
- 鏈表中的每個(gè)節(jié)點(diǎn)保存了一個(gè)當(dāng)前key上所有blocked client
- redis 在每次處理command完成后, 都會(huì)通過(guò)一個(gè)雙層循環(huán)
- 由于每次請(qǐng)求的處理都需要完成block client的偵聽(tīng)邏輯, 當(dāng)有大量block client的時(shí)候, 就會(huì)導(dǎo)致每次請(qǐng)求的處理時(shí)延都會(huì)增加
- 當(dāng)然大量block client對(duì)于server端的鏈接維護(hù)也是個(gè)負(fù)擔(dān)
RDB/AOF頻繁刷出對(duì)于性能的影響分析
重溫一下event loop的處理機(jī)制
- time event會(huì)在event loop中被串行執(zhí)行.
- time event中會(huì)有比較多的高成本操作, 如db rehash、統(tǒng)計(jì)、RDB（AOF）數(shù)據(jù)刷出
- 其中最大的性能瓶頸就是數(shù)據(jù)的刷出, 因?yàn)镽edis默認(rèn)是fork一個(gè)子進(jìn)程, 將當(dāng)前內(nèi)存中的數(shù)據(jù)按照一定格式寫(xiě)入到本地文件中,
如果當(dāng)一個(gè)redis存在大量的寫(xiě)入請(qǐng)求, 并且rdb的flush策略沒(méi)有很好配置的時(shí)候, 可能每秒都會(huì)觸發(fā)數(shù)據(jù)的刷出, Disk IO的高負(fù)載會(huì)導(dǎo)致整體處理時(shí)延的提升, 最終租塞Event Loop的線程
