目錄
1. redis是什么
主要特點
2. redis中存儲的數據類型
2.1 String類型
2.2 List類型
2.3 Hash類型
2.4 Set類型
2.5 Zset類型
2.6 其它類型
3.redis高可用框架
1. redis是什么
Redis 是一個開源的、基于內存的數據結構存儲系統，是 Remote Dictionary Server（遠程字典服務器）的縮寫。可用作：
- 數據庫
- 緩存
- 消息中間件
主要特點
- 基于內存操作，性能極高
- 支持豐富的數據結構（字符串、哈希表、列表、集合等）
- 支持數據持久化
- 支持主從復制和集群
- 單線程模型（核心操作）
2. redis中存儲的數據類型
常見的5種數據類型：String(字符串)、Hash(哈希)、List(列表)、Set(集合)、Zset(有序集合)。
2.1 String類型
String 是最基本的 key-value 結構，key 是唯一標識，value 是具體的值，value其實不僅是字符串， 也可以是數字（整數或浮點數），value 最多可以容納的數據長度是512M。
常見指令：
| 操作 | 常用指令 | value類型 |
| 查詢 | GET key | 字符串 |
| 增加 | SET key value | |
| 刪除 | DEL key | |
| 判斷key是否存在 | EXISTS key | |
| 判斷key中value長度 | STRLEN key | |
| value值+1 | INCR key | 整數 |
| value值-1 | DECR key | |
| value值+10 | INCR key 10 | |
| 設置過期時間60秒 | EXPIRE key 60 | |
| 查看數據還有多久過期 | TTL key | time to live |
| 設置值和過期時間 | SETEX key 60 value SET key value EX 60 | |
| 不存在插入 | SETNX key value |
應用場景：
- 緩存對象數據
- 計數(單線程原子操作)：INCR key
- 分布式鎖：SETNX key value PX?1000，若key不存在，則插入成功即加鎖成功，若key存在，加鎖失敗，同時給該key鎖設置過期時間1秒。
- 共享session信息：分布式系統，服務器共享redis中存儲的session信息。
擴展：SETEX 是較早引入的命令，當時Redis主要使用秒作為時間單位；SET 命令的選項是后來添加的，增加了更精細的毫秒級控制，PX =?Precise eXpire (in milliseconds)
2.2 List類型
簡單的字符串列表，底層采用雙鏈表，列表的最大長度為?2^32 - 1，也即每個列表支持超過?40 億個元素。
常用指令：
| 操作 | 常用指令 | |
| 在value列表left左側插入數據 | LPUSH key value | |
| 在value列表右側right插入數據 | RPUSH key value | |
| 列表左側彈出頭元素 | LPOP key | |
| 列表右側彈出尾元素 | RPOP key | |
| 返回指定區間內的元素 | LRANGE key start stop |
應用場景：
- 消息隊列：
2.3 Hash類型
Hash 是一個鍵值對（key - value）集合，其中 value 的形式如： value=[{field1，value1}，...{fieldN，valueN}]。Hash 特別適合用于存儲對象。
常用指令：
| 操作 | 常用指令 |
| 增加 | HSET key field value(HMSET key field1 value1 field2 value2 ) |
| 獲取 | HGET key field |
| 刪除 | HDEL key field |
| field的數量 | HLEN key |
2.4 Set類型
無序并唯一的鍵值集合，一個集合最多可以存儲?2^32-1?個元素。
常見指令：
| 操作 | 指令 | 備注 |
| 增加元素 | SADD key value | |
| 刪除元素 | SREM key value | |
| 獲取所有元素 | SMEMBERS key |
應用場景：數據去重，數據唯一性，集合之間交集、并集、錯集。
點贊：文章下點贊的用戶數據
共同關注：不同的用戶關注的相同的公眾號數據
2.5 Zset類型
有序集合類型：元素依然是唯一的，不允許重復，但是每個元素是有順序的。每個元素存儲兩個值，一個是順序號，一個是元素值。
常用指令
| 操作 | 指令 | 備注 |
| 增加 | ZADD key score value | |
| 刪除 | ZREM key value | |
| 返回元素的分值 | ZSCORE key value | |
| 某個元素的score增加 | ZINCRBY key score value |
應用場景：排行榜、排序
2.6 其它類型
- BitMap（2.2 版新增）：二值狀態統計的場景，比如簽到、判斷用戶登陸狀態、連續簽到用戶總數等；
- HyperLogLog（2.8 版新增）：海量數據基數統計的場景，比如百萬級網頁 UV 計數等；
- GEO（3.2 版新增）：存儲地理位置信息的場景，比如滴滴叫車；
- Stream（5.0 版新增）：消息隊列，相比于基于 List 類型實現的消息隊列，有這兩個特有的特性：自動生成全局唯一消息ID，支持以消費組形式消費數據。
3.redis高可用框架
框架：主從模式，數據修改只在主服務器上，然后將最新的數據同步給從服務器。
如果主服務器掛了，如何選擇新的主服務器呢，引入哨兵機制，它會檢測主節點是否存活，哨兵的作用：監控、選主、通知。
為了減少一個哨兵節點對主服務器判斷的失誤，所以，為了減少誤判的情況，哨兵在部署的時候不會只部署一個節點，而是用多個節點部署成哨兵集群（最少需要三臺機器來部署哨兵集群），通過多個哨兵節點一起判斷，就可以就可以避免單個哨兵因為自身網絡狀況不好，而誤判主節點下線的情況。同時，多個哨兵的網絡同時不穩定的概率較小，由它們一起做決策，誤判率也能降低。
這張圖展示的是Redis哨兵（Sentinel）模式的架構相關邏輯。 在Redis哨兵模式中，存在主節點（Master）、從節點（Slave）和哨兵節點（Sentinel）。主節點負責處理寫操作，從節點通過“寫同步”從主節點同步數據，主要處理讀操作。
哨兵節點的作用是監控主節點的狀態。圖中的哨兵A、B、C會對主節點是否下線進行判斷與協商。比如哨兵B和C判定主節點“主觀下線”（即自身認為主節點可能下線）后，會相互詢問對方是否也認為主節點下線，哨兵C表示認同，而哨兵A則判定主節點在線且不認同其他哨兵的觀點。當多數哨兵（通常是超過半數）判定主節點真正下線（客觀下線）后，會觸發故障轉移流程，從從節點中選舉出新的主節點，保證Redis服務的高可用性。
參考：https://www.xiaolincoding.com/redis/cluster/master_slave_replication.html
：)
