Redis本身是支持數(shù)據(jù)持久化的，很多有些程序員都會覺得Redis應(yīng)該可以替代MySQL，但是我們在使用一項技術(shù)的時候，不是看它能不能，而是要看它適合不適合；而在大部分場景下，Redis是無法替代MySQL的。

• MySQL是關(guān)系型數(shù)據(jù)庫，數(shù)據(jù)儲存在磁盤上，數(shù)據(jù)的格式是我們熟知的二維表格的樣式。關(guān)系型數(shù)據(jù)庫具有很多強大的功能；大部分都支持SQL語句查詢，對事務(wù)也有很好的支持。
  

• Redis被稱作非關(guān)系型數(shù)據(jù)庫，屬于內(nèi)存數(shù)據(jù)庫，數(shù)據(jù)都儲存在內(nèi)存中（Redis有RDB持久化策略），Redis支持的數(shù)據(jù)類型也比較多，比如字符串，HASH，List等。
  

• MySQL和Redis沒有競爭的關(guān)系，通常當并發(fā)訪問量比較大的時候，特別是讀操作很多，架構(gòu)中可以引入Redis，幫助提升架構(gòu)的整體性能，減少Mysql(或其他關(guān)系型數(shù)據(jù)庫)的壓力；
  

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

因為Redis的性能十分優(yōu)越，可以支持每秒十幾萬此的讀/寫操作，并且它還支持持久化、集群部署、分布式、主從同步等，Redis在高并發(fā)的場景下數(shù)據(jù)的安全和一致性，所以它經(jīng)常用于這些場景：

1. 經(jīng)常要被查詢，但是CUD操作頻率低的數(shù)據(jù)；比如數(shù)據(jù)字典，確定了之后很少被修改，是可以放到緩存中的；還有熱點數(shù)據(jù)，查詢極為頻繁的數(shù)據(jù)，放到Redis中可以減少MySQL的壓力；
   

2. 經(jīng)常被查詢，但是實時性要求不高數(shù)據(jù)，比如購物網(wǎng)站的熱銷排行榜，定時統(tǒng)計一次后把統(tǒng)計結(jié)果放到Redis中提供查詢（請不要每次都使用select top 10 from xxxx）。
   

3. 緩存還可以做數(shù)據(jù)共享（Session共享），在分布式的架構(gòu)中，把用戶的Session數(shù)據(jù)放到Redis中。
   

4. 高并發(fā)場景下的計數(shù)器，比如秒殺，把商品庫存數(shù)量放到Redis中（秒殺的場景會比較復(fù)雜，Redis只是其中之一，例如如果請求超過某個數(shù)量的時候，多余的請求就會被限流）；
   

5. 因為Redis對高并發(fā)的支持和單線程機智，它也經(jīng)常用作分布式鎖；
   

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

1. 首先要判斷數(shù)據(jù)是否適合緩存到Redis中，可以從幾個方面考慮：數(shù)據(jù)會被經(jīng)常查詢么？命中率如何？寫操作多么？數(shù)據(jù)大小？數(shù)據(jù)一致性如何保證？
   

2. 我們經(jīng)常采用這樣的方式將數(shù)據(jù)刷到Redis中：查詢的請求過來，現(xiàn)在Redis中查詢，如果查詢不到，就查詢數(shù)據(jù)庫拿到數(shù)據(jù)，再放到緩存中，這樣第二次相同的查詢請求過來，就可以直接在Redis中拿到數(shù)據(jù)；不過要注意【緩存穿透】的問題。
   

3. 緩存的刷新會比較復(fù)雜，通常是修改完數(shù)據(jù)庫之后，還需要對Redis中的數(shù)據(jù)進行操作；代碼很簡單，但是需要保證這兩步為同一事務(wù)，或最終的事務(wù)一致性。
   

我將持續(xù)分享Java開發(fā)、架構(gòu)設(shè)計、程序員職業(yè)發(fā)展等方面的見解，希望能得到你的關(guān)注。

首先可以明確一點的是：Redis可以對MySQL中的部分數(shù)據(jù)進行存儲，但Redis是無法代替MySQL來做數(shù)據(jù)存儲的。Redis是非關(guān)系型數(shù)據(jù)庫，MySQL是關(guān)系型數(shù)據(jù)庫，聽上去都是數(shù)據(jù)庫，但兩者的定位及應(yīng)用場景是完全不同的。

數(shù)據(jù)庫的目的及功能

數(shù)據(jù)庫是專門用來存儲數(shù)據(jù)的地方，可以理解成是一個電子檔案館。數(shù)據(jù)庫需要具備最基本的新增、更新、查詢、刪除等操作，另外要在并發(fā)操作下保證數(shù)據(jù)的隔離性和一致性。

為什么會存在非關(guān)系型數(shù)據(jù)庫（NoSQL）？

我們知道，傳統(tǒng)的關(guān)系型數(shù)據(jù)庫都是持久化存儲的，數(shù)據(jù)是存放在硬盤中的。隨著數(shù)據(jù)量的擴大，無論是寫入還是查詢操作都會產(chǎn)生IO開銷。為了解決寫讀數(shù)據(jù)帶來的IO瓶頸就出現(xiàn)了NoSQL技術(shù)。

Redis非關(guān)系型數(shù)據(jù)庫的初衷及不足

Redis作為一種非關(guān)系型數(shù)據(jù)庫的代表，它是基于內(nèi)存的高性能Key-Value數(shù)據(jù)庫。它支持每秒十幾萬次的讀寫操作，在讀寫性能上遠遠超過傳統(tǒng)的關(guān)系型數(shù)據(jù)庫。

Redis讀寫速度之所以這么快，是因為它將數(shù)據(jù)直接存放在內(nèi)存中進行操作的。但是問題也來了，如果使用Redis來做數(shù)據(jù)存儲，那內(nèi)存開銷是相當大的，出于成本考慮我們一般只使用Redis來存儲熱點數(shù)據(jù)。

另外一方面，雖然Redis也支持數(shù)據(jù)持久化，但是Redis的數(shù)據(jù)查詢能力很差而且事務(wù)支持不完善。這樣一比較，在數(shù)據(jù)存儲能力上，Redis遠遠比不上MySQL這類關(guān)系型數(shù)據(jù)庫。

綜上，Redis一般都是配合MySQL來使用的，也無法代替MySQL來做數(shù)據(jù)持久存儲。

以上就是我的觀點，對于這個問題大家是怎么看待的呢？歡迎在下方評論區(qū)交流 ~ 我是科技領(lǐng)域創(chuàng)作者，十年互聯(lián)網(wǎng)從業(yè)經(jīng)驗，歡迎關(guān)注我了解更多科技知識！

redis是不可以代替mysql進行數(shù)據(jù)存儲的。redis和mysql不應(yīng)該是競爭的關(guān)系，而是一對好基友。在實際工作中針對不同的場景，根據(jù)redis和mysql的各自優(yōu)點采用不同的存儲方案，合理的運用兩者才能達到理想的效果。

NoSQL是“Not Only SQL”的意思，本質(zhì)上是跟SQL形成互補關(guān)系的應(yīng)用。

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

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的官網(wǎng)描述，redis是一個基于BSD協(xié)議開源的內(nèi)存數(shù)據(jù)庫，可用作數(shù)據(jù)庫、緩存和消息隊列，支持strings、hashes、lists、sets、sorted sets、bitmaps...等等數(shù)據(jù)結(jié)構(gòu)。

每一種數(shù)據(jù)結(jié)構(gòu)都有適合自己的應(yīng)用場景，熟悉運用redis的各種數(shù)據(jù)結(jié)構(gòu)，確實讓各位有一種錯覺“redis可以替代mysql”。

redis是基于內(nèi)存存儲的，采用IO單路復(fù)用模型。一個字就是快！對于并發(fā)訪問量比較高的場景，使用redis可以避免流量直接沖向數(shù)據(jù)庫層。

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

1. redis存業(yè)務(wù)數(shù)據(jù)，mysql存更細粒度或者基于數(shù)據(jù)模型對象的數(shù)據(jù)，redis是中間緩存層，mysql是數(shù)據(jù)存儲層。

2. mysql中l(wèi)ike/in/and/or/join等數(shù)據(jù)查詢檢索redis是無法支持的，通常情況下，我們會以mysql數(shù)據(jù)為基礎(chǔ)數(shù)據(jù)，然后通過一系列的策略或者job跑出業(yè)務(wù)數(shù)據(jù)放到redis中存儲，這是二者結(jié)合使用的典型應(yīng)用場景。
   

3. redis對事務(wù)的支持還是比較簡單的，所以很多復(fù)雜的數(shù)據(jù)落庫場景很難用redis去支持，即便可以支持，那也需要花費高昂的代價，這個時候你突然想起來有一個mysql好像可以完美的支持事務(wù)。

4. 大部分的業(yè)務(wù)請求基本上就到redis這一層就結(jié)束了，如果查不到數(shù)據(jù)那就查不到，不會再去數(shù)據(jù)庫里面去查了，所以也不用考慮“緩存穿透”的問題。

5. redis中存儲的大部分數(shù)據(jù)是不過期的，所以也沒有“緩存雪崩”的問題。

6. redis能夠讓你的業(yè)務(wù)運行的更快，mysql能夠讓你的數(shù)據(jù)更安全。

7. 那么問題來了，如何保證redis中存儲的業(yè)務(wù)數(shù)據(jù)能夠與mysql中存儲的數(shù)據(jù)保持一致呢？所以我們需要做一套數(shù)據(jù)一致性的方案來保證這個前提。

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

歡迎大家積極參與討論，一起學(xué)習(xí)，共同成長~

Mysql是關(guān)系型數(shù)據(jù)庫，而NOSQL譬如redis通常都是弱關(guān)系，如果你的數(shù)據(jù)相互之間關(guān)系非常弱，哪自然可以使用redis,反之如果你是強關(guān)系，使用redis則需要自己實現(xiàn)上層的數(shù)據(jù)模型關(guān)系，祝你好運

基本上，作為一個靠開發(fā)維持生活的人，看到此類比較什么比什么好、什么能不能代替什么的問題，基本上會判定為是初學(xué)者的無聊撕逼，這種情況都是直接略過。但是，偶爾這些問題也會出自某些資深同行之口，那么可以分情況討論。

如何回答這類問題，基本上取決于這個問題出現(xiàn)在什么場景下：
場景一：面試
可以考慮的回答：面試官你是認真的嗎？貴司是真的考慮要這么干還是已經(jīng)這么干了？我感覺我的職業(yè)生涯規(guī)劃可能跟貴司的發(fā)展方向并不是非常匹配，所以，非常抱歉！我還有事，先走了。
場景二：技術(shù)分享

可以考慮拒絕回答。而且如果是公司內(nèi)部的技術(shù)分享，基本上可以考慮找下家了。討論這種問題的公司要么是太牛逼而毫無生存壓力，要么是太垃圾而毫無生存機會。前者的可能性不會太大。所以，走為上策吧！

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

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

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

當然，純屬個人看法。

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

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

redis主要用于熱點數(shù)據(jù)的快速查詢，數(shù)據(jù)要符合“查多改少”的特點，事務(wù)性差。

mysql存儲的結(jié)構(gòu)化數(shù)據(jù)，強調(diào)數(shù)據(jù)的一致性，需要數(shù)據(jù)高度一致的場景還是要關(guān)系型數(shù)據(jù)庫出馬，電信運營商、金融等行業(yè)oracle還是主流解決方案。

這兩種數(shù)據(jù)庫，在檢索方式，存儲容量上，也是不一樣的。

MySQL是關(guān)系型數(shù)據(jù)庫，可以通過多字段的檢索來確定數(shù)據(jù)，而且，基于硬盤的存儲，容量會大得多。

而Redis是kv數(shù)據(jù)庫，雖然支持多種數(shù)據(jù)結(jié)構(gòu)，但是本質(zhì)上，依然是kv。它的高效檢索是依賴于數(shù)據(jù)緩存在內(nèi)存當中的。不能進行多條件聯(lián)合檢索，也不支持like等檢索。

存在即合理，redis和關(guān)系型數(shù)據(jù)庫是共生關(guān)系

大型系統(tǒng)都會同時看到redis、關(guān)系型數(shù)據(jù)庫的身影，通過相互配合解決系統(tǒng)的高并發(fā)和數(shù)據(jù)的一致性。當然這里面要考慮緩存擊穿、緩存雪崩、緩存和數(shù)據(jù)庫的一致性等問題。

總之，兩者是相輔相成的，歡迎探討。

不可以，存儲數(shù)據(jù)類型不一樣，都是開源數(shù)據(jù)庫，用redis 代替mysql沒意義

想搞明白這個問題，必須要先知道，什么是redis，什么是mysql，他們的各自優(yōu)缺點是什么

• redis：是一種非關(guān)系kv內(nèi)存數(shù)據(jù)庫（也就是常說的nosql），即將數(shù)據(jù)存儲在緩存中，支持的數(shù)據(jù)類型比較多，比如字符串，hash，list等緩存的讀取速度快，能夠大大的提高運行效率，但是保存時間有限。
• mysql：是關(guān)系型數(shù)據(jù)庫，主要用于存放持久化數(shù)據(jù)，將數(shù)據(jù)存儲在硬盤中，數(shù)據(jù)的格式是我們熟知的二維表格的樣式，關(guān)系型數(shù)據(jù)庫具有很多強大的功能，大部分都支持SQL語句查詢，對事務(wù)也有很好的支持。
• mysql和redis沒有競爭的關(guān)系，通常當并發(fā)訪問量比較大的時候，特別是讀操作很多，架構(gòu)中可以引入redis，幫助提升架構(gòu)的整體性能，減少mysql(或其他關(guān)系型數(shù)據(jù)庫)的壓力。

所以兩者是相互配合，而不是替代，因為Redis的性能十分優(yōu)越，可以支持每秒十幾萬次的讀/寫操作，并且它還支持持久化、集群部署、分布式、主從同步等，Redis在高并發(fā)的場景下數(shù)據(jù)的安全和一致性，所以它經(jīng)常用于這些場景：

1. 經(jīng)常要被查詢，但是創(chuàng)建、更新、刪除等操作頻率低的數(shù)據(jù)；比如數(shù)據(jù)字典，確定了之后很少被修改，是可以放到緩存中的；還有熱點數(shù)據(jù)，查詢極為頻繁的數(shù)據(jù)，放到redis中可以減少mysql的壓力；
2. 經(jīng)常被查詢，但是實時性要求不高數(shù)據(jù)，比如購物網(wǎng)站的熱銷排行榜，定時統(tǒng)計一次后把統(tǒng)計結(jié)果放到redis中提供查詢 。
3. 緩存還可以做數(shù)據(jù)共享（session共享），在分布式的架構(gòu)中，把用戶的session數(shù)據(jù)放到redis中。
4. 高并發(fā)場景下的計數(shù)器，比如秒殺，把商品庫存數(shù)量放到redis中（秒殺的場景會比較復(fù)雜，redis只是其中之一，例如如果請求超過某個數(shù)量的時候，多余的請求就會被限流）；
5. 因為redis對高并發(fā)的支持和單線程機智，它也經(jīng)常用作分布式鎖；

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

1. 首先要判斷數(shù)據(jù)是否適合緩存到redis中，可以從幾個方面考慮：數(shù)據(jù)會被經(jīng)常查詢么？命中率如何？寫操作多么？數(shù)據(jù)大小？數(shù)據(jù)一致性如何保證？
2. 我們經(jīng)常采用這樣的方式將數(shù)據(jù)刷到redis中：查詢的請求過來，現(xiàn)在redis中查詢，如果查詢不到，就查詢數(shù)據(jù)庫拿到數(shù)據(jù)，再放到緩存中，這樣第二次相同的查詢請求過來，就可以直接在redis中拿到數(shù)據(jù)；不過要注意【緩存穿透】的問題。
3. 緩存的刷新會比較復(fù)雜，通常是修改完數(shù)據(jù)庫之后，還需要對redis中的數(shù)據(jù)進行操作；代碼很簡單，但是需要保證這兩步為同一事務(wù)，或最終的事務(wù)一致性。

redis是nosql數(shù)據(jù)庫，擅長處理鍵值對(key, value)結(jié)構(gòu)的數(shù)據(jù)，同時他還支持豐富的數(shù)據(jù)結(jié)構(gòu) set, map, list, zset

mysql擅長處理關(guān)系型數(shù)據(jù)

如果你的應(yīng)用場景，僅限于存儲和簡單查詢，不去做復(fù)雜的關(guān)聯(lián)操作，并且能夠容忍一定的數(shù)據(jù)丟失的話，可以使用redis代替mysql。但是主流場景不這樣使用，redis主要用作熱點數(shù)據(jù)的緩存，相當于緩存一些讀多寫少的數(shù)據(jù)，用于降低mysql(后者其它關(guān)系型數(shù)據(jù)庫)的讀寫壓力。

緩存數(shù)據(jù)庫怎么替代物理數(shù)據(jù)庫