1.redis五種數據結構
1.1 String字符串類型，對應java字符串類型
用戶信息序列化后，可以用string類型存入redis中
批量讀寫string類型，見效網絡消耗
數字類型的string類型，可以自增自減操作，有一個大小限制。
1.2 list類型，對應java的LinkedList，鏈表結構。
增刪O(1)，查詢O(n)
異步隊列，一邊線程塞入，一邊線程取出消費。
結構又和java的不同，多個ziplist組合成quicklist
1.3hash字典類型，對應java的HashMap，是數組+鏈表結構。
擴容：java是一次性rehash，redis漸進rehash，redis新舊結構兩個一起存，然后定時任務慢慢移動，保證了高性能。
可以存儲用戶單個對象，好處是可以獲得單個字段，壞處比起String類型架構占用更多的空間。
1.4set(集合)對應java中的HashSet，無序不重復。
可以做抽獎，去重保證一個人不會中獎兩次。
1.5zset(有序集合)
存粉絲：value用戶id，socre關注時間。
學生成績：value學生成績，socre學生分數
數據結構跳躍列表結構，分等級結構，這樣快速的定位插入。
2.應用一：分布式鎖
獲得鎖
setnx key value
存活時間
expire key time
中間異常沒有釋放鎖，加一個存活過期時間解決。
不是原子操作？redis2.8用一條命令操作，后面學習。
超時問題，后面學習。
可沖入鎖，后面學習。
3.應用二：延遲隊列
異步消息隊列，不能保證消息可靠性極致的追求。
list(列表)作為異步消息隊列的使用，rpush/lpush入隊列，lpop/rpop出隊列。
隊列空了怎么辦？一直獲取對cpu有壓力，java休眠1s，會有延遲，多個消費者可以降低延遲。
上面問題可以用 blpop/brpop解決，b表示blocking，也就是阻塞讀，沒有數據就會自動休眠，完美解決上面的問題。注意：長時間沒有數據，服務器會斷開空閑連接，java編寫客戶端消費者注意捕獲異常進行重試。
鎖沖突處理？當前無法獲得鎖
拋出異常，通知用戶稍后重試，調到對話框讓用戶點擊重試，進行重試控制。
sleep 一會再重試。會阻塞當前的消息處理線程，導致隊列的后續消息處理出現延遲。
請求轉入延時隊列中，過一會再試，適合異步消息處理。
延時隊列實現？沒看懂，后面再學習。