一.介紹

? ? ? 為什么會(huì)出現(xiàn)Redis這個(gè)中間件，從原始的磁盤存儲(chǔ)到Redis中間又發(fā)生了哪些事，下面進(jìn)入正題

二.發(fā)展史

2.1? 磁盤存儲(chǔ)

最早的時(shí)候都是以磁盤進(jìn)行數(shù)據(jù)存儲(chǔ)，每個(gè)磁盤都有一個(gè)磁道。每個(gè)磁道有很多扇區(qū)，一個(gè)扇區(qū)接近512Byte。

那要從磁盤中讀取數(shù)據(jù)，有兩個(gè)指標(biāo)很重要就是：尋址速度 和 帶寬

磁盤：尋址速度是ms的，帶寬是GB/M的。

內(nèi)存：尋址速度是ns級(jí)的，帶寬也比磁盤大上好幾個(gè)數(shù)量級(jí)。

結(jié)論：磁盤比內(nèi)存在尋址上慢了接近10W倍。

當(dāng)數(shù)據(jù)文件很大的時(shí)候，存儲(chǔ)的時(shí)候我們的面臨的問(wèn)題是，I/O問(wèn)題。在讀寫文件時(shí)，我們常常面臨很大的I/O成本問(wèn)題。但是最初的解決方案是加一個(gè)buffer。

I/O 成本問(wèn)題是指：假設(shè) 1T的數(shù)據(jù)存儲(chǔ)在硬盤，每個(gè)扇區(qū)512Byte，上層創(chuàng)建很大的索引才能索引住每個(gè)扇區(qū)數(shù)據(jù)。操作系統(tǒng)無(wú)論都多少，都是最少?gòu)?k拿

總結(jié)：數(shù)據(jù)很大的時(shí)候，I/O 會(huì)越慢，最終磁盤會(huì)成為瓶頸。

2.2 數(shù)據(jù)庫(kù)時(shí)代

? ?當(dāng)關(guān)系型數(shù)據(jù)庫(kù)出現(xiàn)，創(chuàng)建了一個(gè)data page 概念，data page? 大小是4k，這個(gè)4k和磁盤的4k對(duì)應(yīng)上，正好是一次 I/O.

? ? 數(shù)據(jù)存儲(chǔ)在數(shù)據(jù)庫(kù)的時(shí)候，就是很多4k的data page 小格子，如果只存數(shù)據(jù)不建索引，數(shù)據(jù)的讀取還是會(huì)很慢，因?yàn)樽x取的時(shí)候都是全量I/O.所以關(guān)系型數(shù)據(jù)庫(kù)會(huì)再創(chuàng)建4k的索引，提高查詢的效率，索引的 結(jié)構(gòu)是B+樹。

B+樹是B樹的一種變體，也屬于平衡多路查找樹，大體結(jié)構(gòu)與B樹相同，包含根節(jié)點(diǎn)、內(nèi)部節(jié)點(diǎn)和葉子節(jié)點(diǎn)。多用于數(shù)據(jù)庫(kù)和操作系統(tǒng)的文件系統(tǒng)中，由于B+樹內(nèi)部節(jié)點(diǎn)不保存數(shù)據(jù)，所以能在內(nèi)存中存放更多索引，增加緩存命中率。另外因?yàn)槿~子節(jié)點(diǎn)相連遍歷操作很方便，而且數(shù)據(jù)也具有順序性，便于區(qū)間查找

? ? ? 創(chuàng)建表的時(shí)候，每個(gè)列會(huì)設(shè)定數(shù)據(jù)類型，數(shù)據(jù)類型決定了字節(jié)寬度，當(dāng)所有列的類型確定，則一行的數(shù)據(jù)寬度是固定的，往4k的data page 里面整體存儲(chǔ)，所以數(shù)據(jù)庫(kù)傾向于行級(jí)存儲(chǔ)，好處就是修改數(shù)據(jù)的時(shí)候不需要移動(dòng)數(shù)據(jù)，在原本的位置復(fù)寫就可以了。

? ? ?數(shù)據(jù)和索引都是在磁盤里，select 語(yǔ)句的where 條件命中內(nèi)存的B+樹的樹干，然后走索引讀取數(shù)據(jù)到內(nèi)存里，內(nèi)存是比較快的。

? 2.3?key-value數(shù)據(jù)庫(kù)的產(chǎn)生

? ? ?我們將數(shù)據(jù)庫(kù)發(fā)展到極致，產(chǎn)生出類似SAP公司的HANA數(shù)據(jù)庫(kù)。這種數(shù)據(jù)庫(kù)，硬件需求大，內(nèi)存約2T，硬件服務(wù)費(fèi)很貴。不適合小中型公司選擇。

隨著互聯(lián)網(wǎng)的發(fā)展，我們面臨了一個(gè)新的問(wèn)題。如何才能抵擋高并發(fā)，大數(shù)據(jù)量導(dǎo)致的查找變慢呢？（注意，數(shù)據(jù)量變大，僅僅影響多范圍數(shù)據(jù)查找，單主鍵索引數(shù)據(jù)查找并不會(huì)影響性能。我們的業(yè)務(wù)邏輯，通常是多條數(shù)據(jù)查找，所以才會(huì)有瓶頸）

于是我們的k-v數(shù)據(jù)庫(kù)產(chǎn)生了，redis 應(yīng)運(yùn)而生。

三.總結(jié)

? ? ?redis的誕生，解決了應(yīng)對(duì)實(shí)際業(yè)務(wù)中對(duì)高并發(fā)，大數(shù)量業(yè)務(wù)，提供更豐富API使用以及豐富多樣的數(shù)據(jù)結(jié)構(gòu)。后續(xù)會(huì)從數(shù)據(jù)結(jié)構(gòu)開始，一步步揭開redis的面紗。

如有侵權(quán)請(qǐng)聯(lián)系 刪除，謝謝。