依黛
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中的數據進行操作；代碼很簡單，但是需要保證這兩步為同一事務，或最終的事務一致性。
我將持續分享Java開發、架構設計、程序員職業發展等方面的見解，希望能得到你的關注。
會點代碼的大叔
完全可以，但要注意幾點：
一、REDIS的兩種固化機制，RDB和AOF，都不適合存儲大量數據，RDB是全量鏡像數據越多對磁盤消耗越大。AOF是增量備份，讀寫效率比一般關係型數據庫低。
二、REDIS運行時所有數據加載到內存中，數據不能無限增長，會耗盡內存，物理內存耗盡之後，Redis就沒有速度優勢了。
三、沒有事務機制，沒有數據完整性保障，不適合存放對完整性要求很高的數據。
光明右使8787
Redis能不能代替MySQL進行數據存儲？怎麼樣？
這個問題首先得分析應用的場景，技術本身是為業務服務的，不同的場景有著不同的解決方案。一項技術和另一項技術並沒有好不好的區分，只有合不合適的區別。但是就目前的應用場景來說，大部分時候Redis是沒有辦法取代MySQL或其他關係型數據庫的。
從兩者差異性來看
- 類型
從兩者的類型來看，MySQL屬於關係型數據庫，採用了關係模型來組織數據，由行和列構成，可以簡單的理解為二維數組或表格。
而Redis屬於非關係型數據庫，大多數以哈希表中鍵值對的方式存儲，非關係型數據庫不保證滿足ACID的特性。
- 存儲
從存儲來看，MySQL的數據存儲在磁盤中，以InnorDB為例，數據庫文件默認單頁大小一般為16K，數據一般會以拆分開的文件形式存儲在磁盤。
而Redis採用的是純內存存儲，內存的讀寫速度和尋址方式和磁盤相比有較大差異，這也是Redis為什麼這麼快和能達到較高併發的主要原因之一。
- 性能
從性能上來看，MySQL因為採用的是磁盤存儲，不論是在讀還是寫的情況下都不能避免會進行磁盤尋址，所以從單命令的執行效率上來說，MySQL的性能還是和Redis有所差距的。但是，如果延伸到複雜的查詢，那兩者在性能上就各有所長了。
- 查詢
MySQL採用的磁盤存儲，本身關係型數據庫的特徵結合索引的方式，能更好的支持多種情況的複雜查詢。以InnorDB引擎為例，其索引類型分為哈希索引和B+樹索引。哈希索引的查詢效率除了磁盤和內存的性能差距外，時間複雜度上並無其他差距。而B+樹索引無論是聚簇索引還是非聚簇索引，MySQL對於持有索引的複雜條件查詢，明顯優於Redis。Redis是很難做到多條件或複雜條件查詢的。
孰好孰壞
MySQL和Redis，實際上並不是誰取代誰的問題，現在的應用群來說，兩者結合構建高容錯、高併發的系統是兩者之間最好的結合方式。
Redis性能卓越，往往被用來放置在MySQL集群之前增加系統整體的處理性能，擋住大量打往數據庫的流量。
而MySQL因為查詢、存儲方面的優勢，往往用於系統最為核心的存儲和查找實現。Redis因為基於內存，所以在持久化上採用RDB和AOF兩種方式，而我們往往兩者相結合，但是在容差方面和MySQL天生的存儲相比還是略顯不足。
另外，由於Redis不保證具備ACID特性，在事務處理上會略顯不足，雖然可以通過類似存儲過程一次執行多個命令的方式實現事務，但是在回滾機制等處理上需要客戶端進行約束，略顯不足。
當然，實際場景中兩者還有很多其他方面的差異，這裡就不一一細說了，請參照使用場景。
使用場景
1. 熱點數據
Redis往往用於存儲熱點且實時性要求略低的數據，用於攔截大部分的核心流量，從而降低數據庫的IO瓶頸。
2. 頻繁寫
如果是頻繁寫的場景，Redis的用處明顯不如頻繁讀。而且往往這種情況下我們還需要更多的考慮數據庫和緩存間的數據同步，避免髒讀等情況的產生。所以如果是頻繁寫的場景，如果是非實時性同步場景，隊列的使用往往優先於緩存。
3. 分佈式鎖
就目前的分佈式系統來說，Redis和Zookeeper通常是被用於分佈式鎖的方案，通過Redis的setNX命令和Redis集群的Redlock實現分佈式鎖，用於協同不同系統間對於同一資源的競爭。
4. 其他
除了以上，Redis還經常用於秒殺場景下的計數器、Set集合實現好友關係管理、SortSet實現排行榜、List實現簡單隊列等等功能。只要區分開了兩者各自的優勢和特點，運用在不同的場景之下，才能真正發揮不同技術最大的優勢。
我是尋心湖，記得關注我。
尋心湖
這個完全取決於你對數據的要求，是否允許丟失，還是必須要求不允許丟失。我覺得就可以直接存放redis.如果用戶去網站買東西，這時候要記錄用戶的一個在網站操作的操作行為，（看了哪個商品、點擊了哪個商品、點擊了哪個按鈕）日誌，可以用來還原當時用戶的操作行為這個日誌的記錄是可以放在redis的，但是用戶下單、支付、配送信息等這些是要保持強一致性，並且不允許丟失的所以需要存入mysql.當用戶下完單之後想看下自己的訂單詳情，這時候訂單詳情一些固定的信息也是可以放redis的，所以redis和mysql是可以結合一起使用的。什麼事情都沒有絕對的，完全取決於你的業務要求。是業務驅動技術。
JAVA
首先可以明確一點的是：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是不可以代替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>上面是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各自有各自的應用場景，掌握好他們的特性，在不同的場景下應用最適合的存儲方案才是編碼之道。
歡迎大家積極參與討論，一起學習，共同成長~
java架構設計
定位不一樣，場景不一樣，
談不上取代一說，
都是一些初中級技術在庸人自擾
天亮教育
可以，但是成本翻百倍，大型項目以TB為數據容量單位的。而且至少需要雙熱備，成本翻倍
小劉49568648
不可以，存儲數據類型不一樣，都是開源數據庫，用redis 代替mysql沒意義
凱哥聽說
不可以！redis是nosql數據庫，內存型，單線程，運行時數據暫存內存，而數據庫數據是存放在硬盤！雖然有rdb、aof兩種持久化，但也只是為了避免掉電數據丟失，而且內存容量也有限，並不能解決數據庫的大量數據的持久化，更重要的是，redis雖然也支持事務，但不支持數據庫的事務回滾機制，不具有任何維持原子性的機制，雖然也因為單線程的原因有原子性，但不具有數據庫的原子性一致性隔離性持久性！
