Redis 、MongoDB入門

xwmwanjy666發表於2020-10-08

問題描述

  • 問題現象
    海量使用者
    高併發
  • 罪魁禍首--------關係型資料庫
  1. 效能瓶頸:磁碟IO效能低下
  2. 擴充套件瓶頸:資料關係複雜,擴充套件性差,不便於大規模叢集
  • 解決思路
  1. 降低磁碟IO次數,越低越好 ------記憶體儲存
  2. 去除資料間關係,越簡單越好 ---------不儲存關係,僅儲存資料

Nosql:即Not-only SQL(泛指非關係型的資料庫),作為關係型資料庫的補充。
作用: 應對基於海量使用者和海量資料前提下的資料處理問題。
常見的Nosql資料庫:
Redis、memcache、HBase、MongoDB

解決方案

在這裡插入圖片描述

redis概念以及特徵

概念:Redis (REmote DIctionary Server) 是用 C 語言開發的一個開源的高效能鍵值對(key-value)資料庫。
特徵:

  • 資料間沒有必然的關聯關係
  • 內部採用單執行緒機制進行工作
  • 高效能
  • 多資料型別支援【value的型別】(字串型別 string、列表型別 list、雜湊型別 hash、集合型別set、有序集合型別 sorted_set)
  • 持久化支援,可以進行資料災難恢復

redis支援的資料型別

String:

  • redis用於控制資料庫表主鍵id,為資料庫表主鍵提供生成策略,保障資料庫表的主鍵唯一性incr(decr) key/ incrby key increment
    此方案適用於所有資料庫,且支援資料庫叢集
  • redis 控制資料的生命週期,通過資料是否失效控制業務行為,適用於所有具有時效性限定控制的操作(setex key seconds value
  • redis應用於各種結構型和非結構型高熱度資料訪問加速

Hash:
儲存物件資訊,一個儲存空間儲存多個鍵值對資料,底層使用雜湊表結構實現資料儲存

  • redis 應用於購物車資料儲存設計
  • redis 應用於搶購,限購類、限量發放優惠卷、啟用碼等業務的資料儲存設計

List:
儲存多個資料,並對資料進入儲存空間的 順序 進行區分,底層使用 雙向連結串列 儲存結構實現

  • redis 應用於最新訊息展示( 微信朋友圈點贊,要求按照點贊順序顯示點贊好友資訊、騰訊微博中個人使用者的關注列表需要按照使用者的關注順序進行展示)

Set:
儲存大量的資料,在查詢方面提供更高的效率,:與hash儲存結構完全相同,僅儲存鍵,不儲存值(nil),並且值是不允許重複的。

  • redis 應用於隨機推薦類資訊檢索,例如熱點歌單推薦,熱點新聞推薦,熱賣旅遊線路,應用APP推薦,大V推薦等
  • redis 應用於同類資訊的關聯搜尋,二度關聯搜尋,深度關聯搜尋(交併比)
  • redis 應用於同型別資料的快速去重
  • redis 應用於基於黑名單與白名單設定的服務控制

Sorted_set:
資料排序有利於資料的有效展示,需要提供一種可以根據自身特徵進行排序的方式,在set的儲存結構基礎上新增可排序欄位

  • redis 應用於計數器組合排序功能對應的排名
  • redis 應用於定時任務執行順序管理或任務過期管理
  • redis 應用於即時任務/訊息佇列執行管理

redis支援的高階資料型別

Bitmaps:
在這裡插入圖片描述
redis 應用於資訊狀態統計

HyperLogLog:
基數是資料集去重後元素個數
HyperLogLog 是用來做基數統計的,運用了LogLog的演算法

GEO:
redis 應用於地理位置計算

持久化

為了防止資料的意外丟失,確保資料安全性,利用永久性儲存介質將資料進行儲存,在特定的時間將儲存的資料進行恢復的工作機制稱為持久化
在這裡插入圖片描述

RDB啟動方式:

  • save:手動執行一次儲存操作(save指令的執行會阻塞當前Redis伺服器,直到當前RDB過程完成為止,有可能會造成長時間阻塞,線上環境不建議使用。)
  • bgsave:手動啟動後臺儲存操作,但不是立即執行(bgsave命令是針對save阻塞問題做的優化。Redis內部所有涉及到RDB操作都採用bgsave的方式,save命令可以放棄使用)
  • save配置:滿足限定時間範圍內key的變化數量達到指定數量即進行持久化(save second changes second:監控時間範圍,changes:監控key的變化量)
    在這裡插入圖片描述

AOF(append only file):

以獨立日誌的方式記錄每次寫命令,重啟時再重新執行AOF檔案中命令達到恢復資料的目的。與RDB相比可以簡單描述為改記錄資料為記錄資料產生的過程,解決了資料持久化的實時性,目前已經是Redis持久化的主流方式.
AOF寫資料三種策略(appendfsync):always(每次 效能較低)、 everysec(每秒 效能較高)、no(系統控制)
AOF重寫:
隨著命令不斷寫入AOF,檔案會越來越大,為了解決這個問題,Redis引入了AOF重寫機制壓縮檔案體積。AOF檔案重寫是將Redis程式內的資料轉化為寫命令同步到新AOF檔案的過程。簡單說就是將對同一個資料的若干個條命令執行結果轉化成最終結果資料對應的指令進行記錄。

AOF重寫作用:
降低磁碟佔用量,提高磁碟利用率
提高持久化效率,降低持久化寫時間,提高IO效能
降低資料恢復用時,提高資料恢復效率

AOF重寫規則:

  • 程式內已超時的資料不再寫入檔案
  • 忽略無效指令,重寫時使用程式內資料直接生成,這樣新的AOF檔案只保留最終資料的寫入命令
  • 對同一資料的多條寫命令合併為一條命令

AOF重寫方式:

  1. 手動重寫(bgrewriteaof)
  2. 自動重寫(auto-aof-rewrite-min-size size)

在這裡插入圖片描述

redis事務與鎖

開啟事務:multi 建立佇列
執行事務:exec
取消事務:discard

監視鎖: 對 key 新增監視鎖,在執行exec前如果key發生了變化,終止事務執行(watch key
取消對所有 key 的監視(unwatch
分散式鎖: 使用 setnx 設定一個公共鎖(setnx lock-key value
利用setnx命令的返回值特徵,有值則返回設定失敗,無值則返回設定成功。對於返回設定成功的,擁有控制權,進行下一步的具體業務操作;對於返回設定失敗的,不具有控制權,排隊或等待。 操作完畢通過del操作釋放鎖。
分散式鎖改良: 使用 expire 為鎖key新增時間限定,到時不釋放,放棄鎖(expire lock-key second

redis 刪除策略與逐出演算法

刪除策略

redis 是一種記憶體級資料庫,所有資料均存放在記憶體中,記憶體中的資料可以通過TTL指令獲取其狀態。
xx:具有時效性的資料
-1:永久有效的資料
-2 :已經過期的資料 或 被刪除的資料 或 未定義的資料

過期資料刪除策略:

  1. 定時刪除(建立一個定時器,當key設定有過期時間,且過期時間到達時,由定時器任務立即執行對鍵的刪除操作)
    優點:節約記憶體,到時就刪除,快速釋放掉不必要的記憶體佔用
    缺點:CPU壓力很大,無論CPU此時負載量多高,均佔用CPU,會影響redis伺服器響應時間和指令吞吐量
    總結:用處理器效能換取儲存空間(拿時間換空間)

  2. 惰性刪除(資料到達過期時間,不做處理。等下次訪問該資料時,如果未過期,返回資料;發現已過期,刪除,返回不存在)
    優點:節約CPU效能,發現必須刪除的時候才刪除
    缺點:記憶體壓力很大,出現長期佔用記憶體的資料
    總結:用儲存空間換取處理器效能 (拿時間換空間)
    每當get name的時候,會呼叫expireIfNeeded()檢視是否過期

折中方案
3. 定期刪除(週期性輪詢redis庫中的時效性資料,採用隨機抽取的策略,利用過期資料佔比的方式控制刪除頻度)
總結:週期性抽查儲存空間(隨機抽查,重點抽查)
在這裡插入圖片描述

逐出演算法

Redis使用記憶體儲存資料,在執行每一個命令前,會呼叫freeMemoryIfNeeded()檢測記憶體是否充足如果記憶體不滿足新加入資料的最低儲存要求,redis要臨時刪除一些資料為當前指令清理儲存空間。清理資料的策略稱為逐出演算法
在這裡插入圖片描述

主從複製

在這裡插入圖片描述
在這裡插入圖片描述

在這裡插入圖片描述
在這裡插入圖片描述

哨兵模式

哨兵(sentinel) 是一個分散式系統,用於對主從結構中的每臺伺服器進行監控,當出現故障時通過投票機制選擇新的master並將所有slave連線到新的master。哨兵也是一臺redis伺服器,只是不提供資料服務。通常哨兵配置數量為單數
哨兵的作用:

  • 監控(不斷的檢查master和slave是否正常執行。master存活檢測、master與slave執行情況檢測)
  • 通知/提醒(當被監控的伺服器出現問題時,向其他(哨兵間,客戶端)傳送通知。)
  • 自動故障轉移(斷開master與slave連線,選取一個slave作為master,將其他slave連線到新的master,並告知客戶端新的伺服器地址)

叢集

叢集就是使用網路將若干臺計算機聯通起來,並提供統一的管理方式,使其對外呈現單機的服務效果
叢集作用:
 分散單臺伺服器的訪問壓力,實現負載均衡
 分散單臺伺服器的儲存壓力,實現可擴充套件性
 降低單臺伺服器當機帶來的業務災難
叢集資料儲存設計:

  • 通過演算法設計,計算出key應該儲存的位置
  • 將所有的儲存空間計劃切割成16384份,每臺主機儲存一部分,每份代表的是一個儲存空間,不是一個key的儲存空間
  • 將key按照計算出的結果放到對應的儲存空間

叢集內部通訊設計:

  • 各個資料庫相互通訊,儲存各個庫中槽的編號資料
  • 一次命中,直接返回
  • 一次未命中,告知具體位置

快取預熱:
快取預熱就是系統啟動前,提前將相關的快取資料直接載入到快取系統。避免在使用者請求的時候,先查詢資料庫,然後再將資料快取的問題!使用者直接查詢事先被預熱的快取資料!

快取雪崩:
問題:短時間範圍內,大量key集中過期
快取雪崩就是瞬間過期資料量太大,導致對資料庫伺服器造成壓力。如能夠有效避免過期時間集中,可以有效解決雪崩現象的出現(約40%),配合其他策略一起使用,並監控伺服器的執行資料,根據執行記錄做快速調整

快取擊穿:
問題:單個key高熱資料,key過期
快取擊穿就是單個高熱資料過期的瞬間,**資料訪問量較大,未命中redis後,發起了大量對同一資料的資料庫訪問,**導致對資料庫伺服器造成壓力。應對策略應該在業務資料分析與預防方面進行,配合執行監控測試與即時調整策略,畢竟單個key的過期監控難度較高,配合雪崩處理策略即可。

快取穿透:
問題:redis中大面積出現未命中,出現非正常URL訪問

快取擊穿訪問了不存在的資料,跳過了合法資料的redis資料快取階段,每次訪問資料庫,導致對資料庫伺服器造成壓力。通常此類資料的出現量是一個較低的值,當出現此類情況以毒攻毒,並及時報警。應對策略應該在臨時預案防範方面多做文章。
無論是黑名單還是白名單,都是對整體系統的壓力,警報解除後儘快移除。

=====================================================================================

MongoDB

MongoDB是一個開源、高效能、無模式的文件型資料庫,當初的設計就是用於簡化開發和方便擴充套件,是NoSQL資料庫產品中的一種。是最像關係型資料庫(MySQL)的非關係型資料庫。BTree儲存結構。不支援事務,支援索引遊標等操作,優勢在於查詢功能比較強大,擅長查詢JSON資料,能儲存海量資料。
它支援的資料結構非常鬆散,是一種類似於 JSON 的 格式叫BSON,所以它既可以儲存比較複雜的資料型別,又相當的靈活。
MongoDB的最小儲存單位就是文件(document)物件。文件(document)物件對應於關係型資料庫的行。資料在MongoDB中以
BSON(Binary-JSON)文件的格式儲存在磁碟上。
在這裡插入圖片描述

相關文章