缓存雪崩、缓存穿透、缓存击穿
    缓存雪崩是指缓存同一时间大面积的失效，所以，后面的请求都会落到数据库上，造成数据库短时间内承受大量请求而崩掉。
    解决方案:
    ●缓存数据的过期时间设置随机，防止同一时间大量数据过期现象发生。
    ●给每一个缓存数据增加相应的缓存标记.记录缓存是否失效，如果缓存标记失效， 则更新数据缓存。
    ●缓存预热
    ●互斥锁
    缓存穿透是指缓存和数据库中都没有的数据，导致所有的请求都落到数据库上,造成数据库短时间内承受大量请求 而崩掉。
    解决方案:
    ●接口层增加校验，如用户鉴权校验，id做基础校验，id<=0的直接拦截;
    ●从缓存取不到的数据，在数据库中也没有取到，这时也可以将key-value对写为key-null,缓存有效时间可以设置短点，如30秒(设置太长会导致正常情况也没法使用)。这样可以防止攻击用户反复用同一个id暴力攻击
    ●采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中,一个 定不存在的数据会被这个bitmap拦截掉,从而避免了对底层存储系统的查询压力

    缓存击穿是指缓存中没有但数据库中有的数据(一般是缓存时间到期)， 这时由于并发用户特别多,同时读缓存没读到数据，又同时去数据库去取数据，引起数据库压力瞬间增大，造成过大压力。和缓存雪崩不同的是,缓存击穿 指并发查同一条数据， 缓存雪崩是不同数据都过期了，很多数据都查不到从而查数据库。
    解决方案
    ●设置热点数据永远不过期。
    ■加互斥锁

    redis集群方案
    主从
    哨兵模式:
    sentinel,哨兵是redis集群中非常重要的一个组件,主要有以下功能:
    ●集群监控:负责监控redis master和slave进程是否正常工作。
    ●消息通知:如果某个redis实例有故障，那么哨兵负责发送消息作为报警通知给管理员。
    ●故障转移:如果master node挂掉了，会自动转移到slave node.上。
    ●配置中心:如果故障转移发生了，通知client客户端新的master地址。
    哨兵用于实现redis集群的高可用，本身也是分布式的.作为一个哨兵集群去运行，互相协同工作。
    ■故障转移时，判断-一个master node是否宕机了,需要大部分的哨兵都同意才行,涉及到了分布式选举
    即使部分哨兵节点挂掉了，哨兵集群还是能正常工作的
    ■哨兵通常需要3个实例，来保证自己的健壮性。
    ■哨兵+ redis主从的部署架构，是不保证数据零丢失的，只能保证redis集群的高可用性。
    ■对于哨兵+ redis主从这种复杂的部署架构，尽量在测试环境和生产环境，都进行充足的测试和演练。
    Redis Cluster是一种服务端Sharding技术， 3.0版本开始正式提供。 采用slot(槽)的概念，一共分成16384个槽。将 Redis群集是一种服务端切分技术，请求发送到任意节点，接收到请求的节点会将查询请求发送到正确的节点上执行

    方案说明
    ●通过哈希的方式，将数据分片，每个节点均分存储一定哈希槽(哈希值)区间的数据，默认分配了16384个槽位
    ●每份数据分片会存储在多个互为主从的多节点上
    ●数据写入先写主节点，再同步到从节点(支持配置为阻塞同步)
    ●同一分片多个节点间的数据不保持强一致性
    ●读取数据时，当客户端操作的key没有分配在该节点上时, redis 会返回转向指令,指向正确的节点
    ●扩容时需要把旧节点的数据迁移-部分到新节点
    在redis cluster架构下，每个redis要放开两个端口号,比如一个是6379,另外-一个就是加1w的端口号,比如16379.。
    16379端口号是用来进行节点间通信的，也就是cluster bus的通信，用来进行故障检测、配置更新、故障转移授权。cluster bus用了另外一种二进制的协议， gossip 协议，用于节点间进行高效的数据交换，占用更少的网络带宽和处理时间。

    优点
    ●无中心架构，支持动态扩容,对业务透明
    ●具备SentineI的监控和自动Failover(故障转移)能力
    ●客户端不需要连接集群所有节点，连接集群中任何-个可用节点即可
    ●高性能，客户端直连redis服务， 免去了proxy代理的损耗
    缺点
    ●运维也很复杂，数据迁移需要人工干预
    ●只能使用0号数据库
    ●不支持批量操作(pipeline管道操作) 管道， 分布式逻辑和存储模块耦合等

    Redis Sharding是Redis. Cluster出来之前，业界普遍使用的多Redis实例集群方法。其主要思想是采用哈希算法将 Redis数据的key进行散列，通过hash函数，特定的key会映射到特定的Redis节点上。Java redis客户端驱动,支持Redis Sharding功能.。即ShardedJedis以及结合缓存池的
    优点
    优势在于非常简单，服务端的Redis实例彼此独立,相互无关联，每个Redis实例像单服务器一样运行, 非常容易 线性扩展，系统的灵活性很强
    缺点
    由于sharding处理放到客户端，规模进一步扩大时给运维带来挑战。
    客户端sharding不支持动态增删节点。服务端Redis实例群拓扑结构有变化时，每个客户端都需要更新调整。连接不能共享，当应用规模增大时，资源浪费制约优化

    redis持久化
    bgsave 执行该命令时，Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。具体流程如下：
    具体操作是Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在fork阶段，一般时间很短。基本上 Redis 内部所有的RDB操作都是采用 bgsave 命令。
    自动触发
    自动触发是由我们的配置文件来完成的。在redis.conf配置文件中，里面有如下配置，我们可以去设置：
    ①save：这里是用来配置触发 Redis的 RDB 持久化条件，也就是什么时候将内存中的数据保存到硬盘。比如“save m n”。表示m秒内数据集存在n次修改时，自动触发bgsave。
    4、RDB 的优势和劣势
    ①、优势
    （1）RDB文件紧凑，全量备份，非常适合用于进行备份和灾难恢复。
    （2）生成RDB文件的时候，redis主进程会fork()一个子进程来处理所有保存工作，主进程不需要进行任何磁盘IO操作。
    （3）RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。
    ②、劣势
    RDB快照是一次全量备份，存储的是内存数据的二进制序列化形式，存储上非常紧凑。当进行快照持久化时，会开启一个子进程专门负责快照持久化，子进程会拥有父进程的内存数据，父进程修改内存子进程不会反应出来，所以在快照持久化期间修改的数据不会被保存，可能丢失数据。
    三、AOF机制
    全量备份总是耗时的，有时候我们提供一种更加高效的方式AOF，工作机制很简单，redis会将每一个收到的写命令都通过write函数追加到文件中。通俗的理解就是日志记录。
    3、AOF也有三种触发机制
    （1）每修改同步always：同步持久化 每次发生数据变更会被立即记录到磁盘 性能较差但数据完整性比较好
    （2）每秒同步everysec：异步操作，每秒记录 如果一秒内宕机，有数据丢失
    （3）不同no：从不同步
    4、优点
    （1）AOF可以更好的保护数据不丢失，一般AOF会每隔1秒，通过一个后台线程执行一次fsync操作，最多丢失1秒钟的数据。（2）AOF日志文件没有任何磁盘寻址的开销，写入性能非常高，文件不容易破损。
    （3）AOF日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写。
    （4）AOF日志文件的命令通过非常可读的方式进行记录，这个特性非常适合做灾难性的误删除的紧急恢复。比如某人不小心用flushall命令清空了所有数据，只要这个时候后台rewrite还没有发生，那么就可以立即拷贝AOF文件，将最后一条flushall命令给删了，然后再将该AOF文件放回去，就可以通过恢复机制，自动恢复所有数据
    5、缺点
    （1）对于同一份数据来说，AOF日志文件通常比RDB数据快照文件更大
    （2）AOF开启后，支持的写QPS会比RDB支持的写QPS低，因为AOF一般会配置成每秒fsync一次日志文件，当然，每秒一次fsync，性能也还是很高的
    （3）以前AOF发生过bug，就是通过AOF记录的日志，进行数据恢复的时候，没有恢复一模一样的数据出来。