Redis解決了什么問題？

大規(guī)模讀寫數(shù)據(jù)與數(shù)據(jù)庫讀寫能力之間的矛盾 （推薦學習：Redis視頻教程）

簡單回顧一下CPU高速緩存的發(fā)展歷程，為了解決CPU的計算速度與內(nèi)存的讀取速度之間的巨大差異，CPU使用高速緩存來存放指令和數(shù)據(jù)。

高速緩存從最初的主板緩存到現(xiàn)在的3級緩存，緩存大小也不斷變大。來自網(wǎng)絡的數(shù)據(jù)表明：CPU高速緩存的命中率大約為80%。

類比電腦發(fā)展過程中CPU與內(nèi)存的矛盾，可以察覺到大型網(wǎng)站中大規(guī)模讀寫數(shù)據(jù)與數(shù)據(jù)庫讀寫能力之間的矛盾與此矛盾類似。我們也可以在數(shù)據(jù)庫與應用之間構建一塊比數(shù)據(jù)庫速度更快存儲區(qū)域——緩存。

大家最熟悉的也莫過于Ｒｅｄｉｓ用作緩存，我們知道Redis的作者設計Redis的初衷是因為他使用關系型數(shù)據(jù)庫時，無論如何優(yōu)化，性能都不能達到自己的期望，于是便自己手寫了一個內(nèi)存數(shù)據(jù)庫。

在作為緩存的情況下，我們有一下應用場景：

1. 熱點數(shù)據(jù) 例如我們可以將SＱＬ查詢結果保存在內(nèi)存中，也可以將用戶經(jīng)常查看的圖片保存在內(nèi)存中。

2. 排行榜 基于Redis提供的zset這種數(shù)據(jù)結構我們可以更加便捷的實現(xiàn)排行榜。實現(xiàn)排行榜的相關內(nèi)容可以參考排行榜算法設計實現(xiàn)比較。在小規(guī)模數(shù)據(jù)的情況下，使用Mysql實現(xiàn)排行榜沒有多少問題，但是一旦數(shù)據(jù)量上去了，那么持續(xù)的進行Mysql讀寫將會成為瓶頸。

3. 計數(shù)器/限速器 計數(shù)器的應用場景之一是統(tǒng)計用戶的點贊數(shù)，限速器的應用場景之一是限制用戶ip的訪問次數(shù)。之所以Redis能用于計數(shù)器是因為Redis是單線程的，每次都必須前一個指令執(zhí)行完，再執(zhí)行下一個指令。這樣就保證不會同時執(zhí)行多條指令；也即不會出現(xiàn)并發(fā)問題。限速器的原理類似。

4. 共同好友 利用Redis提供的Set數(shù)據(jù)結構的求交集操作sinter可以更加便捷地求兩個Set集合的交集；而使用數(shù)據(jù)庫的連表查詢將造成性能的開銷很多，因為大型網(wǎng)站的用戶數(shù)量巨大。

5. 簡單消息隊列 Redis的提供的發(fā)布/訂閱是一個極其簡單的消息系統(tǒng)。它不像Kafka那樣提供了分成不同的topic并且分成不同的分區(qū)并且提供持久化的功能。Ｒｅｄｉｓ的消息隊列用在不需要高可靠的場景。

6. session共享 Session是用來記錄是用戶是誰。當在應用使用集群方式部署的時候，我們需要一個統(tǒng)一管理session的地方，可以使用數(shù)據(jù)庫來記錄session，但是這時對數(shù)據(jù)庫的性能要求較高，此外session通常是具有時效性的，這段邏輯我們需要在代碼中實現(xiàn)，但是如果使用Redis來共享session，那么不會出現(xiàn)這樣的問題。

上面的許多應用場景也可以使用其他技術解決問題，只是Redis這樣的技術在一定資源限制的情況下，會是更好的解決方案。