Redis本身有固化機制，完全可以當作主資料庫使用，如果對事務要求不高的話。和MySQL配合用，可以把MySQL當作Redis後備庫，業務資料放在Redis中執行，用非同步方式寫入MySQL。Redis的優點是可以任意做映象，可以叢集。Redis當主庫使用，必須要保證至少一個異地Slave，防止主庫當機時丟失資料。

大聲反對樓下說的Redis做主庫。

Redis要求記憶體，你想想你們的資料量增長態勢，先算一下記憶體夠不夠用。

Redis的持久化有問題，想保證資料不丟時使用AOF模式（注：AOF持久化策略是將傳送到Redis服務端的每一條命令都記錄下來，並且儲存到硬碟中的AOF檔案中，類似打日誌檔案，來一條命令就記錄一條），策略為fsync always，這種的效能比Mysql還低！如果你喜歡它直觀的kv結構而對效能要求不高，或者效能要求很高，但允許一定程度的丟失資料，則可以用redis做為主資料庫。你真的考慮好了嗎？你能確定丟了什麼資料嗎？Redis做主資料庫是不靠譜的，並不是所有的資料都是立即回寫磁碟！

它適合小資料量重複查詢，實時要求高的地方，專案中主要是做快取記憶體和session狀態儲存等，其作為Nosql資料庫，多條件聯合查詢效率低，操作不便，主要資料結構不夠豐富，int,date之類也沒有，主庫還是採用成熟的Mysql比較好。

如何彌補不足？

主要是它適合儲存一些不是特別緊要的比如關注，粉絲關係，等等可以直接轉換為kv格式的資料，能夠避免頻繁查詢資料庫給資料庫造成的壓力。可以做一些資料聚合和統計工作，這些都允許少量的資料丟失，網站今天有12800人訪問和12795人訪問，對老闆來說都是一樣的。Redis還有特別的地理關係資料結構，適合做附近關係等等。

總結下來就是三方面，一方面做快取，扛住訪問關係型資料庫的壓力。二是做運營推廣時效性活動，資料聚合統計工作的，可以全放在Redis，有對應的資料結構可用。三是地理位置等特殊用途。

每種資料庫都有它合適的位置，眉毛鬍子一把抓不可取。

首先，如果應用程式的資料是儲存在MySQL或其它關係型資料庫中，那麼Redis可以作為前端資料庫處於應用程式和MySQL之間;

其次，還可以利用Redis來設計旁路讀出式和寫通式快取解決方案、會話儲存和速率限制器，這樣可以提高效能、加速創新，以更少的資源擴充套件來獲得最佳的使用者體驗。

Redis自身是可以做資料持久化的，很多同學都會想Redis應該可以替代MySQL，但是我們使用一項技術、一個框架的時候，不是看它能不能，而是要看它適合不適合。

所以大多數公司的儲存都是MySQL+Redis，MySQL（或者其他關係型資料庫）作為主儲存，Redis作為輔助儲存，被用作快取，這樣可以加快訪問讀取的速度，提高效能。

Redis被用作快取，以減少資料庫IO的讀操作，減輕資料庫的壓力，例如：

分散式鎖及單執行緒機制；

最新列表、排行榜：請不要使用select top 10 from xxxx。

很多時候，程式設計師習慣先查詢Redis，查詢不到的話再去查詢資料庫，能查到的話再寫入Redis中，認為這樣不僅緩解了資料庫的壓力，同時也能保證資料的準確性。

但是由於快取不命中就會查詢資料庫，如果一直查詢不到的話，就導致每次請求都會查詢資料庫，如果短時間內有大量這樣的請求，那麼資料庫可能會扛不住。

這就是快取穿透。

其實應對的方法也很簡單，查詢不到的資料，也快取到Redis中，並設定資料的過期時間。

舉個不一定恰當的例子，例如Redis中快取員工資訊，提供介面根據工號查詢員工資訊：

介面入參工號A001。

系統先在Redis中查詢，查詢不到。

系統去資料庫中查詢，也查詢不到。

系統插入Redis，key=A001，value=null，設定過期時間五分鐘。

這樣，五分鐘之內再根據A001查詢，不會穿透到資料庫。

四分鐘後，資料庫中插入了A001的資料。

五分鐘後，Redis中資料過期，下一次請求過來，會查詢資料庫，並把資訊載入到Redis中。

使用的就是Redis+MySql來互相輔助。

首先，我們必須承認Mysql作為關係型資料庫管理系統有其不可代替的優勢，主要體現在以下5個方面。

1 支援處理大量資料，量級可達到八位數

2 支援常見的SQL語句規範

3 可移植性強，安裝起來小巧方便

4 執行效率高

5 使用量大，能夠獲得廣泛的網路資訊支援

基於此，MySQL通常作為持久層，出現在各種web應用場景。

但是當表內資料量很大之後，如果不加索引，其查詢效率將有驚人的衰退。

我們通常預設查詢語句是毫秒級別的返回，但是我在實際工作中曾經遇到過一張包含10個欄位的表，900萬+條資料。當根據一個未加索引的欄位進行精確查詢的時候，單條sql語句的執行時長有時能夠達到2min以上，就更別提如果用like這種模糊查詢的話，其效率將會多麼低下。

也許你會說，那再對該欄位加一個索引好了。

如果你真的這麼做了，恭喜你，你踩了一個比大查詢還可怕的坑。

假設我們使用的Mysql已經是主從庫了，那麼大查詢語句執行很久時，卡住的頂多是從庫，主庫還是不受任何影響的。但是如果此時你又執行了增加索引操作，那麼主庫將會對這900萬+條資料依次操作增加索引，結果就是主庫從庫全部卡住，此時所有請求，不論增刪改查，全部hang住，等待查詢與增加索引操作執行結束。從使用者的角度，感受到的就是服務響應變慢，甚至超時。

在這種時刻，Redis的重要性就體現出來了。

Redis具有讀寫速度極快，支援多種儲存型別，支援事務以及分散式鎖的優勢。

與上面的侷限性結合起來看就可以看出，Redis能夠彌補MySQL讀寫慢的劣勢，對於一些無需持久化的資料，或者是在持久化之前會頻繁變動的資料，就可以選擇用Redis做快取。

舉個例子，我建立了一個任務資料Task，這個Task在最終完成寫入資料庫之前，有很多個步驟需要改變Task的屬性值，在這個過程中，將Task持久化資料庫是無意義的，反而會徒增很多讀寫的步驟，浪費執行時間。如果選擇在建立Task之後，就將其寫入資料庫與Redis，在中間過程，只讀寫Redis中Task的值，在完成Task之後，確認其值不會改變後，再持久化入MySql，就能夠極大的提高系統的效率。

這樣，就能夠將原本給Mysql的讀寫壓力，分配到了Redis上。

雖然Redis的讀寫速度優於MySQL，並且支援配置持久化，但是沒有任何一個對外應用匯選擇Redis來代替MySQL。

主要原因是Redis持久化資料是需要一定代價的。我們曾親身經驗過一次事件，我們一個服務的Redis節點誤開啟了持久化開關，重啟節點後，幾分鐘都無法讀取，最開始我們以為是伺服器的問題，網路問題，最後透過日誌才發現，是由於Redis重啟後，要load持久化的資料進來，儘管這個資料量遠遠小於MySQL儲存的資料，但是啟動時長卻用了分鐘級別。

此外，Redis不支援sql語句，當資料量增加後，其讀寫效率也會顯著下降等問題，也是它無法代替MySQL的原因。

綜上，最科學的方法是用MySQL+Redis的結合，分攤資料讀寫壓力，從而提高系統效率。

Mysql是一款開源免費，使用最多的非關係型資料庫，體積小，效能強大，查詢速度快！

但是大多數關係型資料庫的資料都是儲存在計算機硬碟上的，資料在磁碟存取的時候是機械操作，斷電不丟失資料，而記憶體是儲存電訊號，斷電就丟失資料，記憶體的存取速度比硬碟的存取速度快了很多很多！

mysql資料也是存在硬碟，存取速度相對於存在記憶體的redis有很大差距，在高併發環境，如果有瞬間的大量請求透過，則mysql會存在存取速度慢導致系統崩潰的情況！

比如說秒殺場景，在一秒鐘之內，有可能有數百萬的資料訪問，而mysql是完全不能處理的，對這種場景可使用記憶體型資料庫，比如redis，先將需要秒殺的商品ID存入到redis中，將商品ID和使用者的資訊非同步儲存到資料庫，減少資料庫的衝擊！

再比如一個場景，某個產品非常熱門，大量的客戶端在訪問這個產品的詳情，這時候可以把這個資料的詳情快取到redis中，可以減少大量的訪問資料庫，提升整個系統的吞吐效能！

由此可見，其實快取就是相當於資料庫的限流工具！

不過，快取加資料庫的果架構也會存在問題，如快取擊穿，快取穿透，快取雪崩，這些事故的發生可能是因為快取突然宕機，也可能是因為程式設定不當導致快取失效，進而大量的資料請求衝擊資料庫，引發資料庫崩潰！

針對這種情況，應該做到以下幾點：

1，儘量使用快取叢集，防止單機宕機引發的快取失效！

2，防止大量資料庫key同時失效的情況！

3，對key進行合理性檢驗，防止攻擊！(比如資料庫ID一般來說都是正整數吧，別人使用一個負數一直來查詢，這樣所有的請求都落在了資料庫)！