通常來說，當數據多、并發量大的時候，架構中可以引入Redis，幫助提升架構的整體性能，減少Mysql(或其他數據庫)的壓力，但不是使用Redis，就不用MySQL。
因為Redis的性能十分優越，可以支持每秒十幾萬此的讀/寫操作，并且它還支持持久化、集群部署、分布式、主從同步等，Redis在高并發的場景下數據的安全和一致性，所以它經常用于兩個場景：
緩存經常會被查詢，但是不經常被修改或者刪除的數據；比如數據字典，業務數據中的熱點數據；這樣不僅提升查詢效率，還可以減少數據庫的壓力；
經常被查詢，實時性要求不高數據，比如網站的最新列表、排行榜之類的數據，只需要定時統計一次，然后把統計結果放到Redis中提供查詢（請不要使用select top 10 from xxxx）。
緩存可以方便數據共享，比如我先用電腦網頁打開X東，選了兩件商品放到購物車里面，再登錄手機APP，也是可以看到購物車里面的商品的。判斷數據是否適合緩存到Redis中，可以從幾個方面考慮：會經常查詢么？命中率如何？寫操作多么？數據大小？
我們經常采用這樣的方式將數據刷到Redis中：查詢的請求過來，現在Redis中查詢，如果查詢不到，就查詢數據庫拿到數據，再放到緩存中，這樣第二次相同的查詢請求過來，就可以直接在Redis中拿到數據；不過要注意【緩存穿透】的問題。
緩存的刷新會比較復雜，通常是修改完數據庫之后，還需要對Redis中的數據進行操作；代碼很簡單，但是需要保證這兩步為同一事務，或最終的事務一致性。
高速讀寫常見的就是計數器，比如一篇文章的閱讀量，不可能每一次閱讀就在數據庫里面update一次。
高并發的場景很適合使用Redis，比如雙11秒殺，庫存一共就一千件，到了秒殺的時間，通常會在極為短暫的時間內，有數萬級的請求達到服務器，如果使用數據庫的話，很可能在這一瞬間造成數據庫的崩潰，所以通常會使用Redis（秒殺的場景會比較復雜，Redis只是其中之一，例如如果請求超過某個數量的時候，多余的請求就會被限流）。
這種高并發的場景，是當請求達到服務器的時候，直接在Redis上讀寫，請求不會訪問到數據庫；程序會在合適的時間，比如一千件庫存都被秒殺，再將數據批量寫到數據庫中。
所以通常來說，在必要的時候引入Redis，可以減少MySQL（或其他）數據庫的壓力，兩者不是替代的關系。
我將持續分享Java開發、架構設計、程序員職業發展等方面的見解，希望能得到你的關注。