1. 程式人生 > 其它 >第十八章 【高階篇】分散式快取Redis6.X新特性講解拓展

第十八章 【高階篇】分散式快取Redis6.X新特性講解拓展

願景:"讓程式設計不再難學,讓技術與生活更加有趣"

更多架構課程請訪問 xdclass.net +vxdclass10諮詢更多課程

第1集 新版Redis6核心特性-多執行緒介紹

簡介: 新版Redis6核心特性介紹-多執行緒

  • 新版Redis6特性講解

    • 支援多執行緒

      • redis6多執行緒只是用來處理網路資料的讀寫和協議解析上,底層資料操作還是單執行緒
      • 執行命令仍然是單執行緒,之所以這麼設計是不想因為多執行緒而變得複雜,需要去控制 key、lua、事務,LPUSH/LPOP 等等的併發問題
      • 預設不開啟
      io-threads-do-reads yes
      io-threads 執行緒數
      • 官方建議 ( 執行緒數小於機器核數 )

        • 4 核的機器建議設定為 2 或 3 個執行緒
        • 8 核的建議設定為 4或6個執行緒,
    • 開啟多執行緒後,是否會存線上程併發安全問題?

    • 不會有安全問題,Redis 的多執行緒部分只是用來處理網路資料的讀寫和協議解析,執行命令仍然是單執行緒順序執行。

第2集 新版Redis6核心特性-Access Control List許可權控制

簡介: 新版Redis6核心特性介紹-acl 許可權控制

  • 引入了 ACL(Access Control List)

    • 之前的redis沒有使用者的概念,redis6引入了acl

    • 可以給每個使用者分配不同的許可權來控制權限

    • 通過限制對命令和金鑰的訪問來提高安全性,以使不受信任的客戶端無法訪問

    • 提高操作安全性,以防止由於軟體錯誤或人為錯誤而導致程序或人員訪問 Redis,從而損壞資料或配置

    • 文件:https://redis.io/topics/acl

    • 常用命令

      • acl list 當前啟用的 ACL 規則
      • acl cat 支援的許可權分類列表
      • acl cat hash 返回指定類別中的命令
      • acl setuser 建立和修改使用者命令
      • acl deluser 刪除使用者命令
      +<command> 將命令新增到使用者可以呼叫的命令列表中,如+@hash
      -<command> 將命令從使用者可以呼叫的命令列表中移除
      #切換預設使用者
      auth default 123456
      #例子 密碼 123 ,全部key,全部許可權
      acl setuser jack on >123 ~* +@all
      #例子 密碼 123 ,全部key,get許可權
      acl setuser jack on >123 ~* +get
參 數說明
user 使用者
default 表示預設使用者名稱,或則自己定義的使用者名稱
on 表示是否啟用該使用者,預設為off(禁用)
#... 表示使用者密碼,nopass表示不需要密碼
~* 表示可以訪問的Key(正則匹配)
+@ 表示使用者的許可權,“+”表示授權許可權,有許可權操作或訪問,“-”表示還是沒有許可權; @為許可權分類,可以通過ACL CAT查詢支援的分類。+@all 表示所有許可權,nocommands 表示不給與任何命令的操作許可權

第3集 新版Redis6核心特性-Client-Side-Caching 客戶端快取

簡介: 新版Redis6核心特性介紹-客戶端快取

  • 新版Redis6特性講解

    • client side caching客戶端快取

      • 類似瀏覽器快取一樣

        • 在伺服器端更新了靜態檔案(如css、js、圖片),能夠在客戶端得到及時的更新,但又不想讓瀏覽器每次請求都從伺服器端獲取靜態資源
        • 類似前端的-Expires、Last-Modified、Etag快取控制
    • 文件:https://redis.io/topics/client-side-caching

    • 詳細: 分為兩種模式

      redis在服務端記錄訪問的連線和相關的key, 當key有變化時通知相應的應用
      應用收到請求後自行處理有變化的key, 進而實現client cache與redis的一致
      這需要客戶端實現,目前lettuce對其進行了支援

  • 預設模式

    • Server 端全域性唯一的表(Invalidation Table)記錄每個Client訪問的Key,當發生變更時,向client推送資料過期訊息。

      • 優點:只對Client傳送其訪問過的被修改的資料
      • 缺點:Server端需要額外儲存較大的資料量。
  • 廣播模式

    • 客戶端訂閱key字首的廣播,服務端記錄key字首與client的對應關係。當相匹配的key發生變化時通知client。
    • 優點:服務端記錄資訊比較少
    • 缺點:client會收到自己未訪問過的key的失效通知