Redis筆記

　　

 

Redis 全稱: Remote Dictionary Service: 遠程字典服務.

特色:

redis的存儲格式是基於行存儲數據, 是一個二維的模式.

 

Redis 的特性： 1）更豐富的數據類型 2）進程內與跨進程；單機與分佈式 3）功能豐富：持久化機制、過時策略 4）支持多種編程語言 5）高可用，集羣

 

Redis 的 Hash 自己也是一個 KV 的結構，相似於 Java 中的 HashMap。 外層的哈希（Redis KV 的實現）只用到了 hashtable。當存儲 hash 數據類型時， 咱們把它叫作內層的哈希。內層的哈希底層可使用兩種數據結構實現： ziplist：OBJ_ENCODING_ZIPLIST（壓縮列表） hashtable：OBJ_ENCODING_HT（哈希表）

 

 

ziplist 是一個通過特殊編碼的雙向鏈表，它不存儲指向上一個鏈表節點和指向下一 個鏈表節點的指針，而是存儲上一個節點長度和當前節點長度，經過犧牲部分讀寫性能， 來換取高效的內存空間利用率，是一種時間換空間的思想。只用在字段個數少，字段值 小的場景裏面。

 

quicklist（快速列表）是 ziplist 和 linkedlist 的結合體。

 

 

應用場景總結
緩存——提高熱點數據的訪問速度
共享數據——數據的存儲和共享的問題
全局 ID —— 分佈式全局 ID 的生成方案（分庫分表）
分佈式鎖——進程間共享數據的原子操做保證
在線用戶統計和計數
隊列、棧——跨進程的隊列/棧
消息隊列——異步解耦的消息機制
服務註冊與發現 —— RPC 通訊機制的服務協調中心（Dubbo 支持 Redis）
購物車
新浪/Twitter 用戶消息時間線
抽獎邏輯（禮物、轉發）
點贊、簽到、打卡
商品標籤
用戶（商品）關注（推薦）模型
電商產品篩選
排行榜

 

---------------

Redis 的事務有兩個特色：

• 批量操做在發送 EXEC 命令前被放入隊列緩存。
• 收到 EXEC 命令後進入事務執行，事務中任意命令執行失敗，其他的命令依然被執行。
• 在事務執行過程，其餘客戶端提交的命令請求不會插入到事務執行命令序列中。

事務小結:

單個 Redis 命令的執行是原子性的，但 Redis 沒有在事務上增長任何維持原子性的機制，因此 Redis 事務的執行並非原子性的。

事務能夠理解爲一個打包的批量執行腳本，但批量指令並不是原子化的操做，中間某條指令的失敗不會致使前面已作指令的回滾，也不會形成後續的指令不作。

 

 

 

 參照: http://c.biancheng.net/view/4544.html

Lua腳本

1、一次發送多個命令，減小網絡開銷。
2、Redis 會將整個腳本做爲一個總體執行，不會被其餘請求打斷，保持原子性。
3、對於複雜的組合命令，咱們能夠放在文件中，能夠實現程序之間的命令集複用。

 

 

 

單線程有什麼好處呢？
一、沒有建立線程、銷燬線程帶來的消耗
二、避免了上線文切換致使的CPU 消耗
三、避免了線程之間帶來的競爭問題，例如加鎖釋放鎖死鎖等等

異步非阻塞I/O，多路複用處理併發鏈接。

 

Redis過時策略:

1. 定時過時（主動淘汰）: 每一個設置過時時間的key 都須要建立一個定時器，到過時時間就會當即清除。

　　優勢: 對內存很友好,該策略能夠當即清除過時的數據
　　缺點: 會佔用大量的CPU 資源去處理過時的數據，從而影響緩存的響應時間和吞吐量.

2. 惰性過時（被動淘汰）:

　　優勢: 能夠最大化優化CPU資源.

　　缺點: 對內存不優化, 極端狀況下會出現大量過時的key,佔用大量內存.

3. 按期過時: 每隔必定的時間，會掃描必定數量的數據庫的expires 字典中必定數量的key，並清除其中已過時的key,

　　該策略是前二者的一個折中方案。經過調整定時掃描的時間間隔和每次掃描的限定耗時，能夠在不一樣狀況下使得CPU 和內存資源達到最優的平衡效果。

　　

AOF,RDB持久化方案的比較

若是能夠忍受一小段時間內數據的丟失，毫無疑問使用RDB 是最好的，定時生成RDB快照（snapshot）很是便於進行數據庫備份， 而且RDB 恢復數據集的速度也要比AOF 恢復的速度要快。不然就使用AOF 重寫。可是通常狀況下建議不要單獨使用某一種持久化機制，而是應該兩種一塊兒用，在這種狀況下,當redis 重啓的時候會優先載入AOF 文件來恢復原始的數據，由於在一般狀況下AOF 文件保存的數據集要比RDB 文件保存的數據集要完整。