雙線程的程序可以支持每秒幾百萬的請求量，眾所周知，Redis作為被廣泛使用的內(nèi)存數(shù)據(jù)庫偏偏選擇了單線程模型，這又是為什么呢？其實簡單概括起來主要有以下三個原因，方便維護，可以并發(fā)的處理任務(wù)以及雙線程不能解決Redis的性能瓶頸。下面我們來仔細分析一下Redis選擇單線程模型的原因。
原因一：單線程模型更方便維護
相信我們都了解可維護性對一個項目的重要性，而Redis使用單線程模型能帶來更好的可維護性，方便開發(fā)和調(diào)試。如果代碼難以調(diào)試和測試，問題也經(jīng)常難以復(fù)現(xiàn)，這對于任何一個項目來說都會嚴重地影響項目的可維護性。多線程模型雖然在某些方面表現(xiàn)優(yōu)異，但是它卻引入了程序執(zhí)行順序的不確定性，代碼的執(zhí)行過程不再是串行的，多個線程同時訪問的變量如果沒有謹慎處理就會帶來詭異的問題。而多線程帶來的問題是很明顯的，如果計算機中的兩個進程（線程同理）同時嘗試修改一個共享內(nèi)存的內(nèi)容，在沒有并發(fā)控制的情況下，最終的結(jié)果依賴于兩個進程的執(zhí)行順序和時機，如果發(fā)生了并發(fā)訪問沖突，最后的結(jié)果就會是不正確的。
原因二：可以并發(fā)的處理任務(wù)。
雖然，Redis選擇了單線程模型，但是這也不影響它能并發(fā)的處理客戶端的請求。Redis服務(wù)中運行的絕大多數(shù)操作的性能瓶頸都不是CPU。用單線程模型也并不意味著程序不能并發(fā)的處理任務(wù)，Redis雖然使用單線程模型處理用戶的請求，但是它卻使用I/O多路復(fù)用機制并發(fā)處理來自客戶端的多個連接，同時等待多個連接發(fā)送的請求。在I/O多路復(fù)用模型中，最重要的函數(shù)調(diào)用就是select以及類似函數(shù)，該方法的能夠同時監(jiān)控多個文件描述符（也就是客戶端的連接）的可讀可寫情況，當其中的某些文件描述符可讀或者可寫時，select方法就會返回可讀以及可寫的文件描述符個數(shù)。使用I/O多路復(fù)用技術(shù)能夠極大地減少系統(tǒng)的開銷，系統(tǒng)不再需要額外創(chuàng)建和維護進程和線程來監(jiān)聽來自客戶端的大量連接，減少了服務(wù)器的開發(fā)成本和維護成本
原因三：雙線程不能解決Redis的性能瓶頸
這也是Redis選擇單線程模型的最核心的原因。雖然多線程技術(shù)的能夠幫助我們充分利用CPU的計算資源來并發(fā)的執(zhí)行不同的任務(wù)，但是CPU資源往往都不是Redis服務(wù)器的性能瓶頸。哪怕我們在一個普通的Linux服務(wù)器上啟動Redis服務(wù)，它也能在1s的時間內(nèi)處理1,000,000個用戶請求。
如果這種吞吐量不能滿足我們的需求，更推薦的做法是使用分片的方式將不同的請求交給不同的Redis服務(wù)器來處理，而不是在同一個Redis服務(wù)中引入大量的多線程操作。所以Redis并不是CPU密集型的服務(wù)，如果不開啟AOF備份，所有Redis的操作都會在內(nèi)存中完成不會涉及任何的I/O操作，這些數(shù)據(jù)的讀寫由于只發(fā)生在內(nèi)存中，所以處理速度是非常快的；整個服務(wù)的瓶頸在于網(wǎng)絡(luò)傳輸帶來的延遲和等待客戶端的數(shù)據(jù)傳輸，也就是網(wǎng)絡(luò)I/O，所以使用多線程模型處理全部的外部請求可能不是一個好的方案。
以上就是北大青鳥長沙麓谷校區(qū)java培訓(xùn)機構(gòu)的小編針對“Java數(shù)據(jù)庫開發(fā)教程，Redis選擇單線程模型”的內(nèi)容進行的回答，希望對大家有所幫助，如有疑問，請在線咨詢，有專業(yè)老師隨時為你服務(wù)。
