想搞明白這個問題，必須要先知道，什麼是redis，什麼是mysql，他們的各自優缺點是什麼

redis：是一種非關係kv記憶體資料庫（也就是常說的nosql），即將資料儲存在快取中，支援的資料型別比較多，比如字串，hash，list等快取的讀取速度快，能夠大大的提高執行效率，但是儲存時間有限。mysql：是關係型資料庫，主要用於存放持久化資料，將資料儲存在硬碟中，資料的格式是我們熟知的二維表格的樣式，關係型資料庫具有很多強大的功能，大部分都支援SQL語句查詢，對事務也有很好的支援。mysql和redis沒有競爭的關係，通常當併發訪問量比較大的時候，特別是讀操作很多，架構中可以引入redis，幫助提升架構的整體效能，減少mysql(或其他關係型資料庫)的壓力。

所以兩者是相互配合，而不是替代，因為Redis的效能十分優越，可以支援每秒十幾萬次的讀/寫操作，並且它還支援持久化、叢集部署、分散式、主從同步等，Redis在高併發的場景下資料的安全和一致性，所以它經常用於這些場景：

經常要被查詢，但是建立、更新、刪除等操作頻率低的資料；比如資料字典，確定了之後很少被修改，是可以放到快取中的；還有熱點資料，查詢極為頻繁的資料，放到redis中可以減少mysql的壓力；經常被查詢，但是實時性要求不高資料，比如購物網站的熱銷排行榜，定時統計一次後把統計結果放到redis中提供查詢 。快取還可以做資料共享（session共享），在分散式的架構中，把使用者的session資料放到redis中。高併發場景下的計數器，比如秒殺，把商品庫存數量放到redis中（秒殺的場景會比較複雜，redis只是其中之一，例如如果請求超過某個數量的時候，多餘的請求就會被限流）；因為redis對高併發的支援和單執行緒機智，它也經常用作分散式鎖；

redis雖然功能強大、效能高效，但是也不是萬能的，專案在引入redis的時候，需要考慮的問題也比較多，並且會帶來額外的開發和運維的工作量。

首先要判斷資料是否適合快取到redis中，可以從幾個方面考慮：資料會被經常查詢麼？命中率如何？寫操作多麼？資料大小？資料一致性如何保證？我們經常採用這樣的方式將資料刷到redis中：查詢的請求過來，現在redis中查詢，如果查詢不到，就查詢資料庫拿到資料，再放到快取中，這樣第二次相同的查詢請求過來，就可以直接在redis中拿到資料；不過要注意【快取穿透】的問題。快取的重新整理會比較複雜，通常是修改完資料庫之後，還需要對redis中的資料進行操作；程式碼很簡單，但是需要保證這兩步為同一事務，或最終的事務一致性。

兩者適用於不同的場景，誰也替代不了誰

redis主要用於熱點資料的快速查詢，資料要符合“查多改少”的特點，事務性差。

mysql儲存的結構化資料，強調資料的一致性，需要資料高度一致的場景還是要關係型資料庫出馬，電信運營商、金融等行業oracle還是主流解決方案。

這兩種資料庫，在檢索方式，儲存容量上，也是不一樣的。

MySQL是關係型資料庫，可以透過多欄位的檢索來確定資料，而且，基於硬碟的儲存，容量會大得多。

而Redis是kv資料庫，雖然支援多種資料結構，但是本質上，依然是kv。它的高效檢索是依賴於資料快取在記憶體當中的。不能進行多條件聯合檢索，也不支援like等檢索。

存在即合理，redis和關係型資料庫是共生關係

大型系統都會同時看到redis、關係型資料庫的身影，透過相互配合解決系統的高併發和資料的一致性。當然這裡面要考慮快取擊穿、快取雪崩、快取和資料庫的一致性等問題。

如何回答這類問題，基本上取決於這個問題出現在什麼場景下：場景一：面試可以考慮的回答：面試官你是認真的嗎？貴司是真的考慮要這麼幹還是已經這麼幹了？我感覺我的職業生涯規劃可能跟貴司的發展方向並不是非常匹配，所以，非常抱歉！我還有事，先走了。場景二：技術分享

在各位大佬噴我之前，請先讓我把話說完。

這個問題如果不是那麼認真地提出來的話，我還有可能會假裝認真地回答。

如果真有人認真地提出這個問題，我只能認為此人對待技術本身有點太不認真了。

當然，純屬個人看法。

好了，各位請隨便噴吧！反正我也不會回來看。

redis是不可以代替mysql進行資料儲存的。redis和mysql不應該是競爭的關係，而是一對好基友。在實際工作中針對不同的場景，根據redis和mysql的各自優點採用不同的儲存方案，合理的運用兩者才能達到理想的效果。

NoSQL是“Not Only SQL”的意思，本質上是跟SQL形成互補關係的應用。

之所以有“redis是否可以代替mysql進行資料儲存”這樣的疑問，一定是有很多人認為redis是可以替代mysql的。我也不可否認，在特定的場景下或者說小型web服務的場景下，redis確實可以替代mysql做資料儲存。但是這是有前提條件的，絕不能就可以說redis可以代替mysql進行資料儲存的。

Redis is an open source (BSD licensed), in-memory data structure store, used as a database, cache and message broker. It supports data structures such as strings, hashes, lists, sets, sorted sets with range queries, bitmaps, hyperloglogs, geospatial indexes with radius queries and streams. Redis has built-in replication, Lua scripting, LRU eviction, transactions and different levels of on-disk persistence, and provides high availability via Redis Sentinel and automatic partitioning with Redis Cluster.

上面是redis的官網描述，redis是一個基於BSD協議開源的記憶體資料庫，可用作資料庫、快取和訊息佇列，支援strings、hashes、lists、sets、sorted sets、bitmaps...等等資料結構。

每一種資料結構都有適合自己的應用場景，熟悉運用redis的各種資料結構，確實讓各位有一種錯覺“redis可以替代mysql”。

redis是基於記憶體儲存的，採用IO單路複用模型。一個字就是快！對於併發訪問量比較高的場景，使用redis可以避免流量直接衝向資料庫層。

下面是個人使用redis和mysql的一些心得：

redis存業務資料，mysql存更細粒度或者基於資料模型物件的資料，redis是中間快取層，mysql是資料儲存層。

mysql中like/in/and/or/join等資料查詢檢索redis是無法支援的，通常情況下，我們會以mysql資料為基礎資料，然後透過一系列的策略或者job跑出業務資料放到redis中儲存，這是二者結合使用的典型應用場景。

redis對事務的支援還是比較簡單的，所以很多複雜的資料落庫場景很難用redis去支援，即便可以支援，那也需要花費高昂的代價，這個時候你突然想起來有一個mysql好像可以完美的支援事務。

大部分的業務請求基本上就到redis這一層就結束了，如果查不到資料那就查不到，不會再去資料庫裡面去查了，所以也不用考慮“快取穿透”的問題。

redis中儲存的大部分資料是不過期的，所以也沒有“快取雪崩”的問題。

redis能夠讓你的業務執行的更快，mysql能夠讓你的資料更安全。

那麼問題來了，如何保證redis中儲存的業務資料能夠與mysql中儲存的資料保持一致呢？所以我們需要做一套資料一致性的方案來保證這個前提。

綜上，MySQL和redis各自有各自的應用場景，掌握好他們的特性，在不同的場景下應用最適合的儲存方案才是編碼之道。

這個完全取決於你對資料的要求，是否允許丟失，還是必須要求不允許丟失。我覺得就可以直接存放redis.如果使用者去網站買東西，這時候要記錄使用者的一個在網站操作的操作行為，（看了哪個商品、點選了哪個商品、點選了哪個按鈕）日誌，可以用來還原當時使用者的操作行為這個日誌的記錄是可以放在redis的，但是使用者下單、支付、配送資訊等這些是要保持強一致性，並且不允許丟失的所以需要存入mysql.當用戶下完單之後想看下自己的訂單詳情，這時候訂單詳情一些固定的資訊也是可以放redis的，所以redis和mysql是可以結合一起使用的。什麼事情都沒有絕對的，完全取決於你的業務要求。是業務驅動技術。

Redis本身是支援資料持久化的，很多有些程式設計師都會覺得Redis應該可以替代MySQL，但是我們在使用一項技術的時候，不是看它能不能，而是要看它適合不適合；而在大部分場景下，Redis是無法替代MySQL的。

MySQL是關係型資料庫，資料儲存在磁碟上，資料的格式是我們熟知的二維表格的樣式。關係型資料庫具有很多強大的功能；大部分都支援SQL語句查詢，對事務也有很好的支援。

Redis被稱作非關係型資料庫，屬於記憶體資料庫，資料都儲存在記憶體中（Redis有RDB持久化策略），Redis支援的資料型別也比較多，比如字串，HASH，List等。

MySQL和Redis沒有競爭的關係，通常當併發訪問量比較大的時候，特別是讀操作很多，架構中可以引入Redis，幫助提升架構的整體效能，減少Mysql(或其他關係型資料庫)的壓力；

不是MySQL or Redis；而是MySQL + Redis ；

因為Redis的效能十分優越，可以支援每秒十幾萬此的讀/寫操作，並且它還支援持久化、叢集部署、分散式、主從同步等，Redis在高併發的場景下資料的安全和一致性，所以它經常用於這些場景：

經常要被查詢，但是CUD操作頻率低的資料；比如資料字典，確定了之後很少被修改，是可以放到快取中的；還有熱點資料，查詢極為頻繁的資料，放到Redis中可以減少MySQL的壓力；

經常被查詢，但是實時性要求不高資料，比如購物網站的熱銷排行榜，定時統計一次後把統計結果放到Redis中提供查詢（請不要每次都使用select top 10 from xxxx）。

快取還可以做資料共享（Session共享），在分散式的架構中，把使用者的Session資料放到Redis中。

高併發場景下的計數器，比如秒殺，把商品庫存數量放到Redis中（秒殺的場景會比較複雜，Redis只是其中之一，例如如果請求超過某個數量的時候，多餘的請求就會被限流）；

因為Redis對高併發的支援和單執行緒機智，它也經常用作分散式鎖；

Redis雖然功能強大、效能高效，但是也不是萬能的，專案在引入Redis的時候，需要考慮的問題也比較多，並且會帶來額外的開發和運維的工作量。

首先要判斷資料是否適合快取到Redis中，可以從幾個方面考慮：資料會被經常查詢麼？命中率如何？寫操作多麼？資料大小？資料一致性如何保證？

我們經常採用這樣的方式將資料刷到Redis中：查詢的請求過來，現在Redis中查詢，如果查詢不到，就查詢資料庫拿到資料，再放到快取中，這樣第二次相同的查詢請求過來，就可以直接在Redis中拿到資料；不過要注意【快取穿透】的問題。

快取的重新整理會比較複雜，通常是修改完資料庫之後，還需要對Redis中的資料進行操作；程式碼很簡單，但是需要保證這兩步為同一事務，或最終的事務一致性。

首先可以明確一點的是：Redis可以對MySQL中的部分資料進行儲存，但Redis是無法代替MySQL來做資料儲存的。Redis是非關係型資料庫，MySQL是關係型資料庫，聽上去都是資料庫，但兩者的定位及應用場景是完全不同的。

為什麼會存在非關係型資料庫（NoSQL）？

我們知道，傳統的關係型資料庫都是持久化儲存的，資料是存放在硬碟中的。隨著資料量的擴大，無論是寫入還是查詢操作都會產生IO開銷。為了解決寫讀資料帶來的IO瓶頸就出現了NoSQL技術。

Redis非關係型資料庫的初衷及不足

Redis作為一種非關係型資料庫的代表，它是基於記憶體的高效能Key-Value資料庫。它支援每秒十幾萬次的讀寫操作，在讀寫效能上遠遠超過傳統的關係型資料庫。

Redis讀寫速度之所以這麼快，是因為它將資料直接存放在記憶體中進行操作的。但是問題也來了，如果使用Redis來做資料儲存，那記憶體開銷是相當大的，出於成本考慮我們一般只使用Redis來儲存熱點資料。

另外一方面，雖然Redis也支援資料持久化，但是Redis的資料查詢能力很差而且事務支援不完善。這樣一比較，在資料儲存能力上，Redis遠遠比不上MySQL這類關係型資料庫。

綜上，Redis一般都是配合MySQL來使用的，也無法代替MySQL來做資料持久儲存。

redis是nosql資料庫，擅長處理鍵值對(key, value)結構的資料，同時他還支援豐富的資料結構 set, map, list, zset

mysql擅長處理關係型資料

如果你的應用場景，僅限於儲存和簡單查詢，不去做複雜的關聯操作，並且能夠容忍一定的資料丟失的話，可以使用redis代替mysql。但是主流場景不這樣使用，redis主要用作熱點資料的快取，相當於快取一些讀多寫少的資料，用於降低mysql(後者其它關係型資料庫)的讀寫壓力。