常见问题
缓存击穿（单个热点key失效）
互斥锁
热点数据永不失效
缓存雪崩（大量key同时失效）
加随机值
集群部署
双写一致性
问题：先更新db还是先更新缓存？是删除缓存还是更新缓存？
延时双删
广告项目可用缓存的地方
主数据：项目，楼层，楼栋，商铺
资源位信息：一个项目的资源位设置完成后，应该很少改动
广告位信息：资源位设置广告位后，半年才允许变更一次
各种审批列表：审批信息一旦结束，则不会再变回
广告位排期：按照广告位缓存。一旦计划创建完成后，很长一段时间，不会再针对这个广告位创建新计划
设备列表：新增后基本不变
计划列表和素材列表，考虑变更性比其他列表大，可以不用缓存。
高可用
持久化
rdb
# save 3600 1<br># save 300 100<br># save 60 10000
fork()，生成一个dump.rdb文件<br>可以指定save时间设置。<br>占用空间小。适合容灾备份。<br>恢复时加载速度比 AOF快<br>缺点：<br>1：可能丢的数据时间较长<br>2：数据集大是，fork可能很耗时
aof
1：丢失数据少<br>2：文件过大时，可通过配置或者手动rewrite重写。<br>3：数据出错时，可通过redis-check-aof修复
appendonly no<br>appendfilename "appendonly.aof"<br># appendfsync always<br>appendfsync everysec<br># appendfsync no<br>
混合模式
主从
特点：<br>* 主数据库可以进行读写操作，当读写操作导致数据变化时会自动将数据同步给从数据库<br><br>* 从数据库一般都是只读的，并且接收主数据库同步过来的数据<br><br>* 一个master可以拥有多个slave，但是一个slave只能对应一个master<br><br>* slave挂了不影响其他slave的读和master的读和写，重新启动后会将数据从master同步过来<br><br>* master挂了以后，不影响slave的读，但redis不再提供写服务，master重启后redis将重新对外提供写服务<br><br>* master挂了以后，不会在slave节点中重新选一个master
常用命令：<br>slaveof 192.168.1.1 6379 （高版本replicaof）<br>slave-read-only<br>info replication<br>
存在问题：一旦主节点挂掉，则不能提供写服务
哨兵（sentinel）
特点
* sentinel模式是建立在主从模式的基础上，如果只有一个Redis节点，sentinel就没有任何意义<br><br>* 当master挂了以后，sentinel会在slave中选择一个做为master，并修改它们的配置文件，其他slave的配置文件也会被修改，比如slaveof属性会指向新的master<br><br>* 当master重新启动后，它将不再是master而是做为slave接收新的master的同步数据<br><br>* sentinel因为也是一个进程有挂掉的可能，所以sentinel也会启动多个形成一个sentinel集群<br><br>* 多sentinel配置的时候，sentinel之间也会自动监控<br><br>* 当主从模式配置密码时，sentinel也会同步将配置信息修改到配置文件中，不需要担心<br><br>* 一个sentinel或sentinel集群可以管理多个主从Redis，多个sentinel也可以监控同一个redis<br><br>* sentinel最好不要和Redis部署在同一台机器，不然Redis的服务器挂了以后，sentinel也挂了
工作机制
* 每个sentinel以每秒钟一次的频率向它所知的master，slave以及其他sentinel实例发送一个 PING 命令 <br><br>* 如果一个实例距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 则这个实例会被sentinel标记为主观下线。 <br><br>* 如果一个master被标记为主观下线，则正在监视这个master的所有sentinel要以每秒一次的频率确认master的确进入了主观下线状态<br><br>* 当有足够数量的sentinel（大于等于配置文件指定的值）在指定的时间范围内确认master的确进入了主观下线状态， 则master会被标记为客观下线 <br><br>* 在一般情况下， 每个sentinel会以每 10 秒一次的频率向它已知的所有master，slave发送 INFO 命令 <br><br>* 当master被sentinel标记为客观下线时，sentinel向下线的master的所有slave发送 INFO 命令的频率会从 10 秒一次改为 1 秒一次 <br><br>* 若没有足够数量的sentinel同意master已经下线，master的客观下线状态就会被移除；<br> 若master重新向sentinel的 PING 命令返回有效回复，master的主观下线状态就会被移除
配置
修改sentinel.conf<br><br>daemonize yes<br>logfile "/usr/local/redis/sentinel.log"<br>dir "/usr/local/redis/sentinel" #sentinel工作目录<br>sentinel monitor mymaster 192.168.30.128 6379 2 #判断master失效至少需要2个sentinel同意，建议设置为n/2+1，n为sentinel个数<br>sentinel auth-pass mymaster 123456<br>sentinel down-after-milliseconds mymaster 30000 #判断master主观下线时间，默认30s
问题：无法动态扩容
集群（cluster）
特点
* 多个redis节点网络互联，数据共享<br><br>* 所有的节点都是一主一从（也可以是一主多从），其中从不提供服务，仅作为备用<br><br>* 不支持同时处理多个key（如MSET/MGET），因为redis需要把key均匀分布在各个节点（16384个slot）上，<br> 并发量很高的情况下同时创建key-value会降低性能并导致不可预测的行为<br> <br>* 支持在线增加、删除节点<br><br>* 客户端可以连接任何一个主节点进行读写
配置
cluster-enabled yes<br>cluster-config-file nodes_7001.conf<br>cluster-node-timeout 15000<br><br>redis-cli -a 123456 --cluster create IP host ...<br>CLUSTER NODES<br>
引申
CRC16(key) % 16384
