redis為什么這么快 自己總結(jié)的幾個點
一. 基本常識
-
在計算機中饵史，數(shù)據(jù)是存儲在磁盤中的
磁盤的時間單位
a. 尋址: ms
b. 帶寬: G/M內(nèi)存的時間單位
a. 尋址: ns時間單位組成
秒 > 毫秒 > 微秒 > 納秒
在尋址上满钟，磁盤比內(nèi)存慢了10w倍
-
I/O buff：成本問題
關(guān)系型數(shù)據(jù)庫隨著文件變大胜榔，速度變慢，為什么湃番？
硬盤I/O成為瓶頸
磁盤有磁道和扇區(qū)夭织，一個扇區(qū)512byte，容器小就帶來了成本變大：索引
操作系統(tǒng)一次性會讀取4k的數(shù)據(jù)吠撮，就算你只要1k尊惰，操作系統(tǒng)也會一次性從磁盤讀取4k
所以mysql的文件設(shè)計的頁data page也是4k, 剛好滿足操作系統(tǒng)一次讀取的大小，但是當(dāng)文件增大之后泥兰，就 會出現(xiàn)很多的data page頁弄屡，這個時候，查詢速度就會變慢鞋诗，此時就使用了索引 b+樹膀捷。(為什么使用b+樹 等寫mysql相關(guān)時再說)
-
所以， 當(dāng)數(shù)據(jù)庫表很大的時候削彬，表文件就會很大担孔，性能下降，下降的原因
- 如果有索引吃警，增刪改的時候會維護索引糕篇，速度會變慢
- 查詢速度
a. 1個或少量查詢時依然很快
b. 并發(fā)大的時候會受到硬盤帶寬的限制影響速度
二. epoll
- IO的發(fā)展歷程
在操作系統(tǒng)中，每一個I/O都視為一個文件描述符fd
-
BIO
- BIO的流程酌心，大致可以描述為以下場景
- 幼兒園（進程）
- 小朋友(文件描述符fd)
- 老師（線程）
- 每一個小朋友需要配一名老師拌消，每個老師會詢問對應(yīng)的小朋友，要不要上廁所（I/O操作）安券，這種操作造成了系統(tǒng)資源的極大浪費
- jvm：一個線程的成本 1MB
a. 線程多了產(chǎn)生調(diào)度成本 cpu不停切換線程浪費
b. 內(nèi)存成本增大
- BIO的流程酌心，大致可以描述為以下場景
-
NIO
- NIO的流程可以描述成這樣
- 幼兒園聘請一個老師墩崩，死循環(huán)的去詢問每一個小朋友（select(Nfd)），要不要上廁所（I/O操作）侯勉，此時就不會浪費系統(tǒng)資源
- 但此時還是存在一些問題
a. 當(dāng)小朋友很多的時候鹦筹，一個老師循環(huán)問一遍小朋友就需要花很長的時間
b. 當(dāng)小朋友要上廁所的時候，需要把小朋友從教室（內(nèi)核）帶到廁所（用戶空間） 整體行為=拷貝fd相關(guān)數(shù)據(jù)
-
epoll
- epoll是linux系統(tǒng)中對nio多路復(fù)用的優(yōu)化址貌；
- nio是進程用戶態(tài)中循環(huán)讀取所有的文件描述符進行處理铐拐，如果文件描述符過多的話，循環(huán)遍歷的速度會受到限制练对，并且中間也有從內(nèi)核中讀取的過程遍蟋；
- epoll使用了一個用戶態(tài)和內(nèi)核態(tài)的共享空間MMAP，將文件描述符都放在共享空間的紅黑樹中螟凭，如果有某個連接發(fā)生事件虚青，就將連接加入到共享空間的鏈表中,然后由用戶態(tài)進行操作
-
最終總結(jié)
為什么redis快
1. 單線程操作，沒有事務(wù)
2. 直接操作內(nèi)存螺男，不受磁盤IO影響
3. 使用了linux中的epoll對網(wǎng)絡(luò)IO進行優(yōu)化
