The new system has just published front-end feedback redis in value is often the case, the first reaction of the code inside the suspect who carried out the operation flushall or flushdb
By tracking a wave of monitor redis,
redis-cli -a "xxx" Monitor if redis not configure a password can not add -a parameter, the actual operation I added >> /data/log/trace_redis.log, all operations write to a file inside,
Ran down redis does is cleared, but no one / procedures performed flush operation, stop thinking of life here under five minutes
Fortunately here before turned a zabbix monitoring, surveillance has redis use of memory, and found 
redis number briefly soared to 10G, then immediately fell, this time you can do with a basic memory should determine, after reaching a certain threshold data is cleared up .
Redis look through the official website detailed record: https://redis.io/topics/lru-cache
document check down there really is because reids memory limitations, we are here 10G, and have a clear strategy by default after the super-memory is all clear. . .
Open /etc/redis.conf (actual path may vary)
It is here, maxmemory how to set clear after redis maximum use of memory, maxmemory-policy decisions over
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动态修改Of course, this is the policy on redis, the actual track found the above phenomenon programs has been to push data redis which caused problems to solve