redis

value數(shù)據(jù)類(lèi)型

redis 是key-value 類(lèi)型的內(nèi)存緩存 key的數(shù)據(jù)類(lèi)型是String
value 是二進(jìn)制安全的，可以理解為數(shù)據(jù)存儲(chǔ)為二進(jìn)制文件，在展示時(shí)和客戶(hù)端的編碼相關(guān)。

String byte

• 字符串

  常用命令：
  set
  get
  append
  setrange
  getrange
  strlen

• 數(shù)值

  常用命令：
  incr 應(yīng)用場(chǎng)景：搶購(gòu)秒殺，詳情頁(yè)，點(diǎn)贊，評(píng)論，歸并并發(fā)下對(duì)數(shù)據(jù)庫(kù)的事務(wù)操作，然全由redis內(nèi)存操作代替

• bitmap

  應(yīng)用場(chǎng)景：
  日活統(tǒng)計(jì)

List

• 棧
• 隊(duì)列
• 數(shù)組
• 阻塞，單播隊(duì)列FIFO

Hash

Set

無(wú)序 隨機(jī)性
放入的多少不同，元素存儲(chǔ)的順序不同去重

• 集合操作相當(dāng)多

• 隨機(jī)事件

  • SRANDMEMEBER KEY COUNT

    SRANDMEMBER key count
    count 是正數(shù)： 取出一個(gè)去重的結(jié)果集（不能超過(guò)已有集）
    coutnt 是負(fù)數(shù)： 取出一個(gè)帶重復(fù)的結(jié)果集，一定滿(mǎn)足你要的數(shù)量
    如果count 為0 ，不返回

- SPOP

  取出1個(gè)

Sorted_set

• 集合操作：并集 交集

  • 權(quán)重/聚合指令

• 通過(guò)跳表實(shí)現(xiàn)排序

• zrang/zrevrang

發(fā)布訂閱（Pub/Sub）

應(yīng)用場(chǎng)景，聊天室
聊天室數(shù)據(jù)分為實(shí)時(shí)和歷史數(shù)據(jù)
實(shí)時(shí)數(shù)據(jù)可以通過(guò)發(fā)布訂閱功能
歷史數(shù)據(jù)，假如是近期的數(shù)據(jù)，如3天之內(nèi)，用sorted_set
更老的數(shù)據(jù)需要持久化到數(shù)據(jù)庫(kù)中

SUB CHANNEL

PUB CHANNEL CONTENT

管道pipeline

一次性執(zhí)行多條redis指令

布隆過(guò)濾器

bloom概率解決問(wèn)題
不可能百分之百阻擋
1，你有啥

2. 通過(guò)多個(gè)映射函數(shù)向bitmap中標(biāo)記
3. 請(qǐng)求的可能被錯(cuò)誤標(biāo)記
4. 但是，一定概率會(huì)大量較少放行:穿透
   5.而且成本低

元素——》n個(gè)映射函數(shù)——》bitmap
判斷元素是否存在，通過(guò)映射函數(shù)，比對(duì)bitmap相應(yīng)位置是否為1

映射函數(shù)

bitmap

還有布谷鳥(niǎo)過(guò)濾器

實(shí)現(xiàn)的三種形式

• client 實(shí)現(xiàn)bloom算法，并自己承載bitmap
• client實(shí)現(xiàn)bloom算法，redis 承載bitmap
• redis 實(shí)現(xiàn)bloom算法并承載bitmap

持久化機(jī)制

修改配置文件實(shí)現(xiàn)

RDB快照

• 時(shí)點(diǎn)性

  某一時(shí)刻的快照

• save

  同步阻塞備份，比如關(guān)機(jī)維護(hù)時(shí)使用save

• bgsave

  異步備份，fork創(chuàng)建子進(jìn)程進(jìn)行備份

• 配置文件中給出bgsave的規(guī)則：

  語(yǔ)法：save seconds changes

  save 900 1
  save 300 10
  save 60 10000

  在seconds時(shí)有changes個(gè)key改變 就去備份

  dbfilename dump.rdb
  dir /var/lib/redis/6379

• 優(yōu)/弊端

  • 不支持拉鏈，只有一個(gè)dump.rdb
  • 丟失數(shù)據(jù)相對(duì)多一些，是時(shí)點(diǎn)與時(shí)點(diǎn)之間窗口數(shù)據(jù)容易丟失，場(chǎng)景：8點(diǎn)得到一個(gè)rdb,9點(diǎn)要落一個(gè)rdb，掛機(jī)了。。。。
  • 優(yōu)點(diǎn)：類(lèi)似于java中的序列化，恢復(fù)速度相對(duì)較快

AOF （Append Only File）

redis的寫(xiě)操作記錄到文件中

• 丟數(shù)據(jù)少

• redis中，RDB和AOF可以同時(shí)開(kāi)啟

  如果開(kāi)啟了AOF ,只會(huì)用AOF恢復(fù)

  AOF中包含RDB全量，增加記錄新的寫(xiě)操作

• 弊端：文件體量無(wú)限變大，恢復(fù)慢

  • 日志，優(yōu)點(diǎn)如果能保住，還是可以用的
    結(jié)果：設(shè)計(jì)一個(gè)方案讓日志，AOF足夠小

    • HFFS, fsimage +edits.log
      讓日志只記錄增量
      合并的過(guò)程
    • 重寫(xiě)：
      將老的數(shù)據(jù)RDB到aof文件中，
      將增量以指令的方式Append 到AOF

作為緩存/數(shù)據(jù)庫(kù)

緩存

• 緩存數(shù)據(jù)特點(diǎn)？

  緩存數(shù)據(jù)不重要，不是全量數(shù)據(jù)，
  應(yīng)該是隨著訪(fǎng)問(wèn)變化的熱數(shù)據(jù)

• redis里的數(shù)據(jù)怎么隨著業(yè)務(wù)變化？

  只保留熱數(shù)據(jù)，應(yīng)為內(nèi)存大小有限，也就是內(nèi)存瓶頸

• 緩存有效期

  • 業(yè)務(wù)邏輯驅(qū)動(dòng)

    key有效期隨著訪(fǎng)問(wèn)延長(zhǎng)？ 不對(duì)！！不會(huì)延長(zhǎng)
    發(fā)生寫(xiě)，會(huì)剔除過(guò)期時(shí)間
    倒計(jì)時(shí)，且redis不能延長(zhǎng)，但可以清除后手動(dòng)設(shè)置
    定時(shí)（EXPIREAT）
    業(yè)務(wù)邏輯自己控制過(guò)期時(shí)間

- 業(yè)務(wù)運(yùn)轉(zhuǎn)驅(qū)動(dòng)

  機(jī)器內(nèi)存是有限的，隨著訪(fǎng)問(wèn)的變化，應(yīng)該淘汰掉冷數(shù)據(jù)
  LFU策略：碰了多少次
  LRU策略: 多久沒(méi)碰

• 過(guò)期判定

  有兩種淘汰key的方式：被動(dòng)方式和主動(dòng)方式

- 主動(dòng)方式

  當(dāng)key超過(guò)過(guò)期事件后，并不會(huì)立即刪除key，只會(huì)對(duì)過(guò)期的key執(zhí)行del、set、getset時(shí)才會(huì)清除，也就意味著所有對(duì)改變key的值的操作都會(huì)觸發(fā)刪除動(dòng)作，當(dāng)client嘗試訪(fǎng)問(wèn)它時(shí)，key會(huì)被發(fā)現(xiàn)并主動(dòng)的過(guò)期
  

- 被動(dòng)方式

  只靠主動(dòng)方式是不夠的，因?yàn)橛行┻^(guò)期的keys，永遠(yuǎn)不會(huì)訪(fǎng)問(wèn)他們，那就永遠(yuǎn)不會(huì)過(guò)期，所以redis提供了被動(dòng)方式，被動(dòng)方式會(huì)定時(shí)檢測(cè)過(guò)期的key,然后刪除：
  每隔100ms 隨機(jī)抽取20個(gè)key進(jìn)行過(guò)期檢測(cè)
  刪除20個(gè)key中所有已過(guò)期的key
  如果過(guò)期key的比例大于25%,重復(fù)步驟1
  被動(dòng)方式采用一種概率算法，對(duì)key進(jìn)行隨機(jī)抽樣，這樣就意味著，在任何給定的時(shí)刻，最多會(huì)清除1/4的過(guò)期key。
  犧牲一些內(nèi)存，保證redis性能為王。

事務(wù)

MULTI/EXEC/DISCARD

WATCH

有點(diǎn)類(lèi)似于volitale的味道

兩種錯(cuò)誤情況

• 事務(wù)在執(zhí)行 EXEC 之前，語(yǔ)法錯(cuò)誤

  即使事務(wù)中有某個(gè)/某些命令在執(zhí)行時(shí)產(chǎn)生了錯(cuò)誤， 事務(wù)中的其他命令仍然會(huì)繼續(xù)執(zhí)行。

  最重要的是記住這樣一條， 即使事務(wù)中有某條/某些命令執(zhí)行失敗了， 事務(wù)隊(duì)列中的其他命令仍然會(huì)繼續(xù)執(zhí)行 —— Redis 不會(huì)停止執(zhí)行事務(wù)中的命令。

  當(dāng)命令在入隊(duì)時(shí)產(chǎn)生錯(cuò)誤， 錯(cuò)誤會(huì)立即被返回給客戶(hù)端

• 命令可能在 EXEC 調(diào)用之后失敗

事務(wù)不回滾

Redis 命令只會(huì)因?yàn)殄e(cuò)誤的語(yǔ)法而失敗（并且這些問(wèn)題不能在入隊(duì)時(shí)發(fā)現(xiàn)），或是命令用在了錯(cuò)誤類(lèi)型的鍵上面：這也就是說(shuō)，從實(shí)用性的角度來(lái)說(shuō)，失敗的命令是由編程錯(cuò)誤造成的，而這些錯(cuò)誤應(yīng)該在開(kāi)發(fā)的過(guò)程中被發(fā)現(xiàn)，而不應(yīng)該出現(xiàn)在生產(chǎn)環(huán)境中。
因?yàn)椴恍枰獙?duì)回滾進(jìn)行支持，所以 Redis 的內(nèi)部可以保持簡(jiǎn)單且快速。

XMind - Trial Version