redis—相關問題彙總

什麼是redis？

Redis 本質上是一個 Key-Value 類型的內存數據庫，  整個數據庫加載在內存當中進行操做， 按期經過異步操做把數據庫數據 flush 到硬盤上進行保存。

由於是純內存操做， Redis 的性能很是出色， 每秒能夠處理超過 10 萬次讀寫操做， 是已知性能
最快的 Key-Value DB。
Redis 的出色之處不只僅是性能， Redis 最大的魅力是支持保存多種數據結構， 此外單個
value 的最大限制是 1GB， 不像 memcached 只能保存 1MB 的數據， 所以 Redis 能夠用
來實現不少有用的功能，比方說用他的 List 來作 FIFO 雙向鏈表，實現一個輕量級的高性 能
消息隊列服務， 用他的 Set 能夠作高性能的 tag 系統等等。

另外 Redis 也能夠對存入的Key-Value 設置 expire 時間， 所以也能夠被看成一 個功能增強版的 memcached 來用。
Redis 的主要缺點是數據庫容量受到物理內存的限制， 不能用做海量數據的高性能讀寫， 所以 Redis 適合的場景主要侷限在較小數據量的高性能操做和運算上

 相比 memcached 有哪些優點？

(1) memcached 全部的值均是簡單的字符串， Redis 做爲其替代者， 支持更爲豐富的數據類型

(2)Redis 的速度比 memcached 快不少
(3) Redis 能夠持久化其數據
 

Redis 的全稱是什麼？

Remote Dictionary Server。

支持哪幾種數據類型？

String、 List、 Set、 Sorted Set、 hashes
 

 

Redis 有哪幾種數據淘汰策略？

noeviction:返回錯誤當內存限制達到而且客戶端嘗試執行會讓更多內存被使用的命令（大
部分的寫入指令， 但 DEL 和幾個例外）
allkeys-lru: 嘗試回收最少使用的鍵（LRU）， 使得新添加的數據有空間存放。
volatile-lru: 嘗試回收最少使用的鍵（LRU）， 但僅限於在過時集合的鍵,使得新添加的數據
有空間存放。
allkeys-random: 回收隨機的鍵使得新添加的數據有空間存放。
volatile-random: 回收隨機的鍵使得新添加的數據有空間存放，但僅限於在過時集合的鍵。
volatile-ttl: 回收在過時集合的鍵， 而且優先回收存活時間（TTL） 較短的鍵,使得新添加的
數據有空間存放
 

redis爲何採用跳錶而不是紅黑樹
在作範圍查找的時候，平衡樹比skiplist操做要複雜。在平衡樹上，咱們找到指定範圍的小值以後，還須要以中序遍歷的順序繼續尋找其它不超過大值的節點。若是不對平衡樹進行必定的改造，這裏的中序遍歷並不容易實現。而在skiplist上進行範圍查找就很是簡單，只須要在找到小值以後，對第1層鏈表進行若干步的遍歷就能夠實現。
平衡樹的插入和刪除操做可能引起子樹的調整，邏輯複雜，而skiplist的插入和刪除只須要修改相鄰節點的指針，操做簡單又快速。
從內存佔用上來講，skiplist比平衡樹更靈活一些。通常來講，平衡樹每一個節點包含2個指針（分別指向左右子樹），而skiplist每一個節點包含的指針數目平均爲1/(1-p)，具體取決於參數p的大小。若是像Redis裏的實現同樣，取p=1/4，那麼平均每一個節點包含1.33個指針，比平衡樹更有優點。
查找單個key，skiplist和平衡樹的時間複雜度都爲O(log n)，大致至關；而哈希表在保持較低的哈希值衝突機率的前提下，查找時間複雜度接近O(1)，性能更高一些。因此咱們日常使用的各類Map或dictionary結構，大都是基於哈希表實現的。
從算法實現難度上來比較，skiplist比平衡樹要簡單得多。

介紹一下HyperLogLog？
HyperLogLog 是一種機率數據結構，用來估算數據的基數。數據集能夠是網站訪客的 IP 地址，E-mail 郵箱或者用戶 ID。

基數就是指一個集合中不一樣值的數目，好比 a, b, c, d 的基數就是 4，a, b, c, d, a 的基數仍是 4。雖然 a 出現兩次，只會被計算一次。

使用 Redis 統計集合的基數通常有三種方法，分別是使用 Redis 的 HashMap，BitMap 和 HyperLogLog。前兩個數據結構在集合的數量級增加時，所消耗的內存會大大增長，可是 HyperLogLog 則不會。

Redis 的 HyperLogLog 經過犧牲準確率來減小內存空間的消耗，只須要12K內存，在標準偏差0.81%的前提下，可以統計2^64個數據。因此 HyperLogLog 是否適合在好比統計日活月活此類的對精度要不不高的場景。

這是一個很驚人的結果，以如此小的內存來記錄如此大數量級的數據基數。

爲何 Redis 須要把全部數據放到內存中？

Redis 爲了達到最快的讀寫速度將數據都讀到內存中， 並經過異步的方式將數據寫入磁盤。
因此 Redis 具備快速和數據持久化的特徵。 若是不將數據放在內存中， 磁盤 I/O 速度爲嚴重
影響 Redis 的性能。 在內存愈來愈便宜的今天， Redis 將會愈來愈受歡迎。

 

Redis支持的數據類型？
String字符串：

格式: set key value

string類型是二進制安全的。意思是redis的string能夠包含任何數據。好比jpg圖片或者序列化的對象 。

string類型是Redis最基本的數據類型，一個鍵最大能存儲512MB。

 

Hash（哈希）

格式: hmset name  key1 value1 key2 value2

Redis hash 是一個鍵值(key=>value)對集合。

Redis hash是一個string類型的field和value的映射表，hash特別適合用於存儲對象。

 

List（列表）

Redis 列表是簡單的字符串列表，按照插入順序排序。你能夠添加一個元素到列表的頭部（左邊）或者尾部（右邊）

格式: lpush  name  value

在 key 對應 list 的頭部添加字符串元素

格式: rpush  name  value

在 key 對應 list 的尾部添加字符串元素

格式: lrem name  index

key 對應 list 中刪除 count 個和 value 相同的元素

格式: llen name  

返回 key 對應 list 的長度

 

Set（集合）

格式: sadd  name  value

Redis的Set是string類型的無序集合。

集合是經過哈希表實現的，因此添加，刪除，查找的複雜度都是O(1)。

 

zset(sorted set：有序集合)

格式: zadd  name score value

Redis zset 和 set 同樣也是string類型元素的集合,且不容許重複的成員。

不一樣的是每一個元素都會關聯一個double類型的分數。redis正是經過分數來爲集合中的成員進行從小到大的排序。

zset的成員是惟一的,但分數(score)卻能夠重複。

 

 sds相對c的改進？
  獲取長度：c字符串並不記錄自身長度，因此獲取長度只能遍歷一遍字符串，redis直接讀取len便可。

    緩衝區安全：c字符串容易形成緩衝區溢出，好比：程序員沒有分配足夠的空間就執行拼接操做。而redis會先檢查sds的空間是否知足所須要求，若是不知足會自動擴充。

    內存分配：因爲c不記錄字符串長度，對於包含了n個字符的字符串，底層老是一個長度n+1的數組，每一次長度變化，老是要對這個數組進行一次內存從新分配的操做。由於內存分配涉及複雜算法而且可能須要執行系統調用，因此它一般是比較耗時的操做。   
 

redis鏈表源碼？有什麼特性？
 

雙端、無環、帶長度記錄、

多態：使用 void* 指針來保存節點值， 能夠經過 dup 、 free 、 match 爲節點值設置類型特定函數， 能夠保存不一樣類型的值。

字典是如何實現的？
其實字典這種數據結構也內置在不少高級語言中，可是c語言沒有，因此redis本身實現了。

應用也比較普遍，好比redis的數據庫就是字典實現的。不只如此，當一個哈希鍵包含的鍵值對比較多，或者都是很長的字符串，redis就會用字典做爲哈希鍵的底層實現。

LRU？redis裏的具體實現？
LRU全稱是Least Recently Used，即最近最久未使用的意思。

LRU算法的設計原則是：若是一個數據在最近一段時間沒有被訪問到，那麼在未來它被訪問的可能性也很小。也就是說，當限定的空間已存滿數據時，應當把最久沒有被訪問到的數據淘汰。

redis原始的淘汰算法簡單實現：當須要淘汰一個key時，隨機選擇3個key，淘汰其中間隔時間最長的key。**基本上，咱們隨機選擇key，淘汰key效果很好。後來隨機3個key改爲一個配置項"N隨機key"。但把默認值提升改爲5個後效果大大提升。考慮到它的效果，你根本不用修改他。

redis的持久化？
RDB持久化能夠手動執行，也能夠配置按期執行，能夠把某個時間的數據狀態保存到RDB文件中，反之，咱們能夠用RDB文件還原數據庫狀態。

AOF持久化是經過保存服務器執行的命令來記錄狀態的。還原的時候再執行一遍便可。

 

如何選擇合適的持久化方式？

通常來講， 若是想達到足以媲美 PostgreSQL 的數據安全性， 你應該同時使用兩種持久
化功能。 若是你很是關心你的數據， 但仍然能夠承受數分鐘之內的數據丟失， 那麼你能夠
只使用 RDB 持久化。
有不少用戶都只使用 AOF 持久化， 但並不推薦這種方式： 由於定時生成 RDB 快照
（snapshot） 很是便於進行數據庫備份， 而且 RDB 恢復數據集的速度也要比 AOF 恢復
的速度要快， 除此以外， 使用 RDB 還能夠避免以前提到的 AOF 程序的 bug。
 

Redis 集羣方案應該怎麼作？ 都有哪些方案？

1.twemproxy， 大概概念是， 它相似於一個代理方式， 使用方法和普通 Redis 無任何區別，
設 置 好它 下 屬 的多 個 Redis 實 例 後， 使 用 時在 本 需 要 鏈接 Redis 的 地 方改 爲 鏈接
twemproxy， 它會以一個代理的身份接收請求並使用一致性 hash 算法， 將請求轉接到具
體 Redis， 將結果再返回 twemproxy。 使用方式簡便(相對 Redis 只需修改鏈接端口)， 對
舊項目擴展的首選。 問題： twemproxy 自身單端口實例的壓力， 使用一致性 hash 後， 對
Redis 節點數量改變時候的計算值的改變， 數據沒法自動移動到新的節點。
2. codis， 目前用的最多的集羣方案， 基本和 twemproxy 一致的效果， 但它支持在 節點
數量改變狀況下， 舊節點數據可恢復到新 hash 節點。
3. Redis cluster3.0 自帶的集羣， 特色在於他的分佈式算法不是一致性 hash， 而是 hash
槽的概念， 以及自身支持節點設置從節點。 具體看官方文檔介紹。
4.在業務代碼層實現， 起幾個毫無關聯的 Redis 實例， 在代碼層， 對 key 進行 hash 計算，
而後去對應的 Redis 實例操做數據。 這種方式對 hash 層代碼要求比較高， 考慮部分包括，
節點失效後的替代算法方案， 數據震盪後的自動腳本恢復， 實例的監控， 等等

MySQL 裏有 2000w 數據， Redis 中只存 20w 的數據，

如何保證 Redis 中的數據都是熱點數據？

Redis 內存數據集大小上升到必定大小的時候， 就會施行數據淘汰策略

Redis 有哪些適合的場景？

（1）、 會話緩存（Session Cache）
最經常使用的一種使用 Redis 的情景是會話緩存（session cache）。 用 Redis 緩存會話比其餘
存儲（如 Memcached） 的優點在於： Redis 提供持久化。 當維護一個不是嚴格要求一致性
的緩存時， 若是用戶的購物車信息所有丟失， 大部分人都會不高興的， 如今， 他們還會這樣
嗎？
幸運的是， 隨着 Redis 這些年的改進， 很容易找到怎麼恰當的使用 Redis 來緩存會話的文
檔。 甚至廣爲人知的商業平臺 Magento 也提供 Redis 的插件。
（2）、 全頁緩存（FPC）
除基本的會話 token 以外， Redis 還提供很簡便的 FPC 平臺。 回到一致性問題， 即便重啓
了 Redis 實例， 由於有磁盤的持久化， 用戶也不會看到頁面加載速度的降低， 這是一個極
大改進， 相似 PHP 本地 FPC。
再次以 Magento 爲例， Magento 提供一個插件來使用 Redis 做爲全頁緩存後端。
此外， 對 WordPress 的用戶來講， Pantheon 有一個很是好的插件 wp-Redis， 這個插件
能幫助你以最快速度加載你曾瀏覽過的頁面。
（3）、 隊列
Reids 在內存存儲引擎領域的一大優勢是提供 list 和 set 操做，這使得 Redis 能做爲一個
很好的消息隊列平臺來使用。 Redis 做爲隊列使用的操做， 就相似於本地程序語言（如
Python） 對 list 的 push/pop 操做。
若是你快速的在 Google 中搜索「Redis queues」， 你立刻就能找到大量的開源項目， 這些
項目的目的就是利用 Redis 建立很是好的後端工具， 以知足各類隊列需求。 例如， Celery
有一個後臺就是使用 Redis 做爲 broker， 你能夠從這裏去查看。
（4）、 排行榜/計數器
Redis在內存中對數字進行遞增或遞減的操做實現的很是好。集合（Set）和有序集合（Sorted
Set） 也使得咱們在執行這些操做的時候變的很是簡單， Redis 只是正好提供了這兩種數據
結構。 因此， 咱們要從排序集合中獲取到排名最靠前的 10 個用戶–咱們稱之爲
「user_scores」， 咱們只須要像下面同樣執行便可：
固然， 這是假定你是根據你用戶的分數作遞增的排序。 若是你想返回用戶及用戶的分數， 你
須要這樣執行：
ZRANGE user_scores 0 10 WITHSCORES
Agora Games 就是一個很好的例子， 用 Ruby 實現的， 它的排行榜就是使用 Redis 來存儲
數據的， 你能夠在這裏看到。
（5）、 發佈/訂閱
最後 是 Redis 的發佈/訂閱功能。 發佈/訂閱的使用場景確實非
常多。 我已看見人們在社交網絡鏈接中使用， 還可做爲基於發佈/訂閱的腳本觸發器， 甚至
用 Redis 的發佈/訂閱功能來創建聊天系統。

說說 Redis 哈希槽的概念？

Redis 集羣沒有使用一致性 hash,而是引入了哈希槽的概念， Redis 集羣有 16384 個哈希槽，
每一個 key 經過 CRC16 校驗後對 16384 取模來決定放置哪一個槽， 集羣的每一個節點負責一部分
hash 槽

爲何Redis集羣有16384個槽
(1)若是槽位爲65536，發送心跳信息的消息頭達8k，發送的心跳包過於龐大。

如上所述，在消息頭中，最佔空間的是myslots[CLUSTER_SLOTS/8]。 當槽位爲65536時，這塊的大小是: 65536÷8÷1024=8kb 由於每秒鐘，redis節點須要發送必定數量的ping消息做爲心跳包，若是槽位爲65536，這個ping消息的消息頭太大了，浪費帶寬。

(2)redis的集羣主節點數量基本不可能超過1000個。

如上所述，集羣節點越多，心跳包的消息體內攜帶的數據越多。若是節點過1000個，也會致使網絡擁堵。所以redis做者，不建議redis cluster節點數量超過1000個。 那麼，對於節點數在1000之內的redis cluster集羣，16384個槽位夠用了。沒有必要拓展到65536個。

(3)槽位越小，節點少的狀況下，壓縮比高

Redis主節點的配置信息中，它所負責的哈希槽是經過一張bitmap的形式來保存的，在傳輸過程當中，會對bitmap進行壓縮，可是若是bitmap的填充率slots / N很高的話(N表示節點數)，bitmap的壓縮率就很低。 若是節點數不多，而哈希槽數量不少的話，bitmap的壓縮率就很低。

Redis 集羣會有寫操做丟失嗎？ 爲何？

Redis 並不能保證數據的強一致性， 這意味這在實際中集羣在特定的條件下可能會丟失寫操
做。
 

Redis 集羣方案應該怎麼作？都有哪些方案？

1.twemproxy，大概概念是，它相似於一個代理方式， 使用時在本須要鏈接 redis 的地方改成鏈接 twemproxy， 它會以一個代理的身份接收請求並使用一致性 hash 算法，將請求轉接到具體 redis，將結果再返回 twemproxy。
缺點： twemproxy 自身單端口實例的壓力，使用一致性 hash 後，對 redis 節點數量改變時候的計算值的改變，數據沒法自動移動到新的節點。

2.codis，目前用的最多的集羣方案，基本和 twemproxy 一致的效果，但它支持在 節點數量改變狀況下，舊節點數據可恢復到新 hash 節點

3.redis cluster3.0 自帶的集羣，特色在於他的分佈式算法不是一致性 hash，而是 hash 槽的概念，以及自身支持節點設置從節點。具體看官方文檔介紹。
 

爲何要作 Redis 分區？

分區可讓 Redis 管理更大的內存， Redis 將可使用全部機器的內存。 若是沒有分區， 你
最多隻能使用一臺機器的內存。 分區使 Redis 的計算能力經過簡單地增長計算機獲得成倍提
升,Redis 的網絡帶寬也會隨着計算機和網卡的增長而成倍增加。
 

Redis 分區有什麼缺點？

涉及多個 key 的操做一般不會被支持。 例如你不能對兩個集合求交集， 由於他們可能被存
儲到不一樣的 Redis 實例（實際上這種狀況也有辦法， 可是不能直接使用交集指令）。
同時操做多個 key,則不能使用 Redis 事務.
分區使用的粒度是key，不能使用一個很是長的排序key存儲一個數據集（The partitioning
granularity is the key, so it is not possible to shard a dataset with a single huge
key like a very big sorted set） .
當使用分區的時候， 數據處理會很是複雜， 例如爲了備份你必須從不一樣的 Redis 實例和主
機同時收集 RDB / AOF 文件。
分區時動態擴容或縮容可能很是複雜。 Redis 集羣在運行時增長或者刪除 Redis 節點， 能
作到最大程度對用戶透明地數據再平衡，但其餘一些客戶端分區或者代理分區方法則不支持
這種特性。 然而， 有一種預分片的技術也能夠較好的解決這個問題。

 

Redis 與其餘 key-value 存儲有什麼不一樣？

Redis 有着更爲複雜的數據結構而且提供對他們的原子性操做，這是一個不一樣於其餘數據庫
的進化路徑。 Redis 的數據類型都是基於基本數據結構的同時對程序員透明， 無需進行額外
的抽象。
Redis 運行在內存中可是能夠持久化到磁盤，因此在對不一樣數據集進行高速讀寫時須要權衡
內存， 應爲數據量不能大於硬件內存。 在內存數據庫方面的另外一個優勢是， 相比在磁盤上
相同的複雜的數據結構， 在內存中操做起來很是簡單， 這樣 Redis 能夠作不少內部複雜性
很強的事情。 同時， 在磁盤格式方面他們是緊湊的以追加的方式產生的， 由於他們並不需
要進行隨機訪問

Redis 的內存用完了會發生什麼？

若是達到設置的上限， Redis 的寫命令會返回錯誤信息（可是讀命令還能夠正常返回。） 或
者你能夠將 Redis 當緩存來使用配置淘汰機制，當 Redis 達到內存上限時會沖刷掉舊的內容。
 

Redis 是單線程的， 如何提升多核 CPU 的利用率？

能夠在同一個服務器部署多個 Redis 的實例， 並把他們看成不一樣的服務器來使用， 在某些時
候， 不管如何一個服務器是不夠的，
因此， 若是你想使用多個 CPU， 你能夠考慮一下分片（shard）。

一個 Redis 實例最多能存放多少的 keys？ List、 Set、Sorted Set 他們最多能存放多少元素？

理論上 Redis 能夠處理多達 232 的 keys， 而且在實際中進行了測試， 每一個實例至少存放了 2億 5 千萬的 keys。 咱們正在測試一些較大的值。
任何 list、 set、 和 sorted set 均可以放 232 個元素。
換句話說， Redis 的存儲極限是系統中的可用內存值

 

修改配置不重啓 Redis 會實時生效嗎？

針對運行實例， 有許多配置選項能夠經過 CONFIG SET 命令進行修改， 而無需執行任何
形式的重啓。 從 Redis 2.2 開始， 能夠從 AOF 切換到 RDB 的快照持久性或其餘方式
而不須要重啓 Redis。 檢索 ‘CONFIG GET *’ 命令獲取更多信息。
但偶爾從新啓動是必須的， 如爲升級 Redis 程序到新的版本， 或者當你須要修改某些目前
CONFIG 命令還不支持的配置參數的時候
 

哨兵
Redis sentinel 是一個分佈式系統中監控 redis 主從服務器，並在主服務器下線時自動進行故障轉移。其中三個特性：

監控（Monitoring）：    Sentinel  會不斷地檢查你的主服務器和從服務器是否運做正常。

提醒（Notification）： 被監控的某個 Redis 服務器出現問題時， Sentinel 能夠經過 API 向管理員或者其餘應用程序發送通知。

自動故障遷移（Automatic failover）： 當一個主服務器不能正常工做時， Sentinel 會開始一次自動故障遷移操做。

特色：

一、保證高可用

二、監控各個節點

三、自動故障遷移

缺點：主從模式，切換須要時間丟數據

沒有解決 master 寫的壓力

 

緩存穿透

通常的緩存系統，都是按照key去緩存查詢，若是不存在對應的value，就去後端系統查找（好比DB）。

一些惡意的請求會故意查詢不存在的key,請求量很大，就會對後端系統形成很大的壓力。這就叫作緩存穿透。

 

如何避免？

1：對查詢結果爲空的狀況也進行緩存，這樣，再次訪問時，緩存層會直接返回空值。緩存時間設置短一點，或者該key對應的數據insert了以後清理緩存。

2：對必定不存在的key進行過濾。具體請看布隆過濾器

 

緩存擊穿

是針對緩存中沒有但數據庫有的數據。

場景是，當Key失效後，假如瞬間忽然涌入大量的請求，來請求同一個Key，這些請求不會命中Redis，都會請求到DB，致使數據庫壓力過大，甚至扛不住，掛掉。

解決辦法

一、設置熱點Key，自動檢測熱點Key，將熱點Key的過時時間加大或者設置爲永不過時，或者設置爲邏輯上永不過時

二、加互斥鎖。當發現沒有命中Redis，去查數據庫的時候，在執行更新緩存的操做上加鎖，當一個線程訪問時，其它線程等待，這個線程訪問事後，緩存中的數據會被重建，這樣其餘線程就能夠從緩存中取值。

 

緩存雪崩

是指大量Key同時失效，對這些Key的請求又會打到DB上，一樣會致使數據庫壓力過大甚至掛掉。

解決辦法

1）讓Key的失效時間分散開，能夠在統一的失效時間上再加一個隨機值，或者使用更高級的算法分散失效時間。

2）構建多個redis實例，個別節點掛了還有別的能夠用。

3）多級緩存：好比增長本地緩存，減少redis壓力。

4）對存儲層增長限流措施，當請求超出限制，提供降級服務（通常就是返回錯誤便可）

 

單線程的redis爲何這麼快
(一)純內存操做
(二)單線程操做，避免了頻繁的上下文切換
(三)採用了非阻塞I/O多路複用機制

（其實就是歷史遺留問題，非要吹的這麼好。。。）

 

redis採用的刪除策略
 

redis採用的是按期刪除+惰性刪除策略。

爲何不用定時刪除策略?

定時刪除,用一個定時器來負責監視key,過時則自動刪除。雖然內存及時釋放，可是十分消耗CPU資源。在大併發請求下，CPU要將時間應用在處理請求，而不是刪除key,所以沒有采用這一策略.

按期刪除+惰性刪除是如何工做的呢?

按期刪除，redis默認每一個100ms檢查，是否有過時的key,有過時key則刪除。須要說明的是，redis不是每一個100ms將全部的key檢查一次，而是隨機抽取進行檢查(若是每隔100ms,所有key進行檢查，redis豈不是卡死)。所以，若是隻採用按期刪除策略，會致使不少key到時間沒有刪除。
因而，惰性刪除派上用場。也就是說在你獲取某個key的時候，redis會檢查一下，這個key若是設置了過時時間那麼是否過時了？若是過時了此時就會刪除。

 

爲何Redis的操做是原子性的，怎麼保證原子性的？

對於Redis而言，命令的原子性指的是：一個操做的不能夠再分，操做要麼執行，要麼不執行。
Redis的操做之因此是原子性的，是由於Redis是單線程的。
Redis自己提供的全部API都是原子操做，Redis中的事務實際上是要保證批量操做的原子性。
多個命令在併發中也是原子性的嗎？
不必定， 將get和set改爲單命令操做，incr 。使用Redis的事務，或者使用Redis+Lua==的方式實現.
 

消息隊列
不要使用redis去作消息隊列，這不是redis的設計目標。但實在太多人使用redis去作去消息隊列，redis的做者看不下去。

kafka纔好用原文連接：https://blog.csdn.net/hebtu666/article/details/102580321