一.介紹

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

二.發(fā)展史

2.1? 磁盤存儲

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

三.總結(jié)

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

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