http://www.imooc.com/article/3645
http://www.cnblogs.com/mushroom/p/4738170.html
http://linusp.github.io/2015/12/16/redis-performance-analysis.html
https://segmentfault.com/a/1190000002906345

#info 分析

## Memory
>实际缓存占用的内存和Redis自身运行所占用的内存(如元数据、lua)。
>它是由Redis使用内存分配器分配的内存，所以这个数据并没有把内存碎片浪费掉的内存给统计进去
>如果used_memory > 可用最大内存，那么操作系统开始进行内存与swap空间交换
>当 rss > used ，且两者的值相差较大时，表示存在（内部或外部的）内存碎片。
>内存碎片的比率可以通过 mem_fragmentation_ratio 的值看出。
>当 used > rss 时，表示 Redis 的部分内存被操作系统换出到交换空间了，在这种情况下，操作可能会产生明显的延迟

>used_memory:9892187056
>used_memory_human:9.21G

>从操作系统上显示已经分配的内存总量, 包括碎片
>used_memory_rss:11148713984
>used_memory_peak:11236792296
>used_memory_peak_human:10.47G
>used_memory_lua:35840

## 内存碎片率
>内存碎片率稍大于1是合理的，这个值表示内存碎片率比较低，也说明redis没有发生内存交换。
>但如果内存碎片率超过1.5，那就说明Redis消耗了实际需要物理内存的150%，其中50%是内存碎片率
>若是内存碎片率低于1的话，说明Redis内存分配超出了物理内存，操作系统正在进行内存交换。内存交换会引起非常明显的响应延迟
>mem_fragmentation_ratio:1.13
>mem_allocator:jemalloc-3.6.0

## stats
>total_commands_processed:105868 #总共处理的命令数
>instantaneous_ops_per_sec:0
>rejected_connections:0
>evicted_keys:0 #因为maxmemory限制导致key被回收删除的数量

# 性能分析

## 延迟

>redis-cli -h 127.0.0.1 -p 6379 –latency
>持续采样，结果单位是ms;
>redis-cli -h 127.0.0.1 -p 6379 -–latency-history
>间隔采样，结果单位是ms;

## bigkeys

>redis-cli -h 127.0.0.1 -p 6379 –bigkeys
>持续采样，实时输出当时得到的 value 占用空间最大的 key 值

## 慢日志

>默认配置
>slowlog-log-slower-than 10000
>slowlog-max-len 128

>获取慢日志
>slowlog get 3

## 统计

>redis-cli -h 127.0.0.1 -p 6379 info commandstats
>查看所有命令统计的快照，执行次数，所耗费的毫秒数，总时间和平均时间

## 调试

>redis-cli -h 127.0.0.1 -p 6379 monitor

## 内存占用分析

redis-rdb-tools
>pip install rdbtools
>rdb -c memory /var/redis/6379/dump.rdb > memory.csv

# 优化与禁忌

停止使用 KEYS *，如果避免不了，请使用scan命令
精简键名和键值，减小key长度，压缩value
设置 key 值的过期时间，避免长时间占用内存，缓解同步和持久化的压力
选择合适的回收策略，如果不能丢数据则建议使用 volatile-lru 策略，如果key可以自动重建则推荐allkeys-lru
业务层要考虑读写分离和主从模式
合理分配snapshot，aof，主上关闭aof和snapshot，在主从上开启snapshot和aof
如果数据不需要持久，可关闭所有的持久化方式可以获得最佳的性能以及最大的内存使用量
合理选择最优的数据结构解决实际问题，那样既可以提高效率又可以节省内存
合理使用长连接
maxmemory=8g, 不要让你的Redis所在机器物理内存使用超过实际内存总量的3/5
sysctl vm.overcommit_memory=1
关闭vm-enabled，3.0以后默认废弃

解决保存快照失败后redis无法写入的问题
>config set stop-writes-on-bgsave-error no

定期日志重写，减小aof重载时的时间开销
>auto-aof-rewrite-percentage 100
>auto-aof-rewrite-min-size 64mb

# 安全
使用普通用户启动服务，且禁止该用户登录
在可以保证内网安全的情况下，无密码性能最好
客户端可能会发送config命令，会有安全问题，建议禁用
客户端可能会发送flushall、flushdb命令，为避免误操作，建议禁用
客户端可能会发送save命令，会严重影响服务器的性能，建议禁用并使用bgsave替代

>rename-command FLUSHALL “”
rename-command FLUSHDB “”
rename-command KEYS “”
rename-command save “”

# 备份策略
主关闭aof, 开启rdb
每十分钟/10000变更生成一次rdb
每个小时保存一次最新的rdb到当前磁盘
每个小时保存一次

选择一台从节点，开启rdb，开启aof，并定期重载日志
“`shell
path=/opt/data/redis/
name=dump_6380.rdb
file=$(date -d “yesterday” +”%Y%m%d%H.rdb”)
/bin/mv $path/$name $path/$file
echo “move file $path/$file”

file=$(date -d “-3 days” +”%Y%m%d%H.rdb”)
/bin/rm -f $path/$file
“`