Redis 產生背景
1.1.數據存儲的發展史
1.1.1.磁盤時代
很久之前，我們的數據存儲方式是磁盤存儲，每個磁盤都有一個磁道。每個磁道有很多扇區，一個扇區接近512Byte。
磁盤的尋址速度是毫秒級的，帶寬是GB/M的。內存是ns級的，帶寬也比磁盤大上好幾個數量級。總體來說，磁盤比內存在尋址上慢了接近10W倍。
在這段歷史中，我們的面臨的問題是，I/O問題。在讀寫文件時，我們常常面臨很大的I/O成本問題。但是最初有個最初的解決方案是加一個buffer。
科普：什么是buffer？
buffer是指一個緩沖區，我們在緩沖區來進行一個暫時的存放，之后統一運輸給內存，這樣會使得I/O的性能有略微提升。
1.1.2.數據庫的產生
任何技術都不會平白無故產生。
我們數據庫技術就是由於磁盤的I/O瓶頸。為了解決這個問題，我們將磁盤扇區分為4K的一個個小的分區，構成索引。有了這些索引值，我們能通過索引，進行更加便捷的查找。為了我們能夠更快的查找，我們將索引使用B+樹進行存儲。
科普：B+樹是什么？
我們普通的1-0樹，又稱二叉查找樹（二叉排序樹），二叉查找樹和排序樹是同一種樹，就是單純的1-0樹，按照中序遍歷的存儲方式進行從小到大（從大到小）進行存儲。（初學者可能誤以為兩種樹，包括我剛開始學習數據結構的時候）。
二叉查找樹（二叉排序樹）由於在插入和刪除的時候，容易出現不太ok的情況，例如，可能在刪除過程中刪除為一個鏈表，這樣查找效率依舊會變得很低。所以，我們使用旋轉，通過左右旋轉，將這種“鏈表”式（極端情況下）的樹轉化為左右平衡的樹，這就是所謂的B-樹。（注意誤區，B樹和B-樹是一個樹么？初學者認為后面一種是B減樹，實際不是，是翻譯過來的時候加的分隔符。B為Balance平衡的意思）
當然，我們的數據庫文件不是二叉的，文件系統也不是，所以，我們多叉的查找樹，就是所謂的B+樹。+號代表每個節點不止二叉的意思。
（用自己的話粗略總結，詳細還是看B-tree，B+tree的定義）
在我們數據庫的查找中，我們遇到一個問題？那就是字節寬度問題。我們建庫的時候必須給出schema，我們行級存儲，即使是該列為空，依舊要占位，那么，數據量龐大的時候，將會浪費很大的存儲空間。但是這樣的好處是，我們可以在update的時候不需要移動數據的位置。
1.1.3.key-value數據庫的產生
任何技術都不會平白無故產生。
我們將數據庫發展到極致，產生出類似SAP公司的HANA數據庫。這種數據庫，硬件需求大，內存約2T，硬件軟件服務總和約2億一個套餐。
隨着互聯網的發展，我們面臨了一個新的問題。如何才能抵擋高並發，以及大數據導致的查找變慢呢？（注意，數據量變大，僅僅影響多數據查找，單數據查找並不會影響性能。我們的業務邏輯，通常是多條數據查找，所以才會有瓶頸）
於是我們的k-v數據庫產生了，這依賴於兩個基礎設施。馮諾依曼體系的硬件，以太網，和tcp/ip網絡。參考附件：馮諾依曼體系圖
科普：什么是馮諾依曼體系？
我們的操作系統老師是個年紀很大的教授，這邊引用他的上課原話。
馮諾依曼體系，至今沒有一個明確的定義。有的書說有5個，有的書說有7個，但是，我依照某年考研題，來規范一下馮諾依曼體系。
馮諾依曼體系由五部分組成，控制器，運算器，內存，總線，硬盤和I/O接口6部分組成。
（如何記憶馮諾依曼體系構成：CPU分為控制器運算器，其他都為CPU服務，運算需要內存，連接需要總線，我們要讀寫必須要I/O接口。一切以CPU考慮，就能記全6個）
參考附件：馮諾依曼體系圖
