新版系統剛發佈前端反饋redis中的值經常被情況，第一反應懷疑誰的代碼裏面執行了flushall或者flushdb操作
通過redis的monitor追蹤一波，
redis-cli -a "xxx" monitor 如果redis沒配置密碼可以不用加-a參數，實際操作中我加了個 >> /data/log/trace_redis.log，把所有操作寫到文件裏面，
跑下來redis確實會被清掉，但沒人/程序執行過flush操作，這裏停頓5分鐘思考下人生
這裏幸虧之前轉過一個zabbix監控，有監控redis的使用內存，結果發現
redis會短時間飆到10G,然後馬上掉下來，這時候基本可以判定應該跟內存有關，達到某個閾值之後數據被清了。
去翻redis官網有詳細記錄：https://redis.io/topics/lru-cache
文檔查下來確實是因爲reids有內存限制，我們這裏是10G,並且有超內存之後的清除策略默認是全清。。。
翻開 /etc/redis.conf (實際路徑可能不同）
就這裏了，maxmemory設置redis最大使用內存，maxmemory-policy決定超過之後怎麼清
Redis提供6種數據淘汰策略：
1. volatile-lru:從已設置過期時間的內存數據集中挑選最近最少使用的數據 淘汰；
2. volatile-ttl: 從已設置過期時間的內存數據集中挑選即將過期的數據 淘汰；
3. volatile-random:從已設置過期時間的內存數據集中任意挑選數據 淘汰；
4. allkeys-lru:從內存數據集中挑選最近最少使用的數據 淘汰；
5. allkeys-random:從數據集中任意挑選數據 淘汰；
6. no-enviction(驅逐)：禁止驅逐數據。（默認淘汰策略。當redis內存數據達到maxmemory，在該策略下，直接返回OOM錯誤）；
關於maxmemory設置，通過在redis.conf中maxmemory參數設置，或者通過命令CONFIG SET動態修改
關於數據淘汰策略的設置，通過在redis.conf中的maxmemory-policy參數設置，或者通過命令CONFIG SET動態修改當然這是redis上的策略，實際追蹤發現有個程序一直往redis裏面push數據導致的上面的現象，問題解決