redis的應用場景 為什么用redis

一、不是萬能的菲關系系數據庫redis

在面試的時候，常被問比較下Redis與Memcache的優缺點，個人覺得這二者並不適合一起比較，redis：是非關系型數據庫不僅可以做緩存還能干其它事情，Memcache：是僅用做緩存。常常讓我們對這二者進行比較，主要也是由於Redis最廣泛的應用場景就是Cache。

1.2 redis 都能干嘛

1. 緩存，毫無疑問這是Redis當今最為人熟知的使用場景。再提升服務器性能方面非常有效；

2. 排行榜，在使用傳統的關系型數據庫（mysql oracle 等）來做這個事兒，非常的麻煩，而利用Redis的SortSet(有序集合)數據結構能夠簡單的搞定；

3. 計算器/限速器，利用Redis中原子性的自增操作，我們可以統計類似用戶點贊數、用戶訪問數等，這類操作如果用MySQL，頻繁的讀寫會帶來相當大的壓力；限速器比較典型的使用場景是限制某個用戶訪問某個API的頻率，常用的有搶購時，防止用戶瘋狂點擊帶來不必要的壓力；

4. 好友關系，利用集合的一些命令，比如求交集、並集、差集等。可以方便搞定一些共同好友、共同愛好之類的功能；

5. 簡單消息隊列，除了Redis自身的發布/訂閱模式，我們也可以利用List來實現一個隊列機制，比如：到貨通知、郵件發送之類的需求，不需要高可靠，但是會帶來非常大的DB壓力，完全可以用List來完成異步解耦；

6. Session共享，以PHP為例，默認Session是保存在服務器的文件中，如果是集群服務，同一個用戶過來可能落在不同機器上，這就會導致用戶頻繁登陸；采用Redis保存Session后，無論用戶落在那台機器上都能夠獲取到對應的Session信息。

7. 一些頻繁被訪問的數據，經常被訪問的數據如果放在關系型數據庫，每次查詢的開銷都會很大，而放在redis中，因為redis 是放在內存中的可以很高效的訪問

1.3 最好別用redis 來做

用Redis去保存用戶的基本信息，雖然它能夠支持持久化，但是它的持久化方案並不能保證數據絕對的落地，並且還可能帶來Redis性能下降，因為持久化太過頻繁會增大Redis服務的壓力。

總結就是數據量太大、數據訪問頻率非常低的業務都不適合使用Redis，數據太大會增加成本，訪問頻率太低，保存在內存中純屬浪費資源。

使用redis的理由

上面所說的一些場景， 緩存可以用Memcache，Session共享能用MySql來實現，消息隊列可以用RabbitMQ等，

理由：
完全基於內存所以速度很快，使用C語言實現，網絡層使用epoll解決高並發問題，單線程模型避免了不必要的上下文切換及競爭條件； 注意：單線程僅僅是說在網絡請求這一模塊上用一個請求處理客戶端的請求，在持久化時它就會重開一個線程/進程去進行處理

豐富的數據類型，Redis有8種數據類型，常用的有 String、Hash、List、Set、 SortSet 這5種，都是基於鍵值的方式組織數據。每一種數據類型提供了非常豐富的操作命令，可以滿足絕大部分需求

Redis的代碼開源在GitHub，代碼非常簡單優雅，願意花時間就能去看懂；它的編譯安裝也很簡單，不存在其他系統依賴；各種客戶端的語言支持也是非常完善。另外它還支持事務、持久化、主從復制讓高可用、分布式成為可能。