验证码的时效性
redis场景，服务器内存不够了，怎么办（或者说被人干蹦了），我们的redis信息是不是就没了，redis服务hi不是挂了，如何优化？容灾方式？分配redis多大内存，是否满足我们的生产的需求，一般我们会缓存到多大的一个数据量，峰值是多少？
思路
Redis场景，服务器内存不够了：
一，增加内存
redis存储在内存中，数据太多，占用大多内存，那么增加内存就是直接的方法，但是这个方法一般不采用，因为内存满了就加内存，满了就加，那代价太大，相当于用钱解决的问题，不首先考虑，一般有方面都做到最优化，才考虑此方法。
二，搭建Redis集群
- 所有的redis节点批次互联（PING-PONG机制),内部使用二进制协议优化传输速度和宽带。
- 节点的fail是通过集群中超过半数的节点检测时效时才生效。
- 客户端与redis节点智联，不需要中间proxy层，客户端不需要连接集群所有的节点，连接集群中任何一个可用的节点即可。
- redis-cluster把所有的物理节点映射到[0-16383]slot上，cluster负责维护node<->slot<->value
Redis 集群中内置了 16384 个哈希槽，当需要在 Redis 集群中放置一个 key-value 时，redis 先对 key 使用 crc16 算法算出一个结果，然后把结果对 16384 求余数，这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽，redis 会根据节点数量大致均等的将哈希槽映射到不同的节点，最多16384个节点。
节点间相互通信，一半以上节点ping不同一个节点，则说明此节点挂掉，从节点顶上
(1)集群中所有master参与投票,如果半数以上master节点与其中一个master节点通信超过(cluster-node-timeout),认为该master节点挂掉.
(2):什么时候整个集群不可用(cluster_state:fail)?
- 如果集群任意master挂掉,且当前master没有slave，则集群进入fail状态。也可以理解成集群的[0-16383]slot映射不完全时进入fail状态。
- 如果集群超过半数以上master挂掉，无论是否有slave，集群进入fail状态。
Redis服务器因某种原因崩掉了，redis的信息是不是就没了 （容灾方式）
redis 持久化策略：
RDB：对redis中的数据周期性的持久化
优点
1、会生成多个数据文件，每个数据文件都代表了某一个时间的全部数据。非常适合做冷备。可以将数据上传到云服务备份。
2、RDB对redis对外提供的服务影响小，可以让redis保持高性能。
3、相比较来说，基于RDB文件重启恢复redis更快
AOF：对每条写入命令作为日志。以append-only模式写入日志。
优点
1、可以更好的保护数据不丢失，一般AOF每隔1秒，通过后台线程执行一次fsync操作。最多丢失1s数据
2、文件以append-only模式写入，没有io开销。文件不容易损坏。损坏也很容易恢复。
3、AOF日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写。因为在rewrite log的时候，会对其中的指导进行压缩，创建出一份需要恢复数据的最小日志出来。再创建新日志文件的时候，老的日志文件还是照常写入。当新的merge后的日志文件ready的时候，再交换新老日志文件即可。
4、日志文件可读性强。适合做灾难性的误删除的紧急恢复。
一般线上环境我们会将2中机制都开启。具体的RDB策略和AOF策略都可以在redis.conf里面配置
RDB： save 60 1000 : 表示每60s有超过1000条数据更新就备份。
AOF： append-only : true 开启aof策略
everysec: 每秒备份
auto-aof-rewrite-percentage 100 : 当aof大小膨胀到上次2倍就备份
auto-aof-rewrite-min-size 64mb ： 和上面是 且 关系。 aof文件必须超过64m才会备份
通过RDB恢复数据的步骤：
先将云服务的RDB备份数据copy到redis配置的备份目录。然后将aof关闭（一定要关闭，否则优先从aof日志文件本分，但是如果没有的话就创建空的。所以redis是无法加载rdb备份文件的）。然后重启redis，此时我们redis-cli 进入redis发现redis已经自动加载备份的rdb文件数据了。这时候手动命令启动aof。这时候redis就会备份aof日志。这启动aof是暂时的。我们停掉redis，在配置文件中修改将aof开启，然后再开启，现在redis已经恢复数据，且AOF已经开启了。
