redis的應用場景為什麼用redis

一、不是萬能的菲關係系資料庫redis

在面試的時候，常被問比較下redis與memcache的優缺點，個人覺得這二者並不適合一起比較，redis：是非關係型資料庫不僅可以做快取還能幹其它事情，memcache：是僅用做快取。常常讓我們對這二者進行比較，主要也是由於redis最廣泛的應用場景就是cache。

1.2 redis 都能幹嘛

快取，毫無疑問這是redis當今最為人熟知的使用場景。再提公升伺服器效能方面非常有效；

排行榜，在使用傳統的關係型資料庫（mysql oracle 等）來做這個事兒，非常的麻煩，而利用redis的sortset(有序集合)資料結構能夠簡單的搞定；

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

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

簡單訊息佇列，除了redis自身的發布/訂閱模式，我們也可以利用list來實現乙個佇列機制，比如：到貨通知、郵件傳送之類的需求，不需要高可靠，但是會帶來非常大的db壓力，完全可以用list來完成非同步解耦；

session共享，以php為例，預設session是儲存在伺服器的檔案中，如果是集群服務，同乙個使用者過來可能落在不同機器上，這就會導致使用者頻繁登陸；採用redis儲存session後，無論使用者落在那台機器上都能夠獲取到對應的session資訊。

一些頻繁被訪問的資料，經常被訪問的資料如果放在關係型資料庫，每次查詢的開銷都會很大，而放在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，**非常簡單優雅，願意花時間就能去看懂；它的編譯安裝也很簡單，不存在其他系統依賴；各種客戶端的語言支援也是非常完善。另外它還支援事務、持久化、主從複製讓高可用、分布式成為可能。

redis的應用場景 為什麼用redis