通常來說，當(dāng)數(shù)據(jù)多、并發(fā)量大的時候，架構(gòu)中可以引入Redis，幫助提升架構(gòu)的整體性能，減少Mysql(或其他數(shù)據(jù)庫)的壓力，但不是使用Redis，就不用MySQL。

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

緩存

• 經(jīng)常會被查詢，但是不經(jīng)常被修改或者刪除的數(shù)據(jù)；比如數(shù)據(jù)字典，業(yè)務(wù)數(shù)據(jù)中的熱點數(shù)據(jù)；這樣不僅提升查詢效率，還可以減少數(shù)據(jù)庫的壓力；

• 經(jīng)常被查詢，實時性要求不高數(shù)據(jù)，比如網(wǎng)站的最新列表、排行榜之類的數(shù)據(jù)，只需要定時統(tǒng)計一次，然后把統(tǒng)計結(jié)果放到Redis中提供查詢（請不要使用select top 10 from xxxx）。

• 緩存可以方便數(shù)據(jù)共享，比如我先用電腦網(wǎng)頁打開X東，選了兩件商品放到購物車里面，再登錄手機APP，也是可以看到購物車里面的商品的。

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

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

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

高速讀寫

常見的就是計數(shù)器，比如一篇文章的閱讀量，不可能每一次閱讀就在數(shù)據(jù)庫里面update一次。

高并發(fā)的場景很適合使用Redis，比如雙11秒殺，庫存一共就一千件，到了秒殺的時間，通常會在極為短暫的時間內(nèi)，有數(shù)萬級的請求達到服務(wù)器，如果使用數(shù)據(jù)庫的話，很可能在這一瞬間造成數(shù)據(jù)庫的崩潰，所以通常會使用Redis（秒殺的場景會比較復(fù)雜，Redis只是其中之一，例如如果請求超過某個數(shù)量的時候，多余的請求就會被限流）。

這種高并發(fā)的場景，是當(dāng)請求達到服務(wù)器的時候，直接在Redis上讀寫，請求不會訪問到數(shù)據(jù)庫；程序會在合適的時間，比如一千件庫存都被秒殺，再將數(shù)據(jù)批量寫到數(shù)據(jù)庫中。

所以通常來說，在必要的時候引入Redis，可以減少MySQL（或其他）數(shù)據(jù)庫的壓力，兩者不是替代的關(guān)系。