一、 Redis官方推荐集群方案：Redis Cluster
适用于redis3.0以后版本，
Redis群集数据分片
· Redis Cluster不使用一致的散列，而是使用不同形式的分片，其中每个键称之为 hash slot.。
Redis集群中有16384个散列槽，为了计算给定密钥的散列槽，我们只需采用密钥模数16384的CRC16。
Redis群集中的每个节点都负责哈希槽的子集，例如，拥有一个包含3个节点的集群，其中：
- 节点A包含从0到5500的散列槽。
- 节点B包含从5501到11000的散列槽。
- 节点C包含从11001到16383的散列槽。
这允许轻松添加和删除集群中的节点。例如，如果我想添加一个新节点D，我需要将一些哈希槽从节点A，B，C移动到D.同样，如果我想从群集中删除节点A，我只需移动A服务的哈希槽。到B和C.当节点A为空时，我可以完全从集群中删除它。
因为将哈希槽从一个节点移动到另一个节点不需要停止操作，添加和删除节点，或者更改节点所持有的哈希槽的百分比，所以不需要任何停机时间。
只要涉及单个命令执行（或整个事务或Lua脚本执行）的所有键都属于同一个哈希槽，Redis Cluster就支持多个键操作。用户可以通过使用称为哈希标记的概念强制多个密钥成为同一哈希槽的一部分。
Hash标签记录在Redis集群规范中，但要点是如果密钥中{}括号之间有子字符串，则只对字符串内部的内容进行哈希处理，例如this{foo}key并another{foo}key 保证位于相同的哈希槽中，并且可以在具有多个键作为参数的命令中一起使用。
Redis Cluster主从模型
为了在主节点子集发生故障或无法与大多数节点通信时保持可用，Redis Cluster使用主从模型，其中每个散列槽从1（主机本身）到N个副本（N） -1个额外的从节点）。创建集群时，每个主节点添加一个从节点，以便最终集群由作为主节点的A，B，C和作为从节点的A1，B1，C1组成。如果节点B出现故障，系统就能继续运行。节点B1复制B，B失败，集群将节点B1升级为新的主节点，并将继续正常运行。
注意，如果节点B和B1同时发生故障，Redis Cluster将无法继续运行。
Redis群集一致性保证
Redis Cluster无法保证强一致性。在某些条件下，Redis Cluster可能会丢失系统向客户端确认的写入。
Redis Cluster可能丢失写入的第一个原因是它使用异步复制。这意味着在写入期间会发生以下情况：
- 客户端写入master B.
- master B向客户端回复确定。
- master B将写入传播到其从设备B1，B2和B3。
（1）B在回复客户端之前并没有等待来自B1，B2，B3的确认，因为这对Redis来说是一个过高的延迟，所以如果客户端写了一些东西，B会确认写入，但是在崩溃之前能够将写入发送到其slave，其中一个slave（没有接收到写入）被提升为master ，永远丢失写入。
这与大多数数据库配置为每秒将数据刷新到磁盘的所发生的情况非常相似。同样，可以通过在回复客户端之前强制数据库刷新磁盘上的数据来提高一致性，但会导致性能过低。在Redis Cluster情况下，相当于同步复制。
解决办法，即需要在性能和一致性之间进行权衡。
Redis Cluster在绝对需要时支持同步写入，通过WAIT命令实现，这使得丢失写入的可能性大大降低，但即使使用同步复制，Redis Cluster也不会实现强一致性：在更复杂的情况下总是可以实现失败场景，无法接收写入的slave被选为master。
（2）还有另一个值得注意的情况是，Redis集群将丢失写入，这种情况发生在网络分区中，其中客户端与少数实例（至少包括主服务器）隔离。如，
以6个节点簇为例，包括A，B，C，A1，B1，C1，3个主站和3个从站。还有一个客户，我们称之为Z1。
在发生分区之后，可能在分区的一侧有A，C，A1，B1，C1，在另一侧有B和Z1。
Z1仍然可以写入B，它将接受其写入。如果分区在很短的时间内恢复，集群将继续正常运行。但是，如果分区持续足够的时间使B1在分区的多数侧被提升为主，则Z1发送给B的写入将丢失。
注意，Z1将能够发送到B的写入量存在maximum window：如果分区的多数方面已经有足够的时间将slave选为master，则少数端的每个主节点都会停止接受写入。
这段时间是Redis Cluster的一个非常重要的配置指令，称为节点超时。
节点超时过后，master被视为失败，可以由其中一个副本替换。类似地，在节点超时已经过去而主节点无法感知大多数其他主节点之后，它进入错误状态并停止接受写入。
2)：如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 则这个实例会被 Sentinel 标记为主观下线。
3)：如果一个Master被标记为主观下线，则正在监视这个Master的所有 Sentinel 要以每秒一次的频率确认Master的确进入了主观下线状态。
4)：当有足够数量的 Sentinel（大于等于配置文件指定的值）在指定的时间范围内确认Master的确进入了主观下线状态， 则Master会被标记为客观下线
5)：在一般情况下， 每个 Sentinel 会以每 10 秒一次的频率向它已知的所有Master，Slave发送 INFO 命令
6)：当Master被 Sentinel 标记为客观下线时，Sentinel 向下线的 Master 的所有 Slave 发送 INFO 命令的频率会从 10 秒一次改为每秒一次
7)：若没有足够数量的 Sentinel 同意 Master 已经下线， Master 的客观下线状态就会被移除。
若 Master 重新向 Sentinel 的 PING 命令返回有效回复， Master 的主观下线状态就会被移除。
主从复制：主节点负责写数据，从节点负责读数据，主节点定期把数据同步到从节点保证数据的一致性
备注：主从复制和哨兵机制需要进行手动配置。
三、Redis作为缓存应用问题及解决方案：
1）缓存穿透
- 对所有可能查询的参数以hash形式存储，在控制层先进行校验，不符合则丢弃。还有最常见的则是采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。
- 也可以采用一个更为简单粗暴的方法，如果一个查询返回的数据为空（不管是数据不存在，还是系统故障），我们仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。
2）缓存雪崩
- 在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程查询数据和写缓存，其他线程等待。
- 可以通过缓存reload机制，预先去更新缓存，再即将发生大并发访问前手动触发加载缓存
- 不同的key，设置不同的过期时间，让缓存失效的时间点尽量均匀. 比如我们可以在原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件
- 做二级缓存，或者双缓存策略。A1为原始缓存，A2为拷贝缓存，A1失效时，可以访问A2，A1缓存失效时间设置为短期，A2设置为长期。
3）缓存击穿
4）缓存预热
- 直接写个缓存刷新页面，上线时手工操作下；
- 数据量不大，可以在项目启动的时候自动进行加载；
- 定时刷新缓存；
5）缓存更新
- 定时去清理过期的缓存；
- 当有用户请求过来时，再判断这个请求所用到的缓存是否过期，过期的话就去底层系统得到新数据并更新缓存。
6）缓存降级
- 一般：比如有些服务偶尔因为网络抖动或者服务正在上线而超时，可以自动降级；
- 警告：有些服务在一段时间内成功率有波动（如在95~100%之间），可以自动降级或人工降级，并发送告警；
- 错误：比如可用率低于90%，或者数据库连接池被打爆了，或者访问量突然猛增到系统能承受的最大阀值，此时可以根据情况自动降级或者人工降级；
- 严重错误：比如因为特殊原因数据错误了，此时需要紧急人工降级。
四、redis作为分布式锁方案（性能最优）
分布式锁是控制分布式系统之间同步访问共享资源的一种方式。
实现思路：
- 使用
SETNX命令获取锁，若不存在则设置值，设置成功则表示取得锁成功； - 设置expire，保证超时后能自动释放锁（使用lua脚本将setnx和expire变成一个原子操作）；
- 释放锁，使用
DEL命令将锁数据删除。