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開發、架構設計、程序員職業發展等方面的見解，希望能得到你的關注。