redis相關技術總結


1.一致性哈希分區
 
一致性哈希的目的就是為了在節點數目發生改變時盡可能少的遷移數據,將所有的存儲節點排列在收尾相接的Hash環上,每個key在計算Hash 后會順時針找到臨接的存儲節點存放。而當有節點加入或退 時,僅影響該節點在Hash環上順時針相鄰的后續節點。
 
優點
加入和刪除節點只影響哈希環中順時針方向的相鄰的節點,對其他節點無影響。
 
缺點 
數據的分布和節點的位置有關,因為這些節點不是均勻的分布在哈希環上的,所以數據在進行存儲時達不到均勻分布的效果。
 
虛擬槽分區
 
本質上還是第一種的普通哈希算法,把全部數據離散到指定數量的哈希槽中,把這些哈希槽按照節點數量進行了分區。這樣因為哈希槽的數量的固定的,添加節點也不用把數據遷移到新的哈希槽,只要在節點之間互相遷移就可以了,即保證了數據分布的均勻性,又保證了在添加節點的時候不必遷移過多的數據。
Redis的集群模式使用的就是虛擬槽分區,一共有16383個槽位平均分布到節點上
 
 
2.redis 擴容
 
當新增節點時,將各節點分出一些插槽給新節點,將待遷移插槽放入, 遷出插槽列表中, 使用類似於scan的掃描,進行遷移,遷移過程中有新數據產生
如果有get命令,集群查本地的插槽,有返回,沒有返回ask命令, 客戶端通過ask再次請求新的節點,新節點有則返回,沒有返回空
如果有set命令,節點強制將新key遷移到目標節點
 
 
 
3.為什么redis不是先記日志后響應請求?
redis有兩種功能,一種是做持久化數據庫,一種是做緩存,如果先記請求日志,因為文件io操作是阻塞的,影響redis的性能
 
 
4.redis使用場景:
最主要的是in-memory,高性能,分布式
1.服務端session一致等
2.分布式鎖
3.布隆過濾器(hash緩存所有的有效數據),防止cc攻擊
 
 
5.redis對比memcache有哪些優勢
1.redis可以持久化
2.redis支持多種數據結構
3.redis服務端支持集群,不需要每個客戶端自己做這個事, memcached 不支持主從
4.redis支持的最大value1G, memcahce支持的是1M
 
 
6.Redis有哪幾種數據淘汰策略
1.volatile-lru  最近最少使用的有過期時間的鍵刪除
2.volatile-ttl  快過期的先刪除
3.volatile-random 隨機刪除有過期時間的key
4.allkey-lru
5.allkey-random
6.no-enviction(驅逐):禁止驅逐數據  不淘汰數據
 
 
7.redis集群方案
1.主從: 可以讀寫分離,提高集群的tps, 一般在從庫上持久化
2.哨兵: 主節點down機,可以自動從從節點中選舉主節點,提供服務
3.集群:多個主節點提供寫服務,不同的主節點分配不同的插槽,保存key/value
 
 
8.Redis如何設置密碼及驗證密碼
requirePass yourPass 設置密碼
auth password 驗證密碼
 
9.說說Redis哈希槽的概念
hash槽16384個,虛擬節點,每個真實節點包含多個虛擬節點,當擴容縮容時,只需要遷移部分槽中的key,(擴容時,只需要遷移少部分數據,叫一致性hash)
 
10.Redis集群的主從復制模型是怎樣的
從節點打開slaveof ip port ,設為某個節點的從庫,第一次接入時,主庫執行一次bgsave,將內存中的數據同步到從數據庫,從節點成功rdb文件,然后解析rdb文件,恢復數據,這段時間內,產生的數據會放在緩沖區中
當從庫同步完rdb文件后,會增量同步,緩沖區里的數據,如果緩存區設置太小,那么主節點再次bgsave影響主節點的響應
 
11.edis集群會有寫操作丟失嗎?為什么
會,同步日志都是異步的,當redis主機down的時候,寫入是會丟失的
如果是rdb備份,是定時備份,上次備份到down機的時間內,寫操作都丟失
aof備份有幾個選項
appendonly no 需要打開
# appendfsync always
appendfsync everysec
# appendfsync no
 
 
11.Redis中的管道有什么用
將多個命令一起發到redis,減少網絡延遲
 
12.怎么理解Redis事務?
redis事務三階段:
 
    開啟:以MULTI開始一個事務
    入隊:將多個命令入隊到事務中,接到這些命令並不會立即執行,而是放到等待執行的事務隊列里面
    執行:由EXEC命令觸發事務
redis事務三大特性:
單獨的隔離操作:事務中的所有命令都會序列化、按順序地執行。事務在執行的過程中,不會被其他客戶端發送來的命令請求所打斷。
沒有隔離級別的概念:隊列中的命令沒有提交之前都不會實際的被執行,因為事務提交前任何指令都不會被實際執行,也就不存在”事務內的查詢要看到事務里的更新,在事務外查詢不能看到”這個讓人萬分頭痛的問題
不保證原子性:redis同一個事務中如果有一條命令執行失敗,其后的命令仍然會被執行,沒有回滾
 
13.Redis事務相關的命令有哪幾個
multi  exec  discard取消  watch 監控 樂觀鎖,一致性
 
 
14.Redis如何做內存優化
1.對象共享:數字
2.壓縮結構:編碼優化
3.內存回收
 
 
 
 
分區是分割數據到多個Redis實例的處理過程,因此每個實例只保存key的一個子集。
分區的優勢
 
    通過利用多台計算機內存的和值,允許我們構造更大的數據庫。
    通過多核和多台計算機,允許我們擴展計算能力;通過多台計算機和網絡適配器,允許我們擴展網絡帶寬。
 
分區的不足
 
redis的一些特性在分區方面表現的不是很好:
 
    涉及多個key的操作通常是不被支持的。舉例來說,當兩個set映射到不同的redis實例上時,你就不能對這兩個set執行交集操作。
    涉及多個key的redis事務不能使用。
    當使用分區時,數據處理較為復雜,比如你需要處理多個rdb/aof文件,並且從多個實例和主機備份持久化文件。
    增加或刪除容量也比較復雜。redis集群大多數支持在運行時增加、刪除節點的透明數據平衡的能力,但是類似於客戶端分區、代理等其他系統則不支持這項特性。然而,一種叫做presharding的技術對此是有幫助的。
 
 
Redis常見性能問題和解決方案:
 
    Master最好不要做任何持久化工作,如RDB內存快照和AOF日志文件
    如果數據比較重要,某個Slave開啟AOF備份數據,策略設置為每秒同步一次
    為了主從復制的速度和連接的穩定性,Master和Slave最好在同一個局域網內
    盡量避免在壓力很大的主庫上增加從庫
 
 
COW技術原理(Copy On Write,寫時復制)
在復制一個對象的時候並不是真正的把原先的對象復制到內存的另外一個位置上,而是在新對象的內存映射表中設置一個指針,指向源對象的位置,並把那塊內存的Copy-On-Write位設置為1.
 
這樣,在對新的對象執行讀操作的時候,內存數據不發生任何變動,直接執行讀操作;而在對新的對象執行寫操作時,將真正的對象復制到新的內存地址中,並修改新對象的內存映射表指向這個新的位置,並在新的內存位置上執行寫操作。
 
這個技術需要跟虛擬內存和分頁同時使用,好處就是在執行復制操作時因為不是真正的內存復制,而只是建立了一個指針,因而大大提高效率。但這不是一直成立的,如果在復制新對象之后,大部分對象都還需要繼續進行寫操作會產生大量的分頁錯誤,得不償失。所以COW高效的情況只是在復制新對象之后,在一小部分的內存分頁上進行寫操作。
 
 
redis 持久化
RDB  AOF
RDB 默認的持久化方式 有save bgsave(cow  不阻塞的copy)  定時復制
save m n   m秒寫入多少次,觸發
aof 需要打開開關


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM