有些“上古”程序員一直堅(jiān)持反對(duì)使用redis怎么辦？分享大人物的答案似乎合情合理。不要告訴我們是否使用redis。你必須告訴我們你為什么要使用redis。沒(méi)有redis的業(yè)務(wù)怎么了？世界上沒(méi)有免費(fèi)的午

有些“上古”程序員一直堅(jiān)持反對(duì)使用redis怎么辦？

分享大人物的答案似乎合情合理。

不要告訴我們是否使用redis。你必須告訴我們你為什么要使用redis。沒(méi)有redis的業(yè)務(wù)怎么了？世界上沒(méi)有免費(fèi)的午餐。如果不直接使用頭部緩存/NoSQL，可能會(huì)帶來(lái)越來(lái)越嚴(yán)重的問(wèn)題。

單個(gè)數(shù)據(jù)庫(kù)的最大優(yōu)點(diǎn)是易于實(shí)現(xiàn)事務(wù)，并由數(shù)據(jù)庫(kù)本身保證。舉個(gè)簡(jiǎn)單的例子，要下訂單，需要扣除庫(kù)存并插入訂單條目。如果inventory和order都是數(shù)據(jù)庫(kù)表?xiàng)l目，那么這個(gè)事務(wù)是無(wú)可挑剔的。如果庫(kù)存在redis中，訂單條目是mysql，通常需要先寫(xiě)redis，成功后再寫(xiě)數(shù)據(jù)庫(kù)。如果您寫(xiě)數(shù)據(jù)庫(kù)失敗，需要回滾redis，如果由于網(wǎng)絡(luò)或其他原因回滾失敗，將再扣減一個(gè)存貨。不要認(rèn)為這些事情很容易解決。事務(wù)處理的復(fù)雜性遠(yuǎn)遠(yuǎn)超出您的想象。例如，當(dāng)您編寫(xiě)mysql時(shí)，您在提交時(shí)就失去了連接。你無(wú)法判斷提交是成功還是失敗。你的redis是不是在倒退？

因此，當(dāng)您引入一個(gè)新層時(shí)，您必須弄清楚您必須使用cache/NoSQL的目的以及您可以接受的一致性模型。否則，你就要出丑了。

redis寫(xiě)入數(shù)據(jù)，越來(lái)越慢，是什么原因？

Redis寫(xiě)得慢，這可能是由于節(jié)點(diǎn)數(shù)據(jù)不足、網(wǎng)絡(luò)或主機(jī)速度慢造成的。

導(dǎo)入大量數(shù)據(jù)時(shí)，可以使用resp協(xié)議。

使用傳統(tǒng)redis的客戶端命令在大數(shù)據(jù)量導(dǎo)入場(chǎng)景中存在以下缺陷：

由于redis是單線程模型，雖然避免了多線程下線程切換所消耗的時(shí)間，命令單次執(zhí)行速度快，但在大數(shù)據(jù)量導(dǎo)入場(chǎng)景中，客戶端命令的執(zhí)行速度慢發(fā)送命令和接收服務(wù)器響應(yīng)結(jié)果所消耗的時(shí)間將被放大。

如果您需要導(dǎo)入100萬(wàn)條數(shù)據(jù)，僅就命令執(zhí)行時(shí)間而言，就需要花費(fèi)100萬(wàn)*（T1，T2）。

Redis客戶端使用稱為resp（Redis序列化協(xié)議）的協(xié)議與Redis服務(wù)器通信。

Redis cli pipe mode需要和NC command一樣快，解決了NC command不知道何時(shí)結(jié)束的問(wèn)題。

在發(fā)送數(shù)據(jù)時(shí)，它還會(huì)讀取響應(yīng)并嘗試對(duì)其進(jìn)行解析。

一旦輸入流中不再讀取數(shù)據(jù)，它將發(fā)送一個(gè)特殊的20位回顯命令，以指示已發(fā)送最后一個(gè)命令。如果在響應(yīng)結(jié)果中匹配相同的數(shù)據(jù)，則批發(fā)送成功。

使用這種技術(shù)，我們不需要解析發(fā)送到服務(wù)器的協(xié)議就可以知道我們發(fā)送了多少命令，我們只需要解析響應(yīng)。

在解析響應(yīng)時(shí)，redis會(huì)對(duì)解析的響應(yīng)進(jìn)行計(jì)數(shù)，最后，它可以通過(guò)插入大量會(huì)話來(lái)告訴用戶傳輸?shù)椒?wù)器的命令數(shù)。這是管道模式實(shí)際操作的響應(yīng)結(jié)果。