① redis或者緩存系統有批量刪除的機制嗎
Ehcache 中可以像樓上說的那樣，@Cacheable 產生緩存是以 key-value形式產生的，刪除也是。
memcached 也是同樣的。
具體的想批量清除緩存，你可以手動的清除
先取出 緩存塊中的所有緩存，然後根據key值前綴取出目標 key放到list中，手動調用清除方法
② Redis的主要功能
緩存：這應該是 Redis 最主要的功能了，也是大型網站必備機制，合理地使用緩存不僅可以加 快數據的訪問速度，而且能夠有效地降低後端數據源的壓力。共享Session：對於一些依賴 session 功能的服務來說，如果需要從單機變成集群的話，可以選擇 redis 來統一管理 session。消息隊列系統：消息隊列系統可以說是一個大型網站的必備基礎組件，因為其具有業務 解耦、非實時業務削峰等特性。Redis提供了發布訂閱功能和阻塞隊列的功 能，雖然和專業的消息隊列比還不夠足夠強大，但是對於一般的消息隊列功 能基本可以滿足。比如在分布式爬蟲系統中，使用 redis 來統一管理 url隊列。分布式鎖：在分布式服務中。可以利用Redis的setnx功能來編寫分布式的鎖，雖然這個可能不是太常用。 當然還有諸如排行榜、點贊功能都可以使用 Redis 來實現，但是 Redis 也不是什麼都可以做，比如數據量特別大時，不適合 Redis，我們知道 Redis 是基於內存的，雖然內存很便宜，但是如果你每天的數據量特別大，比如幾億條的
用戶行為日誌數據，用 Redis 來存儲的話，成本相當的高。
③ 大量數據能緩存到redis裡面嗎
不適合引子：
在大數據時代，總希望存在一個Key-value存儲機制，像HashMap一樣在內存中處理大量（千萬數量級）的key-value對，以便提高數據查找、修改速度。
所以，我們會想到，Memcached和Redis這兩個Nosql資料庫（嚴格來講二者都不可以算作資料庫）。
1、Memcached是一個cache機制，當內存不足時會採用LRU機制，替換出陳舊數據，因此他不能保證我們的數據像在HashMap中一樣不丟失，且沒有數據持久化機制；
2、Redis克服了這一缺點，採取磁碟存儲機制實現數據持久化。但是，當數據量達到1千萬左右時，由於內存中不能存儲如此大量數目的數據，頻繁同磁碟進行數據交換，導致數據查詢、存儲性能的急劇下降，將導致服務不可用。
結論：當前還沒有好的產品可以實現key-value保證數據完整性，千萬級條數量級的，高效存儲和查詢支持產品。
附錄一：如下是轉自其它網友的測試數據：
附錄二：memcached 和redis的比較，和各自用途
附錄一：
從圖中可以猜測到還會有Redis 2.2.1 的測試，相同的測試環境，1K的數據量，使用ServiceStack.Redis客戶端進行如下測試：
1) Set操作
2) Get操作
3) Del操作
每一套測試分別使用三個配置進行測試：
1) 綠色線條的是開啟Dump方式的持久化，5分鍾持久化一次
2) 藍色線條是開啟AOF方式的持久化，每秒寫入磁碟一次
3) 紅色線條是關閉任何的持久化方式
對於每一個配置都使用相同的其他配置：
1) 開啟VM 最大內存10GB(128位元組一
④ 京東面試官：Redis 這些我必問
緩存好處：高性能 + 高並發
資料庫查詢耗費了800ms，其他用戶對同一個數據再次查詢 ，假設該數據在10分鍾以內沒有變化過，並且 10 分鍾之內有 1000 個用戶 都查詢了同一數據，10 分鍾之內，那 1000 每個用戶，每個人查詢這個數據都感覺很慢 800ms
比如 ：某個商品信息，在 一天之內都不會改變，但是這個商品每次查詢一次都要耗費2s，一天之內被瀏覽 100W次
mysql 單機也就 2000qps,緩存單機輕松幾萬幾十萬qps,單機 承載並發量是 mysql 單機的幾十倍。
在中午高峰期，有 100W 個用戶訪問系統 A，每秒有 4000 個請求去查詢資料庫，資料庫承載每秒 4000 個請求會宕機，加上緩存後，可以 3000 個請求走緩存 ，1000 個請求走資料庫。
緩存是走內存的，內存天然可以支撐4w/s的請求，資料庫（基於磁碟）一般建議並發請求不要超過 2000/s
redis 單線程 ，memcached 多線程
redis 是單線程 nio 非同步線程模型
一個線程+一個隊列
redis 基於 reactor 模式開發了網路事件處理器，這個處理器叫做文件事件處理器，file event handler，這個文件事件處理器是單線程的，所以redis 是單線程的模型，採用 io多路復用機制同時監聽多個 socket,根據socket上的事件來選擇對應的事件處理器來處理這個事件。
文件事件處理器包含：多個 socket,io多路復用程序，文件事件分派器，事件處理器（命令請求處理器、命令恢復處理器、連接應答處理器）
文件事件處理器是單線程的，通過 io 多路復用機制監聽多個 socket，實現高性能和線程模型簡單性
被監聽的 socket 准備好執行 accept,read,write,close等操作的時候，會產生對應的文件事件，調用之前關聯好的時間處理器處理
多個 socket並發操作，產生不同的文件事件，i/o多路復用會監聽多個socket，將這些 socket放入一個隊列中排隊。事件分派器從隊列中取出socket給對應事件處理器。
一個socket時間處理完後，事件分派器才能從隊列中拿到下一個socket，給對應事件處理器來處理。
文件事件：
AE_READABLE 對應 socket變得可讀（客戶端對redis執行 write操作）
AE_WRITABLE 對應 socket 變得可寫（客戶端對 redis執行 read操作）
I/O 多路復用可以同時監聽AE_REABLE和 AE_WRITABLE ，如果同時達到則優先處理 AE_REABLE 時間
文件事件處理器：
連接應答處理器 對應 客戶端要連接 redis
命令請求處理器 對應 客戶端寫數據到 redis
命令回復處理器 對應 客戶端從 redis 讀數據
流程：
一秒鍾可以處理幾萬個請求
普通的 set,get kv緩存
類型 map結構，比如一個對象（沒有嵌套對象）緩存到 redis裡面，然後讀寫緩存的時候，可以直接操作hash的欄位（比如把 age 改成 21，其他的不變）
key=150
value = {
}
有序列表 ，元素可以重復
可以通過 list 存儲一些列表型數據結構，類似粉絲列表，文章評論列表。
例如：微信大 V的粉絲，可以以 list 的格式放在 redis 里去緩存
key=某大 V value=[zhangsan,lisi,wangwu]
比如 lrange 可以從某個元素開始讀取多少個元素，可以基於 list 實現分頁查詢功能，基於 redis實現高性能分頁，類似微博下來不斷分頁東西。
可以搞個簡單的消息隊列，從 list頭懟進去（lpush），list尾巴出來 (brpop)
無序集合，自動去重
需要對一些數據快速全局去重，（當然也可以基於 HashSet，但是單機）
基於 set 玩差集、並集、交集的操作。比如：2 個人的粉絲列表整一個交集，看看 2 個人的共同好友是誰？
把 2 個大 V 的粉絲都放在 2 個 set中，對 2 個 set做交集（sinter）
排序的 set，去重但是可以排序，寫進去的時候給一個分數，自動根據分數排序
排行榜：
zadd board score username
例如：
zadd board 85 zhangsan
zadd board 72 wangwu
zadd board 96 lis
zadd board 62 zhaoliu
自動排序為：
96 lisi
85 zhangsan
72 wangwu
62 zhaoliu
獲取排名前 3 的用戶 ： zrevrange board 0 3
96 lisi
85 zhangsan
72 wangwu
查看zhaoliu的排行 ：zrank board zhaoliu 返回 4
內存是寶貴的，磁碟是廉價的
給key設置過期時間後，redis對這批key是定期刪除+惰性刪除
定期刪除：
redis 默認每隔 100ms隨機抽取一些設置了過期時間的 key，檢查其是否過期了，如果過期就刪除。
注意：redis是每隔100ms隨機抽取一些 key來檢查和刪除，而不是遍歷所有的設置過期時間的key（否則CPU 負載會很高，消耗在檢查過期 key 上）
惰性刪除：
獲取某個key的時候， redis 會檢查一下，這個key如果設置了過期時間那麼是否過期，如果過期了則刪除。
如果定期刪除漏掉了許多過期key，然後你也沒及時去查，也沒走惰性刪除，如果大量過期的key堆積在內存里，導致 redis 內存塊耗盡，則走內存淘汰機制。
內存淘汰策略：
LRU 演算法：
緩存架構（多級緩存架構、熱點緩存）
redis 高並發瓶頸在單機，讀寫分離，一般是支撐讀高並發，寫請求少，也就 一秒一兩千，大量請求讀，一秒鍾二十萬次。
一主多從，主負責寫，將數據同步復制到其他 slave節點，從節點負責讀，所有讀的請求全部走從節點。主要是解決讀高並發。、
主從架構->讀寫分離->支撐10W+讀QPS架構
master->slave 復制，是非同步的
核心機制：
master持久化對主從架構的意義：
如果開啟了主從架構，一定要開啟 master node的持久化，不然 master宕機重啟數據是空的，一經復制，slave的數據也丟了
主從復制原理：
第一次啟動或者斷開重連情況：
正常情況下：
master 來一條數據，就非同步給 slave
全年 99.99%的時間，都是出於可用的狀態，那麼就可以稱為高可用性
redis 高可用架構叫故障轉移，failover，也可以叫做主備切換，切換的時間不可用，但是整體高可用。
sentinal node(哨兵)
作用：
quorum = 1 （代表哨兵最低個數可以嘗試故障轉移，選舉執行的哨兵）
master 宕機，只有 S2 存活，因為 quorum =1 可以嘗試故障轉移，但是沒達到 majority =2 （最低允許執行故障轉移的哨兵存活數）的標准，無法執行故障轉移
如果 M1 宕機了，S2,S3 認為 master宕機，選舉一個執行故障轉移，因為 3 個哨兵的 majority = 2，所以可以執行故障轉移
丟數據：
解決方案：
sdown 主觀宕機，哨兵覺得一個 master 宕機（ping 超過了 is-master-down-after-milliseconds毫秒數）
odown 客觀宕機，quorum數量的哨兵都覺得 master宕機
哨兵互相感知通過 redis的 pub/sub系統，每隔 2 秒往同一個 channel里發消息（自己的 host,ip,runid），其他哨兵可以消費這個消息
以及同步交換master的監控信息。
哨兵確保其他slave修改master信息為新選舉的master
當一個 master被認為 odown && marjority哨兵都同意，那麼某個哨兵會執行主備切換，選舉一個slave成為master（考慮 1. 跟master斷開連接的時長 2. slave 優先順序 3.復制 offset 4. runid）
選舉演算法：
quorum 數量哨兵認為odown->選舉一個哨兵切換->獲得 majority哨兵的授權（quorum majority 需要 majority個哨兵授權，quorum >= majority 需要 quorum 哨兵授權）
第一個選舉出來的哨兵切換失敗了，其他哨兵等待 failover-time之後，重新拿confiuration epoch做為新的version 切換，保證拿到最新配置，用於 configuration傳播（通過 pu/sub消息機制，其他哨兵對比 version 新舊更新 master配置）
高並發：主從架構
高容量：Redis集群，支持每秒幾十萬的讀寫並發
高可用：主從+哨兵
持久化的意義在於故障恢復數據備份（到其他伺服器）+故障恢復（遇到災難，機房斷電，電纜被切）
AOF 只有一個，Redis 中的數據是有一定限量的，內存大小是一定的,AOF 是存放寫命令的，當大到一定的時候，AOF 做 rewrite 操作，就會基於當時 redis 內存中的數據，來重新構造一個更小的 AOF 文件，然後將舊的膨脹很大的文件給刪掉，AOF 文件一直會被限制在和Redis內存中一樣的數據。AOF同步間隔比 RDB 小，數據更完整
優點：
缺點：
AOF 存放的指令日誌，數據恢復的時候，需要回放執行所有指令日誌，RDB 就是一份數據文件，直接載入到內存中。
優點：
缺點：
AOF 來保證數據不丟失，RDB 做不同時間的冷備
支持 N 個 Redis master node,每個 master node掛載多個 slave node
多master + 讀寫分離 + 高可用
數據量很少，高並發 -> replication + sentinal 集群
海量數據 + 高並發 + 高可用 -> redis cluster
hash演算法->一致性 hash 演算法-> redis cluster->hash slot演算法
redis cluster :自動對數據進行分片，每個 master 上放一部分數據，提供內置的高可用支持，部分master不可用時，還是可以繼續工作
cluster bus 通過 16379進行通信，故障檢測，配置更新，故障轉移授權，另外一種二進制協議，主要用於節點間進行高效數據交換，佔用更少的網路帶寬和處理時間
key進行hash，然後對節點數量取模，最大問題只有任意一個 master 宕機，大量數據就要根據新的節點數取模，會導致大量緩存失效。
key進行hash，對應圓環上一個點，順時針尋找距離最近的一個點。保證任何一個 master 宕機，只受 master 宕機那台影響，其他節點不受影響，此時會瞬間去查資料庫。
緩存熱點問題：
可能集中在某個 hash區間內的值特別多，那麼會導致大量的數據都湧入同一個 master 內，造成 master的熱點問題，性能出現瓶頸。
解決方法：
給每個 master 都做了均勻分布的虛擬節點，這樣每個區間內大量數據都會均勻的分布到不同節點內，而不是順時針全部湧入到同一個節點中。
redis cluster 有固定 16384 個 hash slot,對每個key計算 CRC16 值，然後對16384取模，可以獲取 key對應的 hash slot
redis cluster 中每個 master 都會持有部分 slot ,當一台 master 宕機時候，會最快速度遷移 hash slot到可用的機器上（只會短暫的訪問不到）
走同一個 hash slot 通過 hash tag實現
集群元數據：包括 hashslot->node之間的映射表關系，master->slave之間的關系，故障的信息
集群元數據集中式存儲（storm），底層基於zookeeper（分布式協調中間件）集群所有元數據的維護。好處：元數據的更新和讀取，時效性好，一旦變更，其他節點立刻可以感知。缺點：所有元數據的更新壓力全部集中在一個地方，可能會導致元數據的存儲有壓力。
goosip: 好處：元數據的更新比較分散，有一定的延時，降低了壓力。缺點：更新有延時，集群的一些操作會滯後。（reshared操作時configuration error）
自己提供服務的埠號+ 10000 ，每隔一段時間就會往另外幾個節點發送ping消息，同時其他幾點接收到ping之後返回pong
故障信息，節點的增加和移除， hash slot 信息
meet:某個節點發送 meet給新加入的節點，讓新節點加入集群中，然後新節點就會開始於其他節點進行通信
ping:每個節點都會頻繁給其他節點發送ping，其中包含自己的狀態還有自己維護的集群元數據，互相通過ping交換元數據
ping:返回ping和meet，包含自己的狀態和其他信息
fail:某個節點判斷另一個節點fail之後，就發送 fail 給其他節點，通知其他節點，指定的節點宕機了
ping 很頻繁，且攜帶元數據，會加重網路負擔
每個節點每秒會執行 10 次 ping，每次選擇 5 個最久沒有通信的其他節點
當如果發現某個節點通信延遲達到了 cluster_node_timeout /2 ，那麼立即發送 ping， 避免數據交換延遲過長，落後時間太長（2 個節點之間 10 分鍾沒有交換數據，整個集群處於嚴重的元數據不一致的情況）。
每次ping，一個是帶上自己的節點信息，還有就是帶上1/10其他節點的信息，發送出去，進行數據交換
至少包含 3 個其他節點信息，最多包含總節點-2 個其他節點的信息
客戶端發送到任意一個redis實例發送命令，每個redis實例接受到命令後，都會計算key對應的hash slot，如果在本地就本地處理，否則返回moved給客戶端，讓客戶端進行重定向 （redis-cli -c）
通過tag指定key對應的slot,同一個 tag 下的 key，都會在一個 hash slot中，比如 set key1:{100} 和 set key2:{100}
本地維護一份hashslot->node的映射表。
JedisCluster 初始化的時候，隨機選擇一個 node，初始化 hashslot->node 映射表，同時為每個節點創建一個JedisPool連接池，每次基於JedisCluster執行操作，首先JedisCluster都會在本地計算key的hashslot，然後再本地映射表中找到對應的節點，如果發現對應的節點返回moved，那麼利用該節點的元數據，更新 hashslot->node映射表（重試超過 5 次報錯）
hash slot正在遷移，那麼會返回ask 重定向給jedis,jedis 接受到ask重定向之後，，會重定向到目標節點去執行
判斷節點宕機：
如果一個節點認為另外一個節點宕機了， 就是pfail,主觀宕機
如果多個節點都認為另外一個節點宕機了，那麼就是fail，客觀宕機（跟哨兵原理一樣）
在cluster-node-timeout內，某個節點一直沒有返回 pong,那麼就被認為是 pfail
如果一個節點認為某個節點pfail了，那麼會在gossip消息中，ping給其他節點，如果超過半數的節點認為pfail了，那麼就會變成fail。
從節點過濾：
對宕機的 mster node ，從其所有的 slave node中，選擇一個切換成 master node
檢查每個 slave node與master node斷開連接的時間，如果超過了cluster-node-timeout * cluster-slave-validity-factor，那麼就沒資格切換成 master（和哨兵一致）
從節點選舉：
每個從節點，根據自己對 master 復制數據的 offset，設置一個選舉時間，offset越大（復制數據越多）的從節點，選舉時間越靠前，所有的 master node 開始投票，給要進行選舉的 slave進行投票，如果大部分 master node(N/2 +1) 都投票給某個從節點，那麼選舉通過，從節點執行主備切換，從節點切換成主節點
總結：和哨兵很像，直接集成了 replication 和 sentinal
方案：
事前：保證 redis 集群高可用性 （主從+哨兵或 redis cluster），避免全盤崩潰
事中：本地 ehcache 緩存 + hystrix 限流（保護資料庫） & 降級，避免 MySQL被打死
事後： redis持久化，快速恢復緩存數據，繼續分流高並發請求
限制組件每秒就 2000 個請求通過限流組件進入資料庫，剩餘的 3000 個請求走降級，返回一些默認 的值，或者友情提示
好處 ：
4000 個請求黑客攻擊請求資料庫里沒有的數據
解決方案：把黑客查資料庫中不存在的數據的值，寫到緩存中，比如： set -999 UNKNOWN
讀的時候，先讀緩存，緩存沒有，就讀資料庫，然後取出數據後放入緩存，同時返回響應
更新的時候，刪除緩存，更新資料庫
為什麼不更新緩存：
更新緩存代價太高（更新 20 次，只讀 1 次），lazy思想，需要的時候再計算，不需要的時候不計算
方案：先刪除緩存，再修改資料庫
方案：寫，讀路由到相同的一個內存隊列（唯一標識，hash，取模）里，更新和讀操作進行串列化（後台線程非同步執行隊列串列化操作），（隊列里只放一個更新查詢操作即可，多餘的過濾掉，內存隊列里沒有該數據更新操作，直接返回 ）有該數據更新操作則輪詢取緩存值，超時取不到緩存值，直接取一次資料庫的舊值
TP 99 意思是99%的請求可以在200ms內返回
注意點：多個商品的更新操作都積壓在一個隊列裡面（太多操作積壓只能增加機器），導致讀請求發生大量的超時，導致大量的讀請求走資料庫
一秒 500 寫操作，每200ms，100 個寫操作，20 個內存隊列，每個隊列積壓 5 個寫操作，一般在20ms完成
方案：分布式鎖 + 時間戳比較
10台機器，5 主 5 從，每個節點QPS 5W ，一共 25W QPS（Redis cluster 32G + 8 核 ，Redis 進程不超過 10G）總內存 50g，每條數據10kb，10W 條數據1g，200W 條數據 20G，佔用總內存不到50%，目前高峰期 3500 QPS
作者： mousycoder
⑤ Redis持久化策略(看這篇,你肯定會有所獲)
RDB：Redis DataBase ， 記錄快照
RDB是redis 默認的持久化方案. RDB 是當滿足一定條件時, 就會將redis內存中的數據寫入磁碟,並生成一個快照文件mp.rdb 文件.Redis 重啟會通過載入mp.rdb文件恢復數據.
一定條件分為以下幾種情況: 1.自動觸發 2. 手動觸發 . 下面分開說明下:
a).redis.conf 中 SNAPSHOTTING 其中定義了觸發把數據保存到磁碟的觸發頻率.
如果不需要rdb 方案, 注釋save 或者配置成空字元串" ".
save 900 1 #900秒內至少有一個key被修改(包括添加)
save 300 10 #400秒內至少10個key被修改
save 10000 #60秒內至少有10000個key 被修改.
這三條配置不沖突, 只要滿足一條就觸發.
rdb 文件位置和目錄 (默認在安裝根目錄下)
#文件路徑
dir ./
#文件名稱
dbfilename mp.rdb
#是否以LZY壓縮rdb 文件
rdbcompression yes
#開啟數據校驗
rdbchecksum yes
b) shutdown觸發 ,保證伺服器正常關閉.
c) flushall , rdb文件是空的, 會生成一個空的文件,所以這種情況也沒有什麼意義.但需要知道,這種情況下
會觸發生成rdb文件.
Redis 提供了兩條命令: save 和 bgsave
a). save 命令
save 在生成快照的時候會阻塞當前Redis 伺服器,Redis不能處理其他命令.如果內存數據較多,會造成
b).bgsave 命令
執行bgsave命令時, Redis會在後台進行非同步快照操作,快照同時還可以響應客戶端請求.
具體操作
具體操作:Redis進程會執行fork操作創建子進程(-on-write),RDB 持久化過程由子進程負載,完成後自動結束.它不會記錄fork之後產生的記錄.阻塞只發送在fork階段,一般時間較短.
一.優勢
1.RDB是一個非常緊湊的文件,它保存了Redis在某個時間點上的數據集.這種文件非常適合進行備份和
災難恢復.
2.生成RDB文件的時候,redis主進程會fork()一個子進程來處理所有保存的工作,主進程不需要進行任何
IO操作.
3.RDB在恢復大數據集時的速度比AOF的恢復速度要快
二.劣勢
1).RDB 沒辦法做到實時持久化/妙級持久化.因為bgsave每次運行都要執行fork創建子進程,頻繁執行成本過高.
2).在一定間隔時間做一次備份,所以如果Redis 以為down掉的話,就會丟失最後一次快照之後所有修改
(數據有丟失)
AOF：<Append Only File> ， 記錄日誌
Redis 默認不開啟.AOF採用日誌的形式來記錄每個寫操作,並追加到文件中.開啟後,執行更改Redis 命令時,就會把命令寫入到AOF文件中.
Redis 重啟時會根據日誌文件的內容把寫指令從前往後執行一次以完成數據的恢復工作.
#開關
appendonly no
#文件名
appendfilename "appendonly.aof"
由於操作系統緩存機制,AOF數據並沒有真正地寫入硬碟,而是進入了系統的硬碟緩存.什麼時候
把緩沖區的內容寫入到AOF文件中? 由下面參數決定
appendfsync : 值: no \ always \everysec
no: 表示不執行fync, 由操作系統保證數據同步到磁碟,速度最快,但是不安全.
always:表示每次寫入都執行fync,以保證數據同步到磁碟,效率很低
everysec:表示每秒執行以fync ,可能會導致丟失1s數據.通常選擇everysec,兼顧效率和安全性.
因為AOF文件只有一個, 隨著redis 不斷進行,AOF 的文件會越來越大,文件越大, 文件佔用伺服器內存
以及AOF恢復要求時間越長.
為了解決這個問題,可以使用bgwriteaof來重寫.那什麼時候重寫? 又是怎樣重寫?
一. 什麼時候重寫?
#重寫觸發機制
auto-aof-rewrite-percentage 100 默認值是100. 當前aof 文件大小超過 上一次重寫的aof文件大小百分之多少進行重寫,即當aof文件增長到一定大小時,Redis能夠調用bgwriteaof對日誌文件進行重寫.當前aof文件大小是上次日誌重寫得到aof文件大小的二倍時, 自動啟動新的日誌重寫過程.
auto-aof-rewrite-min-size 默認是64M.設置允許重寫的最小aof文件大小,避免達到了約定百分比 但尺寸
仍然很小的情況還要重寫.
二. 怎樣重寫?
並不是對原文件進行重新整理,而是直接讀取伺服器上現有的鍵值對,然後用一條命令去代替之間記錄這
個鍵值對的多條命令,生成一個新的文件後去替換原來的 AOF文件.
看下面這兩個參數:
no-appendfsync-on-rewrite
aof-load-truncated
AOF 數據恢復
重啟Redis之後就會進行AOF文件恢復.
AOF 的優勢和劣勢
優點:
1.AOF 持久化的方法提供了多種的同步頻率,即使使用默認的同步頻率每秒同步一次,Redis最多也就丟失
1秒的數據.
缺點:
1.對於具有相同數據的Redis, AOF文件通常比RDF文件體積更大(RDB存的是數據快照)
2.雖然AOF提供了多種同步的頻率,默認的情況下,沒秒同步一次的頻率也具有較高的性能.在高並發的情況下,RDB比AOF具有更好的性能.
如果可以忍一小段時間數據的丟失,毫無疑問使用RDB 是最好的,定時生成RDB快照非常便於進行數據備份,而且RDB恢復數據集的速度也要比AOF恢復速度要快.
否則就要使用AOF重寫.但是一般情況下建議不要單獨使用某一種持久化機制,而是兩種一起用.
本文內容來自咕泡學院-青山老師,感謝青山老師!!
⑥ Redis是什麼緩存機制
redis(RemoteDictionaryServer)遠程數據服務
內存高速緩存資料庫。C語言編寫，數據模型為key-value，NoSql資料庫。
希望對你有所啟發。apeit-程序猿IT中redis章節講的不錯，由淺入深，適合入門學習。
⑦ redis 緩存是內存緩存嗎
只支持簡單的key/value數據結構，不像Redis可以支持豐富的數據類型。
無法進行持久化，數據不能備份，只能用於緩存使用，且重啟後數據全部丟失。
無法進行數據同步，不能將MC中的數據遷移到其他MC實例中。
Memcached內存分配採用Slab Allocation機制管理內存，value大小分布差異較大時會造成內存利用率降低，並引發低利用率時依然出現踢出等問題。需要用戶注重value設計。
⑧ web伺服器怎麼使用redis分步式緩存
Redis復制流程概述
Redis的復制功能是完全建立在之前我們討論過的基於內存快照的持久化策略基礎上的，也就是說無論你的持久化策略選擇的是什麼，只要用到了Redis的復制功能，就一定會有內存快照發生，那麼首先要注意你的系統內存容量規劃，原因可以參考我上一篇文章中提到的Redis磁碟IO問題。
Redis復制流程在Slave和Master端各自是一套狀態機流轉，涉及的狀態信息是：
Slave 端：
REDIS_REPL_NONEREDIS_REPL_CONNECTREDIS_REPL_CONNECTED
Master端：
REDIS_REPL_WAIT_BGSAVE_STARTREDIS_REPL_WAIT_BGSAVE_ENDREDIS_REPL_SEND_BULKREDIS_REPL_ONLINE
整個狀態機流程過程如下：
Slave端在配置文件中添加了slave of指令，於是Slave啟動時讀取配置文件，初始狀態為REDIS_REPL_CONNECT。
Slave端在定時任務serverCron(Redis內部的定時器觸發事件)中連接Master，發送sync命令，然後阻塞等待master發送回其內存快照文件(最新版的Redis已經不需要讓Slave阻塞)。
Master端收到sync命令簡單判斷是否有正在進行的內存快照子進程，沒有則立即開始內存快照，有則等待其結束，當快照完成後會將該文件發送給Slave端。
Slave端接收Master發來的內存快照文件，保存到本地，待接收完成後，清空內存表，重新讀取Master發來的內存快照文件，重建整個內存表數據結構，並最終狀態置位為 REDIS_REPL_CONNECTED狀態，Slave狀態機流轉完成。
Master端在發送快照文件過程中，接收的任何會改變數據集的命令都會暫時先保存在Slave網路連接的發送緩存隊列里（list數據結構），待快照完成後，依次發給Slave,之後收到的命令相同處理，並將狀態置位為 REDIS_REPL_ONLINE。
整個復制過程完成，流程如下圖所示：
Redis復制機制的缺陷
從上面的流程可以看出，Slave從庫在連接Master主庫時，Master會進行內存快照，然後把整個快照文件發給Slave，也就是沒有象MySQL那樣有復制位置的概念，即無增量復制，這會給整個集群搭建帶來非常多的問題。
比如一台線上正在運行的Master主庫配置了一台從庫進行簡單讀寫分離，這時Slave由於網路或者其它原因與Master斷開了連接，那麼當Slave進行重新連接時，需要重新獲取整個Master的內存快照，Slave所有數據跟著全部清除，然後重新建立整個內存表，一方面Slave恢復的時間會非常慢，另一方面也會給主庫帶來壓力。
所以基於上述原因，如果你的Redis集群需要主從復制，那麼最好事先配置好所有的從庫，避免中途再去增加從庫。
Cache還是Storage
在我們分析過了Redis的復制與持久化功能後，我們不難得出一個結論，實際上Redis目前發布的版本還都是一個單機版的思路，主要的問題集中在，持久化方式不夠成熟，復制機制存在比較大的缺陷，這時我們又開始重新思考Redis的定位：Cache還是Storage？
如果作為Cache的話，似乎除了有些非常特殊的業務場景，必須要使用Redis的某種數據結構之外，我們使用Memcached可能更合適，畢竟Memcached無論客戶端包和伺服器本身更久經考驗。
如果是作為存儲Storage的話，我們面臨的最大的問題是無論是持久化還是復制都沒有辦法解決Redis單點問題，即一台Redis掛掉了，沒有太好的辦法能夠快速的恢復，通常幾十G的持久化數據，Redis重啟載入需要幾個小時的時間，而復制又有缺陷，如何解決呢？
Redis可擴展集群搭建1. 主動復制避開Redis復制缺陷。
既然Redis的復制功能有缺陷，那麼我們不妨放棄Redis本身提供的復制功能，我們可以採用主動復制的方式來搭建我們的集群環境。
所謂主動復制是指由業務端或者通過代理中間件對Redis存儲的數據進行雙寫或多寫，通過數據的多份存儲來達到與復制相同的目的，主動復制不僅限於用在Redis集群上，目前很多公司採用主動復制的技術來解決MySQL主從之間復制的延遲問題，比如Twitter還專門開發了用於復制和分區的中間件gizzard(https://github.com/twitter/gizzard) 。
主動復制雖然解決了被動復制的延遲問題，但也帶來了新的問題，就是數據的一致性問題，數據寫2次或多次，如何保證多份數據的一致性呢？如果你的應用對數據一致性要求不高，允許最終一致性的話，那麼通常簡單的解決方案是可以通過時間戳或者vector clock等方式，讓客戶端同時取到多份數據並進行校驗，如果你的應用對數據一致性要求非常高，那麼就需要引入一些復雜的一致性演算法比如Paxos來保證數據的一致性，但是寫入性能也會相應下降很多。
通過主動復制，數據多份存儲我們也就不再擔心Redis單點故障的問題了，如果一組Redis集群掛掉，我們可以讓業務快速切換到另一組Redis上，降低業務風險。
2. 通過presharding進行Redis在線擴容。
通過主動復制我們解決了Redis單點故障問題，那麼還有一個重要的問題需要解決：容量規劃與在線擴容問題。
我們前面分析過Redis的適用場景是全部數據存儲在內存中，而內存容量有限，那麼首先需要根據業務數據量進行初步的容量規劃，比如你的業務數據需要100G存儲空間，假設伺服器內存是48G，那麼根據上一篇我們討論的Redis磁碟IO的問題，我們大約需要3~4台伺服器來存儲。這個實際是對現有業務情況所做的一個容量規劃，假如業務增長很快，很快就會發現當前的容量已經不夠了，Redis裡面存儲的數據很快就會超過物理內存大小，那麼如何進行Redis的在線擴容呢？
Redis的作者提出了一種叫做presharding的方案來解決動態擴容和數據分區的問題，實際就是在同一台機器上部署多個Redis實例的方式，當容量不夠時將多個實例拆分到不同的機器上，這樣實際就達到了擴容的效果。
拆分過程如下：
在新機器上啟動好對應埠的Redis實例。
配置新埠為待遷移埠的從庫。
待復制完成，與主庫完成同步後，切換所有客戶端配置到新的從庫的埠。
配置從庫為新的主庫。
移除老的埠實例。
重復上述過程遷移好所有的埠到指定伺服器上。
以上拆分流程是Redis作者提出的一個平滑遷移的過程，不過該拆分方法還是很依賴Redis本身的復制功能的，如果主庫快照數據文件過大，這個復制的過程也會很久，同時會給主庫帶來壓力。所以做這個拆分的過程最好選擇為業務訪問低峰時段進行。
Redis復制的改進思路
我們線上的系統使用了我們自己改進版的Redis,主要解決了Redis沒有增量復制的缺陷，能夠完成類似Mysql Binlog那樣可以通過從庫請求日誌位置進行增量復制。
我們的持久化方案是首先寫Redis的AOF文件，並對這個AOF文件按文件大小進行自動分割滾動，同時關閉Redis的Rewrite命令，然後會在業務低峰時間進行內存快照存儲，並把當前的AOF文件位置一起寫入到快照文件中，這樣我們可以使快照文件與AOF文件的位置保持一致性，這樣我們得到了系統某一時刻的內存快照，並且同時也能知道這一時刻對應的AOF文件的位置，那麼當從庫發送同步命令時，我們首先會把快照文件發送給從庫，然後從庫會取出該快照文件中存儲的AOF文件位置，並將該位置發給主庫，主庫會隨後發送該位置之後的所有命令，以後的復制就都是這個位置之後的增量信息了。
Redis與MySQL的結合
目前大部分互聯網公司使用MySQL作為數據的主要持久化存儲，那麼如何讓Redis與MySQL很好的結合在一起呢？我們主要使用了一種基於MySQL作為主庫，Redis作為高速數據查詢從庫的異構讀寫分離的方案。
為此我們專門開發了自己的MySQL復制工具，可以方便的實時同步MySQL中的數據到Redis上。
（MySQL-Redis 異構讀寫分離）
總結：
Redis的復制功能沒有增量復制，每次重連都會把主庫整個內存快照發給從庫，所以需要避免向在線服務的壓力較大的主庫上增加從庫。
Redis的復制由於會使用快照持久化方式，所以如果你的Redis持久化方式選擇的是日誌追加方式(aof),那麼系統有可能在同一時刻既做aof日誌文件的同步刷寫磁碟，又做快照寫磁碟操作，這個時候Redis的響應能力會受到影響。所以如果選用aof持久化，則加從庫需要更加謹慎。
可以使用主動復制和presharding方法進行Redis集群搭建與在線擴容。
⑨ redis 緩存是內存緩存嗎
redis是類似key_value形式的快速緩存服務。類型較豐富，可以保存對象、列表等，支持的操作也很豐富，屬於內存資料庫，且可以把內存中的數據及時或定時的寫入到磁碟。可設置過期自動刪除，速度快，易於使用。