目录
之前这本书看了大概二分之一，后面就没有再坚持下去，这次在我球管理redis-manager的机会，重新捡起这本书，深度的阅读，以防止自己记忆碎片，整理文档。Redis开发与运维这本书的内容太多，网上没有找到检索，记录下来自己认为重要的信息片段，供检所使用。
集群运维
集群完整性：
默认当16384中任何一个槽没有指派时集群不可用
持有槽的主节点下线时，从故障发现到自动切换转移，整个集群状态为不可用，大多数场景无法接受将cluster-require-full-coverage设置为no
带宽消耗：
消息发送频率：cluster-node-timeout/2
消息数据量：slots槽数组（2kb）+1/10集群的状态数据
节点部署规模：部署的节点要划分均匀
Pub/Sub广播问题：
集群模式下的public广播问题，频繁的应用Pub/Sub避免在大量节点的集群使用，建议使用sentinel结构专门用于Pub/Sub
集群倾斜
数据倾斜：
节点和槽不均匀 使用redis-trib.rb rebalance
不同槽对应键数据量差异过大 大量使用hash_tag导致，
使用cluster countkeysinslot {slot}获取槽对应键的数量发现最多建的槽，
再通过cluster getkeysinslot {slot} {count}迭代出所有键找出过度使用的hash_tag
集合对象包含大量元素 使用redis-cli --bigkey识别，找出后根据业务场景拆分（过大会造成migrate失败）
内存相关配置不一致 例如hash-max-ziplist-value、set-max-intset-entitres等压缩数据结构配置
请求倾斜：
热点key的场景，简单的getset不会造成负载不均匀，一般是hgetall、smembers等搞复杂度算法命令
1.大集合键拆分，hmget代替hgetall
2.不使用热key做hash_tag
3.一致性要求不高的，客户端使用本地缓存减少热键调用
集群读写分离
只读连接：
集群模式下从节点不接受任何读写请求，被转发到对应的master上
分担读压力，使用readonly打开只读状态
只读流程：如果槽属于正在复制的主节点，直接执行命令，负责重定向
readonly命令时连接级别，每次新建命令都要
读写分离：
复制延迟，读取过期数据，从节点故障
集群提供cluster slave {nodeId}获取从节点
不提倡使用
手动故障转移
从节点执行cluster failover执行切换流程
应用于：
主节点迁移（新旧机器迁移）
强制故障转移（主从节点同时故障）
从节点与主节点复制断线时间超过cluster-slave-validity-factor*cluster-node-timeout+repl-ping-slave-period
网络不稳定，无法在cluster-node-timeout*2时间内完成发现转移
集群超过一半以上主节点同时故障
cluster failover提供
force：不再请求master的偏移量，直接替换并广播
takeover：用于超一半主节点故障，会导致配置纪元冲突，会采用配置纪元大的（纪元冲突采用nodeId大的）
数据迁移
和雪球当前方案一样redis-migrate-tool
缓存更新策略
1.LRU/LFU/FIFO
maxmemory-policy缓存使用量超过预设最大值
一致性最差，由算法决定
2.超时剔除
给缓存数据添加过期时间
一致性由expire决定
3.主动更新
利用消息系统或者其他方式通知更新缓存
一致性最高，搭配expire更好
4.最佳实践
低一致性配置最大内存和淘汰策略
高一致性超时剔除+主动更新
缓存粒度：
穿透优化
业务代码或者数据问题，恶意攻击、爬虫导致
1.缓存空值
优点：保护后端数据源 数据压力
缺点：意味着更多的空间（如果是攻击，问题就严重了）、缓存和存储有一个时间窗口不一致
2.布隆过滤器拦截
在访问缓存和存储前，将存在的key用布隆过滤器提前保存起来做第一层拦截
https://github.com/erikdubbelboer/redis-lua-scaling-bloom-filter
无底洞优化
增加节点，性能不增加反而降低
命令优化，例如优化SQL语句
减少网络通信次数
降低接入成本（长连接、连接池、NIO）
雪崩优化
1.保证缓存层服务的高可用性
2.依赖隔离组件为后端限流并降级https://github.com/netflix/hystrix
3.故障演练，上线前就关闭缓存压测一下
热点key优化
问题：
热点key（例如热门的新闻事件）并发量贼大
重建缓存不能短时间内完成（复杂计算，sql、io、多依赖等）
在缓存失效期间大量线程重建缓存造成后端压力骤增
解决：
减少重建次数、数据尽可能一致、较少的潜在危险
互斥锁：等上一个把缓存整出来、先看看有没有
永不过期：缓存方面、功能方面（逻辑过期时间）
Linux配置优化
1.vm.overcommit_memory
设置为1(cat /proc/sys/vm/overcommit_memory)，不然log会有提示
最佳实践
Redis合理设置maxmemory保证机器有20%~30%的空闲
集中化管理AOF和RDB的bgsave
设置vm.overcommit_memory=1，防止极端情况下fork失败
2.swappiness
百分比会决定操作系统使用swap的倾向程度，越大倾向越高（默认60，cat /proc/sys/vm/swappiness）
free -m、vmstat 1、cat /proc/{pid}/smaps |grep Swap
Linux>3.5 vm.swapniess=1 : vm.swapniess=0
3.THP
Linux2.6.38之后默认开启，内存页从4KB变为2MB，建议禁用（echo never > /sys/kernel/mm/transparent_hugepage/enabled）
4.OOM killer
会在可用内存不足时杀掉用户进程，根据每个进程的权值（越高越被杀，cat /proc/{pid}/oom_score）
这个值受(cat /proc/{pid}/oom_adj)控制，当oom_adj为最小值时该进程不会被杀掉
5.NTP
网络时间协议，保证不同机器时钟一致性
6.ulimit
查看和设置当前用户进程的资源数，open files是单个用户打开的最大文件个数
maxclient+32是redis的进程数（ulimit -Sn {max-open-files}）
7.TCP backlog
在linux系统内核中维护了两个队列：syns queue和accept queue，https://www.jianshu.com/p/e6f2036621f4
redis默认值511（cat /proc/sys/net/core/somaxconn）
这个值不能小于redis的默认值，这个是Linux半连接请求（syns queue）
flushall/flushdb误操作
被误flush后，根据缓存还是存储策略不同
缓存：就是个简单的缓存穿透
存储：影响巨大
AOF：
auto-aof-rewrite-percentage、auto-aof-rewrite-min-size看看aof是不是重写了（调大这个参数），拒绝手动bgrewriteaof
删除掉flush这个命令，用redis-check-aof修复AOF文件
RDB：
save {time} {times}配置文件，防止手动bgsave
flush涉及的key较多，RDB会被清除，取决于RDB是什么时候备份的
最佳实践：
使用shell脚本
安全的redis
伪装危险命令：keys、flushall/flushdb、save、debug、config、shutdown
AOF和RDB不要，不然redis无法重启
主从节点要配置一致
使用防火墙限制ip port只开放80
bind绑定的是网卡，可以设置多个
定期备份数据
不使用默认端口
不使用root作为管理员
处理bigkey
字符串一般超过10kb都是大key了，和ops相关
集合类型一般是元素个数过多
危害：
内存空间不均匀
超时阻塞
网络拥塞
处理：
redis-cli --bigkeys统计（debug object key可以查看key的字节数）
被动收集：抛异常时打印所有的key
主动检测：scan+debug object（推荐，键过多可以使用pipeline，从节点上执行，避免阻塞）
删除：
string直接del
集合类型先scan，再pipeline逐个del filed
寻找热点key
1.客户端，每次调用redis命令时使用字典记录
缺点：
无法预知keygeshu，存在内存泄漏
对代码侵入，多个语言维护困难
只能了解客户端热点key，无法规模化运维
2.代理端（Twemproxy、Codis）
3.redis服务端
使用monitor命令
Facebook的redis-faina（尽可能在本机执行，存在单点，影响线上性能问题）
4.机器
对TCP抓包，采用ELK体系下的packetbeat插件（也可以对MySQL检测）
处理热点key：
拆分复杂数据结构
迁移热点key，将热点slot单独迁到一个节点上
本地缓存加通知机制（发布订阅解决不一致问题）