redis 命令exists vs get，在判斷key是否存在的場(chǎng)景下： exists速度更快，可以忽略類(lèi)型。 get只適用于string類(lèi)型，當值越大時(shí)，速度越慢。

Redis存在慢查詢(xún)導致請求延時(shí) 由于Redis主線(xiàn)程是單線(xiàn)程的，所以會(huì )存在慢查詢(xún)會(huì )導致redis請求延時(shí)，可以參考： http://www.pzrlhr.cn/articles/2020/07/23/1595493094855.html redis存在大value導致請求延時(shí) 可以通過(guò)下面命令查找大value: redis-cli -p 6379 -h 127.0.0.1 --bigkeys redis-cli -p 6379 -h 127.0.0.1 --memkeys fork 耗時(shí)導致高并發(fā)請求延時(shí) RDB 和 AOF 的時(shí)候會(huì )存在 RDB 快照生成、AOF rewrite，耗費磁盤(pán) IO 的過(guò)程。主進(jìn)程 fork 子進(jìn)程的時(shí)候，子進(jìn)程是需要拷貝父進(jìn)程的空間內存頁(yè)表的，也是會(huì )耗費一定的時(shí)間的一般來(lái)說(shuō)，如果父進(jìn)程內存有 1 個(gè) G 的數據，那么 fork 可能會(huì )耗費在 20ms 左右，如果是 10G~30G，那么就會(huì )耗費 20 * 10，甚至 20 * 30，也就是幾百毫秒的時(shí)間。 info stats 中的 latest_fork_usec，可以看到最近一次 fork ....

問(wèn)題現象：Redis 頻繁進(jìn)行主備倒換，通過(guò)查看主實(shí)例的日志：redis.log發(fā)現下面報錯： Client id=1317049445 addr=192.168.2.45:8004 fd=40 name= age=314 idle=0 flags=S db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=32568 obl=0 oll=4430 omem=761143439 events=rw cmd=psync scheduled to be closed ASAP for overcoming of output buffer limits 其中：psync scheduled to be closed ASAP for overcoming of output buffer limits 明顯就是問(wèn)題所在，那是什么問(wèn)題呢。于是我在源碼中搜索了scheduled to be closed ASAP for overcoming of output buffer limits(psync明顯是一個(gè)命令，就不用在代碼里面搜索了)。

Redis從3.0開(kāi)始引入集群模式的概念。 集群由多個(gè)節點(diǎn)(Node)組成，Redis的數據分布在這些節點(diǎn)中。集群中的節點(diǎn)分為主節點(diǎn)和從節點(diǎn)：只有主節點(diǎn)負責讀寫(xiě)請求和集群信息的維護；從節點(diǎn)只進(jìn)行主節點(diǎn)數據和狀態(tài)信息的復制。 Redis集群模式的作用主要分為： 1、 數據分區：數據分區(或稱(chēng)數據分片)是集群最核心的功能。 2、高可用：Redis集群模式中，每個(gè)主實(shí)例都會(huì )存在至少一個(gè)被實(shí)例，能夠在主實(shí)例故障之后，頂替主實(shí)例工作。

Redis基礎知識總結思維導圖，系統的學(xué)習Redis。不定時(shí)更新。 主要包括： 基本數據和應用場(chǎng)景 常見(jiàn)問(wèn)題分析 性能優(yōu)化 持久化 集群模式 子模塊

Redis 6實(shí)現了通道加密，提高了redis的安全性。Redis作為緩存數據庫，里面很有可能緩存重要的敏感信息，所以支持tls通道加密還是很有必要的，當然敏感信息還是建議加密保存。

在使用的過(guò)程中發(fā)現Redis ACL 只是針對單個(gè)Redis實(shí)例而言的，但是在生產(chǎn)環(huán)境我們一定用的是哨兵模式或者集群模式，那么就存在Redis集群中實(shí)例ACL權限信息的同步問(wèn)題。

RESP3是RESP v2的更新版本，RESP v2是Redis中使用的協(xié)議，大約從版本2.0開(kāi)始（1.2已經(jīng)支持它，但是Redis 2.0是第一個(gè)只討論這個(gè)協(xié)議的版本）。此協(xié)議的名稱(chēng)只是RESP3，而不是respv3或RESP3.0。 該協(xié)議用于處理客戶(hù)機和服務(wù)器之間的請求-響應通信，其中客戶(hù)機執行某種請求，服務(wù)器用一些數據進(jìn)行回復。該協(xié)議特別適合于數據庫，因為它能夠返回復雜的數據類(lèi)型和相關(guān)的信息來(lái)擴充返回的數據（例如給定信息的流行度指數）。 RESP3協(xié)議可以不對稱(chēng)地使用，就像在Redis中一樣：客戶(hù)端只能向服務(wù)器發(fā)送一個(gè)子集，而服務(wù)器可以返回可用的完整類(lèi)型集。這是因為RESP設計用于發(fā)送非結構化命令，如 SET mykey somevalue或 SADD myset a b c d。此類(lèi)命令可以表示為數組，其中每個(gè)參數都是數組元素，因此這是客戶(hù)端需要發(fā)送到服務(wù)器的唯一類(lèi)型。然而，愿意將RESP3用于其他目標的不同應用程序可能只允許以“全雙工”方式使用協(xié)議，其中兩端都可以使用可用的全套類(lèi)型。 不是RESP3的所有部分對客戶(hù)端和服務(wù)器都是必需的。在Redis的具體案例中，RESP3描....

客戶(hù)端緩存是一種用于創(chuàng )建高性能服務(wù)的技術(shù)。它利用應用服務(wù)器中的可用內存，這些服務(wù)器通常是與數據庫節點(diǎn)不同的計算機，以便將數據庫信息的某些子集直接存儲在應用程序端。

RDB快照有兩種觸發(fā)方式，其一為通過(guò)配置參數，例如在配置文件中寫(xiě)入如下配置： save 60 1000 則在60秒內如果有1000個(gè)key發(fā)生變化，就會(huì )觸發(fā)一次RDB快照的執行。 其二是通過(guò)在客戶(hù)端執行bgsave命令顯式觸發(fā)一次RDB快照的執行。