Redis開發(fā)與運(yùn)維讀書筆記

• API的理解和使用
• • • 為什么redis單線程還那么快？
    • String類型
    • hashmap
    • 列表
    • 集合Set
    • 有序集合
    • bitmap
    • HyperLogLog
• 持久化
• • RDB
  • AOF(append only file)

本文記錄了閱讀該書中本人認(rèn)為比較有收獲，比較重要的知識點(diǎn)。其中有一些內(nèi)容加了一些自己的理解。

API的理解和使用

為什么redis單線程還那么快？

• 純內(nèi)存操作。避免了讀寫文件的時間消耗
• 非阻塞IO。redis使用epoll作為I/O多路復(fù)用技術(shù)的實(shí)現(xiàn)，再加上Redis自身的事件處理模型將epoll中的連接、讀寫、關(guān)閉都轉(zhuǎn)換為事件，不在網(wǎng)絡(luò)I/O上浪費(fèi)過多的事件。

epoll：
一開始說，epoll 是對 select 和 poll 的改進(jìn)，避免了“性能開銷大”和“文件描述符數(shù)量少”兩個缺點(diǎn)。
對于“文件描述符數(shù)量少”，select 使用整型數(shù)組存儲文件描述符集合，而 epoll 使用紅黑樹存儲，數(shù)量較大。
對于“性能開銷大”，epoll_ctl 中為每個文件描述符指定了回調(diào)函數(shù)，并在就緒時將其加入到就緒列表，因此 epoll 不需要像 select 那樣遍歷檢測每個文件描述符，只需要判斷就緒列表是否為空即可。這樣，在沒有描述符就緒時，epoll 能更早地讓出系統(tǒng)資源。

• 單線程避免了線程切換和競爭生產(chǎn)的消耗。

String類型

由于redis所有數(shù)據(jù)類型其實(shí)都是{key, value}的形式，因此String其實(shí)就是我們平常所說的“hashmap”，字符串類的值其實(shí)可以是簡單的字符串，也可是XML、Json，甚至對java對象進(jìn)行序列化后的值、也可以是數(shù)字、二進(jìn)制(圖片音頻、視頻)，但是不能超過512M

str的存儲結(jié)構(gòu)：
int： 8個字節(jié)的長整型
embstr: 小于等于39個字節(jié)的字符串
raw： 大于39個字節(jié)的字符串
redis會根據(jù)當(dāng)前值的類型和長度決定使用哪個數(shù)據(jù)結(jié)構(gòu)(str也可以存int型)
string的使用場景：

• 緩存功能。
  redis作為緩存層，減少存儲層mysql的壓力。

• 計數(shù)
  許多應(yīng)用Redis作為計數(shù)的基礎(chǔ)工具，它可以實(shí)現(xiàn)快速計數(shù)、計數(shù)查詢的功能(單線程執(zhí)行，保證數(shù)據(jù)的正確性)

• 共享session。
  用于分布式登錄中共享session

• 限速。
  和共享session原理相同，限制同一個Ip訪問

• 序列化保存數(shù)據(jù)。缺點(diǎn)就是序列化和反序列化需要開銷
  set user:1 serialize(userInfo)

hashmap

key key value 形式

內(nèi)部編碼
ziplist：壓縮列表,小于64個字節(jié)，查找效率慢
hashtable：哈希表，查找效率為O(1)，會消耗更多內(nèi)存

使用場景
記錄用戶信息
哈希表和關(guān)系型數(shù)據(jù)庫的區(qū)別：

• 哈希表是稀疏的，關(guān)系數(shù)據(jù)庫的結(jié)構(gòu)化的，關(guān)系數(shù)據(jù)庫一旦創(chuàng)建某行數(shù)據(jù)，所有的行都要為其設(shè)置值(NULL)
• 關(guān)系數(shù)據(jù)庫可以做復(fù)雜的關(guān)系查詢，而Redis去模擬關(guān)系型復(fù)雜查詢開發(fā)困難。

列表

列表類用來存儲多個有序的字符串，列表是有序的，可以范圍查找，也可以從某個元素前后插入元素，可以從下表取出元素，可以對兩端插入和彈出，

存儲類型

• ziplist(壓縮列表) 默認(rèn)64字節(jié)
• linkedlist(鏈表)
  使用場景
  1、消息隊列
  2、列表
  3、棧都可以
  lpush + lpop = Stack
  lpush + rpop = Queue

集合Set

集合中的元素不能重復(fù)，無序，redis實(shí)現(xiàn)了兩兩集合之間計算交集、并集
存儲類型

• intset 默認(rèn)小于512字節(jié)
• hashtable(哈希表)
  使用場景
  給用戶打標(biāo)簽(tag)

有序集合

可以排序的set(對key排序)
存儲類型

• ziplist 默認(rèn)小于128字節(jié)
• skiplist(跳表)
  使用場景
  排行榜

bitmap

用二進(jìn)制(位)作為信息的存儲單位，一個字節(jié)等于8位
bitmap本身不是一個數(shù)據(jù)結(jié)構(gòu)，其實(shí)是一個字符串
redis給bitmap單獨(dú)提供了一套命令，可以把bitmap當(dāng)成以位為單位的數(shù)組，數(shù)組的每個單位只能存儲0和1，數(shù)組下標(biāo)為Bitmap中叫做偏移量。
redis提供給bitmap數(shù)組的下標(biāo)查找，范圍查找
使用場景
記錄某天登錄的用戶id
setbit unique：users:2016-04-05 0 1 設(shè)置值為1
bitcount key [start end] 獲取范圍內(nèi)1的個數(shù)
bitmap還可以做兩兩之間的交集or、并集and、非、異或

計算兩天內(nèi)用戶都登錄過的數(shù)量 bittop and newkey key1 key2

bitmap并不是萬金油，當(dāng)用戶量很大，但是日活量很小的時候并不適用

HyperLogLog

hyperLogLog可以極小的內(nèi)存空間完成獨(dú)立總數(shù)的統(tǒng)計，占用內(nèi)存非常小，但是存在一定的誤差率

持久化

AOF 和 RDB

RDB

bgsave 保存redis快照。首先執(zhí)行fork操作創(chuàng)建子進(jìn)程，由子進(jìn)程負(fù)責(zé)，完成自動結(jié)束。

rdb優(yōu)點(diǎn)：
1、恢復(fù)數(shù)據(jù)遠(yuǎn)遠(yuǎn)快于AOF的方式
2、RDB是一個緊湊的二進(jìn)制文件，代表某個時間上的數(shù)據(jù)快照。
缺點(diǎn)：
1、沒辦法做到實(shí)時持久化/秒級持久化，fork子進(jìn)程屬于重量級操作，頻繁執(zhí)行成本太高。
2、redis版本演化過程中有多個格式的RDB版本，存在老版本的Redis可能存在無法兼容新版本的問題。

AOF(append only file)

以獨(dú)立日志的方式記錄每次寫命令，重啟時重新執(zhí)行AOF的文件命令達(dá)到恢復(fù)數(shù)據(jù)的目的。AOF主要是解決了數(shù)據(jù)庫持久化的實(shí)時性。
為了提高AOF性能：
1、AOF緩沖區(qū)。設(shè)置緩沖器定時寫入，減少磁盤IO訪問次數(shù)。
2、重寫機(jī)制。解決文件過大問題。合并一些命令操作，減少文件體積。

重寫機(jī)制過程：

總結(jié)

以上是生活随笔為你收集整理的Redis开发与运维读书笔记的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。