Redis本身是支持?jǐn)?shù)據(jù)持久化的，很多有些程序員都會(huì)覺得Redis應(yīng)該可以替代MySQL，但是我們?cè)谑褂靡豁?xiàng)技術(shù)的時(shí)候，不是看它能不能，而是要看它適合不適合；而在大部分場(chǎng)景下，Redis是無(wú)法替代MySQL的。

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

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

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

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

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

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

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

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

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

5. 因?yàn)镽edis對(duì)高并發(fā)的支持和單線程機(jī)智，它也經(jīng)常用作分布式鎖；
   

Redis雖然功能強(qiáng)大、性能高效，但是也不是萬(wàn)能的，項(xiàng)目在引入Redis的時(shí)候，需要考慮的問題也比較多，并且會(huì)帶來(lái)額外的開發(fā)和運(yùn)維的工作量。

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

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

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

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

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

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

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

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

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

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

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

Redis讀寫速度之所以這么快，是因?yàn)樗鼘?shù)據(jù)直接存放在內(nèi)存中進(jìn)行操作的。但是問題也來(lái)了，如果使用Redis來(lái)做數(shù)據(jù)存儲(chǔ)，那內(nèi)存開銷是相當(dāng)大的，出于成本考慮我們一般只使用Redis來(lái)存儲(chǔ)熱點(diǎn)數(shù)據(jù)。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

在各位大佬噴我之前，請(qǐng)先讓我把話說(shuō)完。

這個(gè)問題如果不是那么認(rèn)真地提出來(lái)的話，我還有可能會(huì)假裝認(rèn)真地回答。

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

當(dāng)然，純屬個(gè)人看法。

好了，各位請(qǐng)隨便噴吧！反正我也不會(huì)回來(lái)看。

兩者適用于不同的場(chǎng)景，誰(shuí)也替代不了誰(shuí)

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

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

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

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

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

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

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

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

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

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

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

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

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

redis雖然功能強(qiáng)大、性能高效，但是也不是萬(wàn)能的，項(xiàng)目在引入redis的時(shí)候，需要考慮的問題也比較多，并且會(huì)帶來(lái)額外的開發(fā)和運(yùn)維的工作量。

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

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

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

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

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