使用redis作為快取，資料還需要存入資料庫中嗎？

我的答案是：

1redis只是快取，不是資料庫如mysql，所以redis中有的資料庫，mysql中一定有。

2使用者請求先去請求redis，如果沒有，再去資料庫中去讀取。

3redis中快取一些請求量比較大的資料（這些快取資料，mysql中一定也是有的），沒必要所有資料都快取到redis中。

5之所以從快取中拿資料會快，是因為快取的資料存在於記憶體中，不像mysql的資料是存在磁碟上的，即不用經過從磁碟載入到記憶體這個過程（這個過程是非常耗時和低效的），直接從記憶體獲取資料。

6當redis快取崩潰的時候，那麼不是海量的請求都去訪問資料庫了？資料庫能抗住嗎？

1）收下要分析，當成千億個請求同時訪問過來，資料庫為什麼會扛不住？

①超大量的併發，資料庫扛不住。

舉個例子就明白了。

10000萬個plsql客戶端，同時訪問oracle進行資料庫查詢、寫入等操作，資料庫肯定吃不消。

參考：從這個角度來說，redis並不能幫什麼忙。

②資料庫存在低速裝置上，每次訪問資料庫，都要經過io，即從磁碟調入記憶體的過程。這個才是使用redis等快取機制的原因。

2）當redis奔潰了，成千億個請求同時訪問過來，資料庫扛不住，該怎麼辦？

*****解答某些同學的提問，核心是，redis中存的資料，資料庫中是否還要存的問題。

我的觀點：

1前提：mysql中存all即所有的資料（redis只是快取的mysql中的部分資料），redis中快取mysql中存在的訪問量超級大的資料。

2如果redis中沒有我要的資料，那麼其實這些請求併發量沒有那麼大（為什麼？參看上面的前提），那麼就去mysql訪問，肯定並沒有太大壓力。

反方觀點1：既然redis中存了，資料庫為什麼還要存呢？所以他們認為資料存入redis就不用存資料庫了。

反方觀點2：如果redis崩潰了，快取丟失了，不是所有的請求都壓到mysql了？mysql資料是存在硬碟上的，讀取是低速的，mysql肯定扛不住。

我的解答：

解答反方觀點1：這個不用爭，redis是當快取用的，不是當資料庫用的。

解答反方觀點2：我承認mysql這種情況下肯定扛不住，但是你全把資料放入redis風險不就更大了嗎？因為我雖然慢，但是最起碼沒有丟失，但是你redis是放入記憶體的，所有資料都丟失了？

反方觀點3：我的redis資料並沒有丟啊，redis有災備機制，因為redis會將其中的資料實時地存入磁碟，這樣就不怕丟了。

解答反方觀點3：那這不是回到我的思路上了嗎？你存磁碟其實跟存資料庫不是乙個道理嗎？方正都是存磁碟？你怎麼能將99g或者更大的資料快速的從磁碟載入到redis即記憶體中呢？不可能的。

所以，咱們兩種方式其實都是一樣的，都解決不了，如果redis即記憶體崩潰了，然後重啟redis之後，怎麼快速的響應千萬甚至過億的請求。

我的方式：redis壞了，從資料庫讀取。

你的方式：redis壞了，從磁碟慢慢地恢復到redis，然後從redis讀取。

反方觀點5：如果redis崩潰了，我不光可以放入磁碟一種方式，我還可以放入所在集群中的其他機器如b的記憶體中啊，這樣如果機器a的redis崩潰了，只需要去訪問機器b的記憶體中去取所需要的內容即可。

解答反方觀點5：①這種方式我沒研究過，集群，竟然記憶體也是共享的？②就算你說的是對的，我的那種方式，也完全可以融入你的機制，如果redis崩潰了，也將資料轉移到集群中的b的記憶體中。這樣的話，咱倆的方式其實就一樣了。

反方觀點6：你如果也採取我的那種方式，將資料轉移到集群中的其他機器的記憶體中，那麼為什麼還要再存入mysql中乙份呢，完全沒有必要，因為對於這部分資料，根本不會去mysql中去讀取的，一直是在redis中讀取就行了。

解答反方觀點6：你是對的，我無言以對。但是我質疑你說的將資料轉移到集群中其他機器上這種方式的可行性。

我對反方觀點5的質疑：照你你這種機制，其實就可以不用硬碟了，你用記憶體就行了，你可以把所有的資料都存入redis了，還將使用者等資訊放入mysql中幹什麼？

反方解答我的質疑：mysql中存的是不經常訪問的事情。

總結：的確，如果可以實現a機器崩潰時可以將redis中的資料轉移到集群中機器b的記憶體中（我對這種方式的可行性是質疑的），那麼，資料存入redis就可以不用存入mysql，但是這就顛覆了我及常人對快取的理解，這其實就不是什麼快取，而是直接將redis當資料庫來用了。

竟然還真有這種方式：