最近使用redis作爲kv存一些業務數據，給redis設置了最大使用內存以及數據淘汰規則。
maxmemory 60g
maxmemory-policy allkeys-lru
設置完之後以爲redis進程最多會佔用60g的內存，所以就放心的使用。
但是前幾天收到redis進程退出報警，查看機器內存曲線，發現redis的使用已經達到100g左右的水平，再加上其他進程也佔用了一些內存，整個機器的內存被用盡，導致redis沒有內存可分配異常退出。
通過info memory命令發現，redis的used_memory在60g左右，但是used_memory_rss在100g左右水平，而後者纔是整個redis進程佔用內存，redis的mem_fragmentation_ratio = used_memory_rss/used_memory_rss已經大於1.5，網上查詢資料發現是redis本身的內存碎片化導致。
對比另外一處使用的redis服務，存儲了也有50g左右的數據，使用一年多mem_fragmentation_ratio才1多一點。
通過對兩個業務場景進行分析，發現內存碎片較高的redis每天都有定時任務在往裏面寫入大量數據，這些數據的key和原來的數據有好多不一致，這樣redis本身就會通過lru策略將部分舊數據淘汰，而被淘汰的數據本身佔用的內存卻沒有被redis進程釋放，導致redis內存的有效數據雖然只有60g，但是整個進程的內存在一直增長。而另外一臺內存碎片較低的機器雖然也會定期寫入數據，但是因爲key的重合度很高，沒有大量內存的再分配。
根據現在查詢的資料，沒有太好的解決辦法，只能對機器設置內存監控，超過95%的內存使用率之後重啓redis，回收內存。