Redis阻塞是什么問(wèn)題造成的？

Redis阻塞是什么問(wèn)題造成的？很多人都不太了解，今天小編為了讓大家更加了解Redis阻塞問(wèn)題的原因，所以給大家總結(jié)了以下內(nèi)容，一起往下看吧。

Redis是一個(gè)單線程的架構(gòu)，所有的操作全部都在一個(gè)主線程中完成。所以一旦Redis發(fā)生阻塞，那將是一場(chǎng)噩夢(mèng)。接下來(lái)，我們就來(lái)看下對(duì)于Redis發(fā)生阻塞問(wèn)題。如何排查以及解決。

Redis數(shù)據(jù)結(jié)構(gòu)或API使用不合理

存在大對(duì)象且對(duì)大對(duì)象進(jìn)行復(fù)雜的較高的命令

1、對(duì)一個(gè)有千萬(wàn)個(gè)元素的hash執(zhí)行hgetall操作, 或del操作.類(lèi)似的這種操作都會(huì)造成Redis阻塞

2、對(duì)于這種大對(duì)象可以采用redis-cli -h {host} -p {port} bigkeys 來(lái)查看。但是該命令只能查詢某類(lèi)型中的其
中最大的一個(gè)key。如果你想查詢多個(gè)。可以采用修改redis-cli源代碼的方式（Redis的源代碼是C）。如果不想修 改源代碼的話也可以使用scan來(lái)完成。

對(duì)于Scan命令需要注意。該命令只能掃描單臺(tái)Redis上的數(shù)據(jù)。如果你是一個(gè)集群，需要每臺(tái)機(jī)器執(zhí)行一遍。但是如果你使用開(kāi)源的客戶端的話（比如：Java的Lettuce客戶端）就已經(jīng)幫你把scan命令實(shí)現(xiàn)為可以掃描整個(gè)集群了。

3、然后對(duì)大對(duì)象進(jìn)行拆分。具體拆分要視業(yè)務(wù)而定了。

Redis的CPU使用率接近100%

1、從機(jī)同步主機(jī)數(shù)據(jù)。從機(jī)接受到rdb文件后從磁盤(pán)加載數(shù)據(jù)

2、主從持久化數(shù)據(jù)。

3、將cpu使用率達(dá)到100%，有可能是真實(shí)業(yè)務(wù)訪問(wèn)量確實(shí)很大。單臺(tái)Redis達(dá)到每秒處理6萬(wàn)+的請(qǐng)求。這個(gè)時(shí)候就只能做水平擴(kuò)展了

4、如果Redis每秒操作數(shù)只有幾百，或者幾千，且cpu還是很高的話就有可能使用了高算法復(fù)雜度的命令。例如hgetall。還有一種可能是內(nèi)存的過(guò)度優(yōu)化導(dǎo)致。這種情況目前暫時(shí)沒(méi)有遇到，但也納入考慮范圍。

Cpu競(jìng)爭(zhēng)

1、Redis是一個(gè)CPU密集型的應(yīng)用，不適合和其他CPU密集的服務(wù)部署在一起。

2、在生產(chǎn)環(huán)境中，我們一臺(tái)服務(wù)器的配置是32核邏輯cpu, 256GB內(nèi)存。每臺(tái)機(jī)器如果只部署一臺(tái)Redis比較浪費(fèi)。所以可能會(huì)一臺(tái)機(jī)器部署多個(gè)Redis。通常會(huì)將Redis進(jìn)程綁定到CPU上。但是在生成RDB文件或者AOF持久話時(shí)，就會(huì)產(chǎn)生子進(jìn)程。這樣子進(jìn)程與父進(jìn)程會(huì)產(chǎn)生CPU競(jìng)爭(zhēng)。所以當(dāng)開(kāi)啟持久化或者主節(jié)點(diǎn)。不建議綁定CPU

內(nèi)存交換

Redis是一個(gè)內(nèi)存型數(shù)據(jù)庫(kù)，所有數(shù)據(jù)全部放在內(nèi)存中。所以強(qiáng)烈建議不開(kāi)啟內(nèi)存交換

網(wǎng)絡(luò)問(wèn)題

主從同步網(wǎng)絡(luò)延遲較大的話，導(dǎo)致從機(jī)經(jīng)常斷線重連。如果斷線時(shí)間久了。導(dǎo)致從機(jī)再次連接上主機(jī)時(shí)會(huì)全量同步，這時(shí)主機(jī)，從機(jī)都會(huì)收到影響

以上就是Redis阻塞是什么問(wèn)題造成的詳細(xì)內(nèi)容了，看完之后是否有所收獲呢？如果如果想了解更多，歡迎來(lái)億速云行業(yè)資訊！