前言

上篇文章簡單的介紹了redis的使用場景和優缺點，本文接著解答以下幾個問題：

• Redis有哪些資料結構？
• 使用過Redis分散式鎖麼，它是什麼回事？
• Redis 的資料型別，以及每種資料型別的使用場景?
• 使用過Redis做非同步佇列麼，你是怎麼用的？

這些問題實際上歸結起來都和redis 提供的資料結構有關，接下來重點帶著這些問題重點解讀redis的資料結構和使用場景。（·我覺得技術本身不能創造價值，只有找到對應的適用場景，解決業務中的問題，才能產生價值）。

` redis 是基於key-value的資料庫，所有的key都是字串型別，針對value值的不同，又劃分為字串，列表，集合，有序集合，雜湊表，（點陣圖，hyperLoglog，GEO） 等等`。
複製程式碼

本文主要介紹字串有代表性的一些命令以及對應的適用場景。

命令: SET key value [EX seconds] [PX milliseconds] [NX|XX] :

  將字串值 value 關聯到 key,如果 key 已經持有其他值， SET 就覆寫舊值，無視型別,對於某個原本帶有生存時（TTL）的鍵來說， 當 SET 命令成功在這個鍵上執行時， 這個鍵原有的 TTL 將被清除.
  
  引數介紹:
  EX second ：設定鍵的過期時間為 second 秒。 
  PX millisecond ：設定鍵的過期時間為 millisecond 毫秒
  NX ：只在鍵不存在時，才對鍵進行設定操作。 
  XX ：只在鍵已經存在時，才對鍵進行設定操作。
複製程式碼

常見使用場景：

• 快取：可以將要快取的資料序列化成json串，儲存在key對應的value裡，同時可以為其指定過期時間;

• 分散式鎖： 分散式鎖設計時要考慮以下問題：

     互斥性
     可重入性
     死鎖
     鎖的效能
  複製程式碼

採用redis實現分散式鎖，網上很多同學都給了實現方案，此處就不囉嗦了。redis 實現分散式鎖的優點是加鎖釋放鎖很快。不過採用redis 實現分散式鎖是有一些缺陷的，比如因為依賴鍵的過期機制，會導致如果加鎖時正常的業務程式碼執行時間超出了鍵的過期時間，業務程式碼還沒有執行完時，鎖已經釋放掉了，這樣其他執行緒就有可能獲取鎖，進而導致多個執行緒同時獲得鎖，不能嚴格意義上保證鎖的排他性。所以在業務選擇時要考慮到這些方面。

命令： INCR key

將 key 中儲存的數字值增一。

如果 key 不存在，那麼 key 的值會先被初始化為 0 ，然後再執行 INCR 操作。

如果值包含錯誤的型別，或字串型別的值不能表示為數字，那麼返回一個錯誤`
複製程式碼

常見使用場景:

• 計數器: 比如用來統計頁面的uv(使用者訪問量)
• 簡單的限速器：結合計數功能+過期機制，統計單位時間的訪問量來實現限流。

命令: SETBIT key offset value

 對 key 所儲存的字串值，設定或清除指定偏移量上的位(bit)。

 位的設定或清除取決於 value 引數，可以是 0 也可以是 1 。

 當 key 不存在時，自動生成一個新的字串值。

 字串會進行伸展(grown)以確保它可以將 value 儲存在指定的偏移量上。當字串值進行伸展時，空白位置以 0 填充。

 offset 引數必須大於或等於 0 ，小於 2^32 (bit 對映被限制在 512 MB 之內)。
複製程式碼

適用場景:

統計和查詢： 結合bitcount指令，比如從10億個無序的整數（範圍在0-40億）統計出前10個數，這種場景下使用bitmap 儲存時會極大的縮小佔用記憶體空間.

總結

本文僅僅是簡單的介紹了一下redis 字串型別的部分操作命令以及其相應的使用場景，關於redis的其他資料型別以及相應的使用場景，再後續的文章中進一步進行介紹。