爲何要用Redis

最近閱讀了《Redis開發與運維》，很是不錯。這裏對書中的知識整理一下，方便本身回顧一下Redis的整個體系，來對相關知識點查漏補缺。

我按照五點把書中的內容進行一下整理：

• 爲何要選擇Redis：介紹Redis的使用場景與使用Redis的緣由；
• Redis經常使用命令總結：包括時間複雜度總結與具體數據類型在Redis內部使用的數據結構；
• Redis的高級功能：包括持久化、複製、哨兵、集羣介紹；
• 理解Redis：理解內存、阻塞；這部分是很是重要的，前面介紹的均可以成爲術，這裏應該屬於道的部分；
• 開發技巧：主要是一些開發實戰的總結，包括緩存設計與常見坑點。

先來開啓第一部分的內容，對Redis來一次從新打量。

本系列內容基於：redis-3.2.12

Redis不是萬金油

在面試的時候，常被問比較下Redis與Memcache的優缺點，我的以爲這兩者並不適合一塊兒比較，一個是非關係型數據庫不只能夠作緩存還能幹其它事情，一個是僅用作緩存。經常讓咱們對這兩者進行比較，主要也是因爲Redis最普遍的應用場景就是Cache。那麼Redis到底能幹什麼？又不能幹什麼呢？

Redis均可以幹什麼事兒

緩存，毫無疑問這是Redis當今最爲人熟知的使用場景。再提高服務器性能方面很是有效；

排行榜，若是使用傳統的關係型數據庫來作這個事兒，很是的麻煩，而利用Redis的SortSet數據結構可以很是方便搞定；

計算器/限速器，利用Redis中原子性的自增操做，咱們能夠統計相似用戶點贊數、用戶訪問數等，這類操做若是用MySQL，頻繁的讀寫會帶來至關大的壓力；限速器比較典型的使用場景是限制某個用戶訪問某個API的頻率，經常使用的有搶購時，防止用戶瘋狂點擊帶來沒必要要的壓力；

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

簡單消息隊列，除了Redis自身的發佈/訂閱模式，咱們也能夠利用List來實現一個隊列機制，好比：到貨通知、郵件發送之類的需求，不須要高可靠，可是會帶來很是大的DB壓力，徹底能夠用List來完成異步解耦；

Session共享，以PHP爲例，默認Session是保存在服務器的文件中，若是是集羣服務，同一個用戶過來可能落在不一樣機器上，這就會致使用戶頻繁登錄；採用Redis保存Session後，不管用戶落在那臺機器上都可以獲取到對應的Session信息。

Redis不能幹什麼事兒

Redis感受能幹的事情特別多，但它不是萬能的，合適的地方用它事半功倍。若是濫用可能致使系統的不穩定、成本增高等問題。

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

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

選擇總須要找個理由

上面說了Redis的一些使用場景，那麼這些場景的解決方案也有不少其它選擇，好比緩存能夠用Memcache，Session共享還能用MySql來實現，消息隊列能夠用RabbitMQ，咱們爲何必定要用Redis呢？

速度快，徹底基於內存，使用C語言實現，網絡層使用epoll解決高併發問題，單線程模型避免了沒必要要的上下文切換及競爭條件；

注意：單線程僅僅是說在網絡請求這一模塊上用一個線程處理客戶端的請求，像持久化它就會重開一個線程/進程去進行處理

豐富的數據類型，Redis有8種數據類型，固然經常使用的主要是 String、Hash、List、Set、 SortSet 這5種類型，他們都是基於鍵值的方式組織數據。每一種數據類型提供了很是豐富的操做命令，能夠知足絕大部分需求，若是有特殊需求還能本身經過 lua 腳本本身建立新的命令（具有原子性）；

除了提供的豐富的數據類型，Redis還提供了像慢查詢分析、性能測試、Pipeline、事務、Lua自定義命令、Bitmaps、HyperLogLog、發佈/訂閱、Geo等個性化功能。

Redis的代碼開源在GitHub，代碼很是簡單優雅，任何人都可以吃透它的源碼；它的編譯安裝也是很是的簡單，沒有任何的系統依賴；有很是活躍的社區，各類客戶端的語言支持也是很是完善。另外它還支持事務（沒用過）、持久化、主從複製讓高可用、分佈式成爲可能。

作爲一個開發者，對於咱們使用的東西不能讓它成爲一個黑盒子，咱們應該深刻進去，對它更瞭解、更熟悉。今天簡單說了下Redis的使用場景，以及爲何選擇了Redis而不是其它。下次對Redis的內部數據結構及經常使用命令的時間複雜度進行總結。

我的公衆號：