為啥Redis/Mongo這么快，就不能直接替代mysql嗎？Mysql、rredis寫入數(shù)據(jù)，越來越慢，是什么原因？Redis寫的慢，可能是節(jié)點數(shù)據(jù)不足，網(wǎng)絡(luò)慢，或者主機原因。大量導(dǎo)入數(shù)據(jù)時，可以使

為啥Redis/Mongo這么快，就不能直接替代mysql嗎？

Mysql、r

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

Redis寫的慢，可能是節(jié)點數(shù)據(jù)不足，網(wǎng)絡(luò)慢，或者主機原因。

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

傳統(tǒng)命令的缺點

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

因為redis是單線程的模型，雖然避免了多線程下線程切換的時間，快速執(zhí)行單個序列的命令，但是在海量數(shù)據(jù)導(dǎo)入的場景下，發(fā)送命令和接收服務(wù)器響應(yīng)結(jié)果的時間會被放大。

如果需要導(dǎo)入100萬條數(shù)據(jù)，光是命令執(zhí)行時間就要花費100萬*(t1 t2)。

RESP議定書散裝

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

Redis-cli管道模式需要和nc命令一樣快，它解決了nc命令不能 我不知道命令什么時候結(jié)束。

在發(fā)送數(shù)據(jù)時，它還會讀取響應(yīng)并嘗試解析它。

一旦輸入流中不再有數(shù)據(jù)被讀取，它將發(fā)送一個特殊的20位echo命令，表明最后一個命令已經(jīng)發(fā)送。如果響應(yīng)結(jié)果中匹配到相同的數(shù)據(jù)，則批量傳輸成功。

使用這種技術(shù)，我們不 不需要解析發(fā)送給服務(wù)器的協(xié)議來知道我們發(fā)送了多少命令，只需解析回復(fù)。

redis在解析回復(fù)時，會對解析的回復(fù)進行統(tǒng)計，最終可以告訴用戶大量插入的會話向服務(wù)器傳輸?shù)拿顢?shù)量。也就是我們使用上面的管道模式實際操作的響應(yīng)結(jié)果。