麻豆小视频在线观看_中文黄色一级片_久久久成人精品_成片免费观看视频大全_午夜精品久久久久久久99热浪潮_成人一区二区三区四区

首頁 > 數據庫 > Redis > 正文

淺談redis的maxmemory設置以及淘汰策略

2020-03-17 12:38:39
字體:
來源:轉載
供稿:網友

redis的maxmemory參數用于控制redis可使用的最大內存容量。如果超過maxmemory的值,就會動用淘汰策略來處理expaire字典中的鍵。

關于redis的淘汰策略:

Redis提供了下面幾種淘汰策略供用戶選擇,其中默認的策略為noeviction策略:

·   noeviction:當內存使用達到閾值的時候,所有引起申請內存的命令會報錯。

·   allkeys-lru:在主鍵空間中,優先移除最近未使用的key。

·   volatile-lru:在設置了過期時間的鍵空間中,優先移除最近未使用的key。

·   allkeys-random:在主鍵空間中,隨機移除某個key。

·   volatile-random:在設置了過期時間的鍵空間中,隨機移除某個key。

·   volatile-ttl:在設置了過期時間的鍵空間中,具有更早過期時間的key優先移除。

PS:

redis,淘汰策略,maxmemory

關于maxmemory的設置,如果redis的應用場景是作為db使用,那不要設置這個選項,因為db是不能容忍丟失數據的。

如果作為cache使用,則可以啟用這個選項(其實既然有淘汰策略,那就是cache了。。。)

但是在集群環境下(尤其是有多個slavers的情形),maxmeomory的值并不是實際redis使用的內存,這個選項值并沒有包括slaver的output buffer。

redis早期版本出過一個bug,在多個slaver的情形下,設置了maxmemory值,同時設定了淘汰策略,會造成master上的數據被漸漸擦除。

antirez先生給出了這個問題的原因:

The issue happens for the following reason: Redis reached the configured limit, so it tries to expire keys.Evicting keys turns into explicit DELs sent to slaves, since masters control the eviction of slaves for well known reasons.But this way if there are enough slaves, emitting the protocol in the output buffers will actually take more memory than the amount freed removing keys...So the key eviction process starts to enter into an infinite loop.Up to a given point the fact that there is a static buffer part in the output queue of every client (including slaves) mitigate this in certain conditions, but once Redis can't use the output buffer but must use the queue of objects the infinite loop is triggered. 

簡單說來,刪除過期鍵,需要產生del命令發送給slaver,如果slaver足夠多,output buffer將會占用足夠多的內存,導致更多的鍵過期,如此往復,陷入了無線循環。

解決方案有多種,比如output buffer可以不計入maxmemory。

因此,在3.0版本的配置說明中有了以下表述:

# WARNING: If you have slaves attached to an instance with maxmemory on,# the size of the output buffers needed to feed the slaves are subtracted# from the used memory count, so that network problems / resyncs will# not trigger a loop where keys are evicted, and in turn the output# buffer of slaves is full with DELs of keys evicted triggering the deletion# of more keys, and so forth until the database is completely emptied.## In short... if you have slaves attached it is suggested that you set a lower# limit for maxmemory so that there is some free RAM on the system for slave# output buffers (but this is not needed if the policy is 'noeviction').## maxmemory <bytes></bytes> 

由此可見,如果有slaver的情況下,建議適當調低maxmemory,給output buffer留出一定的可用空間是合理的。

以上這篇淺談redis的maxmemory設置以及淘汰策略就是小編分享給大家的全部內容了,希望能給大家一個參考,也希望大家多多支持VEVB武林網。


注:相關教程知識閱讀請移步到Redis頻道。
發表評論 共有條評論
用戶名: 密碼:
驗證碼: 匿名發表
主站蜘蛛池模板: 99亚洲伊人久久精品影院红桃 | 91久久极品少妇韩国 | 91久久久久久久久久久久久久 | 国产日产精品一区四区介绍 | 久久久久久久久久久久久国产精品 | 婷婷久久影院 | 国产91丝袜在线播放 | xnxx18日本| 国产精品久久久久久久久久 | 久久精品视频在线 | 第一区免费在线观看 | 欧美精品欧美 | 午夜在线视频一区二区三区 | 国产亚洲在| 国产精品一区二区羞羞答答 | a黄色片 | 日韩欧美高清片 | 国产精品高潮视频 | 久草在线视频看看 | 撅高 自己扒开 调教 | 欧美一级特黄a | 免费a级毛片大学生免费观看 | 中文字幕四区 | 九九热精 | 日本在线观看视频网站 | 成年人黄视频 | 欧美一区二区三区久久精品视 | 中文字幕www. | 国产精品久久久久久久久久iiiii | xxxx69hd一hd| 亚洲网站免费观看 | 一级成人免费 | 国产免费观看一区二区三区 | 久久精品国产精品亚洲 | 免费在线观看国产精品 | 亚洲精品久久久久久下一站 | 亚洲一区二区三区在线免费观看 | 91色爱 | 国产精品成人av片免费看最爱 | 狠狠久久伊人中文字幕 | 欧美成人精品一区二区 |