一、為什么不用redis做主數(shù)據(jù)庫，只用它做緩存

1.Redis的內存架構

Redis是內存數(shù)據(jù)庫，這意味著它將所有數(shù)據(jù)存儲在內存中，而不是在硬盤上。這使得Redis的讀寫速度非常快，但也使得它非常適合存儲臨時數(shù)據(jù)，而不是持久數(shù)據(jù)。如果我們將Redis用作主數(shù)據(jù)庫，我們的數(shù)據(jù)將不能持久化，也就是說，如果服務器崩潰或斷電，我們將失去所有數(shù)據(jù)。這是因為Redis的數(shù)據(jù)存儲在內存中，一旦服務器重啟，內存中的數(shù)據(jù)將被清空，所有的數(shù)據(jù)將丟失。

2.Redis的單線程架構

Redis是單線程的，這意味著它一次只能處理一個請求。如果我們將Redis用作主數(shù)據(jù)庫，當并發(fā)請求增加時，Redis將無法處理它們，從而導致性能問題和響應時間延遲。相比之下，像MySQL這樣的關系型數(shù)據(jù)庫可以處理多個請求。如果我們有大量的并發(fā)請求需要處理，Redis可能會成為性能瓶頸。

3.Redis不支持SQL查詢

Redis不支持SQL查詢，這意味著我們無法使用SQL語言來查詢數(shù)據(jù)。雖然Redis提供了一些基本的查詢功能，但它無法處理復雜的查詢請求。相比之下，像MySQL這樣的關系型數(shù)據(jù)庫提供了強大的SQL查詢功能。如果我們需要進行復雜的查詢，Redis可能會無法勝任。

4.示例：Redis作為主數(shù)據(jù)庫可能會導致數(shù)據(jù)丟失

以下是一個簡單的示例，主要說明為什么使用Redis作為主數(shù)據(jù)庫可能會導致數(shù)據(jù)丟失。假設我們正在構建一個在線商店，并使用Redis來存儲庫存量。我們將商品數(shù)量存儲在Redis中，并在每次銷售后減少庫存量。如果我們使用Redis作為主數(shù)據(jù)庫，當服務器崩潰時，我們將失去所有庫存數(shù)據(jù)。如果我們使用MySQL等關系型數(shù)據(jù)庫，我們可以將庫存數(shù)據(jù)持久化并在服務器崩潰后恢復它們。

import redis

r = redis.Redis(host=’localhost’, port=6379, db=0)

# 假設我們有100個商品

r.set(‘inventory’, 100)

# 當有人購買一個商品時，我們減少庫存量

r.decr(‘inventory’)

# 當服務器崩潰并重啟時，我們將失去所有庫存數(shù)據(jù)

延伸閱讀：

二、主要的單機存儲引擎

1、哈希存儲：hash的CRUD是非?？斓摹５秉c是不支持順序掃描。bitcask是一個基于hash表結構的存儲系統(tǒng)。他將寫操作（包括刪除標識）追加到文件尾。并定期合并新老文件&記錄。

2、B樹：既支持隨機讀取又支持范圍查找的系統(tǒng)。查找時間復雜度為logd(n)（d為每個節(jié)點的出度）。Mysql的InnoDB的引擎和OS的文件系統(tǒng)使用的就是B+樹。（為什么選擇使用B樹的變種B+樹，讀者有興趣可以去探究下。提示：磁盤讀?。?/p>

3、LSM樹(Log Structured Merge Tree)：由B+數(shù)改進而來。其思想為：將增量寫操作保存在內存中，超過閾值時刷入磁盤，從而減少隨機寫磁盤操作。讀操作則需要合并磁盤數(shù)據(jù)和內存中的寫操作。通過Memtable/SSTable實現(xiàn)，實現(xiàn)細節(jié)在此不做深入探究。比較適合寫操作較多的業(yè)務場景。BigTable/HBase/Cassandra中的列簇的數(shù)據(jù)存儲方式采用的即是LSM樹。