通常來說，當(dāng)數(shù)據(jù)多、并發(fā)量大的時(shí)候，架構(gòu)中可以引入Redis，幫助提升架構(gòu)的整體性能，減少M(fèi)ysql(或其他數(shù)據(jù)庫)的壓力，但不是使用Redis，就不用MySQL。
因?yàn)镽edis的性能十分優(yōu)越，可以支持每秒十幾萬此的讀/寫操作，并且它還支持持久化、集群部署、分布式、主從同步等，Redis在高并發(fā)的場景下數(shù)據(jù)的安全和一致性，所以它經(jīng)常用于兩個(gè)場景：
緩存經(jīng)常會被查詢，但是不經(jīng)常被修改或者刪除的數(shù)據(jù)；比如數(shù)據(jù)字典，業(yè)務(wù)數(shù)據(jù)中的熱點(diǎn)數(shù)據(jù)；這樣不僅提升查詢效率，還可以減少數(shù)據(jù)庫的壓力；
經(jīng)常被查詢，實(shí)時(shí)性要求不高數(shù)據(jù)，比如網(wǎng)站的最新列表、排行榜之類的數(shù)據(jù)，只需要定時(shí)統(tǒng)計(jì)一次，然后把統(tǒng)計(jì)結(jié)果放到Redis中提供查詢（請不要使用select top 10 from xxxx）。
緩存可以方便數(shù)據(jù)共享，比如我先用電腦網(wǎng)頁打開X東，選了兩件商品放到購物車?yán)锩妫俚卿浭謾C(jī)APP，也是可以看到購物車?yán)锩娴纳唐返摹?p>判斷數(shù)據(jù)是否適合緩存到Redis中，可以從幾個(gè)方面考慮：會經(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ù)進(jìn)行操作；代碼很簡單，但是需要保證這兩步為同一事務(wù)，或最終的事務(wù)一致性。
高速讀寫常見的就是計(jì)數(shù)器，比如一篇文章的閱讀量，不可能每一次閱讀就在數(shù)據(jù)庫里面update一次。
高并發(fā)的場景很適合使用Redis，比如雙11秒殺，庫存一共就一千件，到了秒殺的時(shí)間，通常會在極為短暫的時(shí)間內(nèi)，有數(shù)萬級的請求達(dá)到服務(wù)器，如果使用數(shù)據(jù)庫的話，很可能在這一瞬間造成數(shù)據(jù)庫的崩潰，所以通常會使用Redis（秒殺的場景會比較復(fù)雜，Redis只是其中之一，例如如果請求超過某個(gè)數(shù)量的時(shí)候，多余的請求就會被限流）。
這種高并發(fā)的場景，是當(dāng)請求達(dá)到服務(wù)器的時(shí)候，直接在Redis上讀寫，請求不會訪問到數(shù)據(jù)庫；程序會在合適的時(shí)間，比如一千件庫存都被秒殺，再將數(shù)據(jù)批量寫到數(shù)據(jù)庫中。
所以通常來說，在必要的時(shí)候引入Redis，可以減少M(fèi)ySQL（或其他）數(shù)據(jù)庫的壓力，兩者不是替代的關(guān)系。
我將持續(xù)分享Java開發(fā)、架構(gòu)設(shè)計(jì)、程序員職業(yè)發(fā)展等方面的見解，希望能得到你的關(guān)注。