Redis 使用了單線程架構(gòu)和 I/O 多路復用模型來實現(xiàn)高性能的內(nèi)存數(shù)據(jù)庫服務。

1. 單線程模型

開啟三個 redis-cli 客戶端同時執(zhí)行命令。客戶端 1 設(shè)置一個字符串鍵值對：

127.0.0.1:6379> set hello world

客戶端 2 對 counter 做自增操作：

127.0.0.1:6379> incr counter

客戶端 3 對 counter 做自增操作：

127.0.0.1:6379> incr counter

Redis 客戶端與服務端的模型可以簡化成下圖，每次客戶端調(diào)用都經(jīng)歷了發(fā)送命令、執(zhí)行命令、返回結(jié)果三個過程。

其中第 2 步是重點要討論的，因為 Redis 是單線程來處理命令的，所以一條命令從客戶端達到服務端不會立刻被執(zhí)行，所有命令都會進入一個隊列中，然后逐個被執(zhí)行。

所以上面 3 個客戶端命令的執(zhí)行順序是不確定的，如下圖所示。但是可以確定不會有兩條命令被同時執(zhí)行

所以兩條 incr 命令無論怎么執(zhí)行最終結(jié)果都是 2，不會產(chǎn)生并發(fā)問題，這就是 Redis 單線程的基本模型。

Redis 是單線程的。那么為什么說是單線程呢？Redis 在 Reactor 模型內(nèi)開發(fā)了事件處理器，這個事件處理器分為多個 Socket（套接字）、IO 多路復用程序、事件分派器、事件處理器（連接應答處理器、命令請求處理器、命令回復處理器），其中事件派發(fā)器的隊列是由單線程的事件處理器消費的，也是因為這個，Redis 才叫單線程模型。

當多個事件并發(fā)出現(xiàn)時，I/O 多路復用程序?qū)⒈O(jiān)聽到的所有 Socket，關(guān)聯(lián)不同的事件處理器，這個關(guān)聯(lián)操作以有序（sequentially）、同步（synchronously）、每次一個套接字的方式向事件分派器傳送 Socket：當上一個套接字產(chǎn)生的事件被處理完畢之后，I/O 多路復用程序才會繼續(xù)向事件分派器傳送下一個套接字。

2. 為什么單線程還能如此快

為什么 Redis 使用單線程模型會達到每秒萬級別的處理能力呢？可以將其歸結(jié)為三點：

1. 純內(nèi)存訪問，Redis 將所有數(shù)據(jù)放在內(nèi)存中，內(nèi)存的響應時長大約為 100 納秒，這是 Redis 達到每秒萬級別訪問的重要基礎(chǔ)。
2. 非阻塞 I/O，Redis 使用 epoll 作為 I/O 多路復用技術(shù)的實現(xiàn)，再加上 Redis 自身的事件處理模型將 epoll 中的連接、讀寫、關(guān)閉都轉(zhuǎn)換為件，不在網(wǎng)絡(luò) I/O 上浪費過多的時間。
3. 單線程避免了線程切換和競態(tài)產(chǎn)生的消耗。

單線程能帶來幾個好處：

1. 單線程可以簡化數(shù)據(jù)結(jié)構(gòu)和算法的實現(xiàn)。如果對高級編程語言熟悉的讀者應該了解并發(fā)數(shù)據(jù)結(jié)構(gòu)實現(xiàn)不但困難而且開發(fā)測試比較麻煩。
2. 單線程避免了線程切換和競態(tài)產(chǎn)生的消耗，對于服務端開發(fā)來說，鎖和線程切換通常是性能殺手。

但是單線程會有一個問題：對于每個命令的執(zhí)行時間是有要求的。如果某個命令執(zhí)行過長，會造成其他命令的阻塞，對于 Redis 這種高性能的服務來說是致命的，所以 Redis 是面向快速執(zhí)行場景的數(shù)據(jù)庫。

本文摘自 《Redis 開發(fā)運維》

總結(jié)

以上是生活随笔為你收集整理的Redis 高级特性（4）— 单线程架构的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。