Redis 占用內(nèi)存的大小
使用 redis-cli 登錄到 Redis Server，執(zhí)行 info 命令, 其中 '# Memory' 段落部分就是 Redis 內(nèi)存的使用情況，例如：
# Memory
used_memory:3848224 //數(shù)據(jù)占用了多少內(nèi)存（字節(jié)）
used_memory_human:3.67M //數(shù)據(jù)占用了多少內(nèi)存（帶單位的，可讀性好）
used_memory_rss:10149888 //redis占用了多少內(nèi)存
used_memory_rss_human:9.68M
used_memory_peak:24336080 //占用內(nèi)存的峰值（字節(jié)）
used_memory_peak_human:23.21M
used_memory_peak_perc:15.81%
used_memory_overhead:2955778
used_memory_startup:512480
used_memory_dataset:892446
used_memory_dataset_perc:26.75%
allocator_allocated:3922952
allocator_active:8519680
allocator_resident:11620352
total_system_memory:16655781888
total_system_memory_human:15.51G
used_memory_lua:37888
used_memory_lua_human:37.00K
used_memory_scripts:0
used_memory_scripts_human:0B
number_of_cached_scripts:0
maxmemory:8589934592
maxmemory_human:8.00G
maxmemory_policy:noeviction
allocator_frag_ratio:2.17
allocator_frag_bytes:4596728
allocator_rss_ratio:1.36
allocator_rss_bytes:3100672
rss_overhead_ratio:0.87
rss_overhead_bytes:18446744073708081152
mem_fragmentation_ratio:2.67
mem_fragmentation_bytes:6343656
mem_not_counted_for_evict:3780
mem_replication_backlog:0
mem_clients_slaves:0
mem_clients_normal:117342
mem_aof_buffer:3780
mem_allocator:jemalloc-5.1.0
active_defrag_running:0
lazyfree_pending_objects:0
Redis 最大占用內(nèi)存的大小
這個在配置文件中:
############################## MEMORY MANAGEMENT ################################
# Set a memory usage limit to the specified amount of bytes.
# When the memory limit is reached Redis will try to remove keys
# according to the eviction policy selected (see maxmemory-policy).
#
# If Redis can't remove keys according to the policy, or if the policy is
# set to 'noeviction', Redis will start to reply with errors to commands
# that would use more memory, like SET, LPUSH, and so on, and will continue
# to reply to read-only commands like GET.
#
# This option is usually useful when using Redis as an LRU or LFU cache, or to
# set a hard memory limit for an instance (using the 'noeviction' policy).
#
# WARNING: If you have replicas attached to an instance with maxmemory on,
# the size of the output buffers needed to feed the replicas 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 replicas 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 replicas attached it is suggested that you set a lower
# limit for maxmemory so that there is some free RAM on the system for replica
# output buffers (but this is not needed if the policy is 'noeviction').
#
# maxmemory <bytes>
maxmemory 8589934592
Redis 支持運(yùn)行時通過命令動態(tài)修改內(nèi)存大小
127.0.0.1:6379> config get maxmemory
1) "maxmemory"
2) "8589934592"
127.0.0.1:6379> config set maxmemory 1024m
OK
127.0.0.1:6379> config get maxmemory
1) "maxmemory"
2) "1024000000"
127.0.0.1:6379>
如果不設(shè)置最大內(nèi)存大小或者設(shè)置最大內(nèi)存大小為 0，在 64 位操作系統(tǒng)下不限制內(nèi)存大小，在 32 位操作系統(tǒng)下最多使用 3GB 內(nèi)存。
Redis 的內(nèi)存淘汰策略
既然可以設(shè)置 Redis 最大占用內(nèi)存大小，那么配置的內(nèi)存就有用完的時候。那在內(nèi)存用完的時候，還繼續(xù)往 Redis 里面添加數(shù)據(jù)不就沒內(nèi)存可用了嗎？
實(shí)際上 Redis 定義了幾種策略用來處理這種情況：
- noeviction(默認(rèn)策略)：對于寫請求不再提供服務(wù)，直接返回錯誤（DEL請求和部分特殊請求除外）
- allkeys-lru：從所有key中使用LRU算法進(jìn)行淘汰
- allkeys-random：從所有key中隨機(jī)淘汰數(shù)據(jù)
- volatile-lru：從設(shè)置了過期時間的key中使用LRU算法進(jìn)行淘汰
- volatile-random：從設(shè)置了過期時間的key中隨機(jī)淘汰
- volatile-ttl：在設(shè)置了過期時間的key中，根據(jù)key的過期時間進(jìn)行淘汰，越早過期的越優(yōu)先被淘汰
當(dāng)使用 volatile-lru、volatile-random、volatile-ttl 這三種策略時，如果沒有 key 可以被淘汰，則和 noeviction 一樣返回錯誤。
查看和設(shè)置 Redis 的內(nèi)存淘汰策略
一種是寫在配置文件中，redis.conf :
maxmemory-policy allkeys-lru
另一種是使用命令
127.0.0.1:6379> config get maxmemory-policy
1) "maxmemory-policy"
2) "noeviction"
127.0.0.1:6379> config set maxmemory-policy volatile-lru
OK
127.0.0.1:6379> config get maxmemory-policy
1) "maxmemory-policy"
2) "volatile-lru"
127.0.0.1:6379>
算法
LRU算法
上面說到了Redis可使用最大內(nèi)存使用完了，是可以使用LRU算法進(jìn)行內(nèi)存淘汰的，那么什么是LRU算法呢？
LRU(Least Recently Used)，即最近最少使用，是一種緩存置換算法。在使用內(nèi)存作為緩存的時候，緩存的大小一般是固定的。當(dāng)緩存被占滿，這個時候繼續(xù)往緩存里面添加數(shù)據(jù)，就需要淘汰一部分老的數(shù)據(jù)，釋放內(nèi)存空間用來存儲新的數(shù)據(jù)。這個時候就可以使用LRU算法了。其核心思想是：如果一個數(shù)據(jù)在最近一段時間沒有被用到，那么將來被使用到的可能性也很小，所以就可以被淘汰掉。
LRU 在 Redis 中的實(shí)現(xiàn)
近似LRU算法
Redis使用的是近似LRU算法，它跟常規(guī)的LRU算法還不太一樣。近似LRU算法通過隨機(jī)采樣法淘汰數(shù)據(jù)，每次隨機(jī)出5（默認(rèn)）個key，從里面淘汰掉最近最少使用的key。
可以通過maxmemory-samples參數(shù)修改采樣數(shù)量：例：maxmemory-samples 10 maxmenory-samples配置的越大，淘汰的結(jié)果越接近于嚴(yán)格的LRU算法
Redis為了實(shí)現(xiàn)近似LRU算法，給每個key增加了一個額外增加了一個24bit的字段，用來存儲該key最后一次被訪問的時間。
Redis3.0對近似LRU的優(yōu)化
Redis3.0對近似LRU算法進(jìn)行了一些優(yōu)化。新算法會維護(hù)一個候選池（大小為16），池中的數(shù)據(jù)根據(jù)訪問時間進(jìn)行排序，第一次隨機(jī)選取的key都會放入池中，隨后每次隨機(jī)選取的key只有在訪問時間小于池中最小的時間才會放入池中，直到候選池被放滿。當(dāng)放滿后，如果有新的key需要放入，則將池中最后訪問時間最大（最近被訪問）的移除。
當(dāng)需要淘汰的時候，則直接從池中選取最近訪問時間最?。ㄗ罹脹]被訪問）的key淘汰掉就行。
LFU算法
LFU 算法是Redis4.0里面新加的一種淘汰策略。它的全稱是Least Frequently Used，它的核心思想是根據(jù)key的最近被訪問的頻率進(jìn)行淘汰，很少被訪問的優(yōu)先被淘汰，被訪問的多的則被留下來。
LFU算法能更好的表示一個key被訪問的熱度。假如你使用的是LRU算法，一個key很久沒有被訪問到，只剛剛是偶爾被訪問了一次，那么它就被認(rèn)為是熱點(diǎn)數(shù)據(jù)，不會被淘汰，而有些key將來是很有可能被訪問到的則被淘汰了。如果使用LFU算法則不會出現(xiàn)這種情況，因?yàn)槭褂靡淮尾⒉粫挂粋€key成為熱點(diǎn)數(shù)據(jù)。
LFU一共有兩種策略：
- volatile-lfu：在設(shè)置了過期時間的key中使用LFU算法淘汰key
- allkeys-lfu：在所有的key中使用LFU算法淘汰數(shù)據(jù)
設(shè)置使用這兩種淘汰策略跟前面講的一樣，不過要注意的一點(diǎn)是這兩周策略只能在Redis4.0及以上設(shè)置，如果在Redis4.0以下設(shè)置會報錯。
