redis高可用

一.redis缓存问题介绍：
1.缓存穿透：
指的是：查询数据库不存在的key值，查询时一直不查询redis缓存，就像redis缓存透明一样。

解决：
方法1.就算数据库查询不到值也存放到redis，key是用户查询的name，value是null，设置一个短暂的key存活时间。

方法2：布隆过滤器：预先在布隆过滤器存放有效的key，不在过滤器里的key就直接返回为null

2.缓存雪崩：
指的是：一时间大量的key过了有效期，导致大量并发查询数据库。
或者指的是redis服务器宕机。大量查询数据库。
解决：
方法1：将key指有效期设置长点，设置质数有效期，错开过期的时间
方法2：第三方缓存：如memory cache ， mybatis缓存，
方法3：存的key是永久时间，后台定时设置定时清理任务。
方法4：网关限流
方法5：消息队列

3.缓存击穿：
指的是：热门的key失效，导致大量并发查询数据库
解决：热门的key永远不失效，后台定时清理任务。

二：redis集群方案
方案1：主从复制：解决查询并发量

利用主服务器进行写与读，从服务器只能读取。
写在主服务器，那么从服务器怎么同步数据呢？

1.全量同步RDB：从服务器重新获取完整的主服务器的数据
2.增量同步AOF：从服务器复制主服务器的偏移量

主从复制的同步步骤：
一.从服务器第一次连接主服务器：
1.主服务器将数据库信息存储到磁盘的快照文件里，
2.再将新的写命令缓存起来，
3.后台进程执行缓存写命令到主服务器的数据库里，
4.主服务器执行完写命令后，
5.主服务器发送同步指令并携带快照文件给从服务器，
6.从服务器将快照文件恢复到从服务器的数据库里，
7.主服务器再将缓存命令转发给从服务器，
8.从服务器再更新数据库。

二.非第一次连接之后的数据同步：
主服务器写命令后就会将命令传播给从服务器，从服务器再更新数据

主服务器会有偏移量版本，每次执行写曹操做操作版本往后+1，从服务器版本与主服务器版本一致达成数据一致。

三.主从服务器断开之后重新连接：
一.全量同步情况
1.初次连接主服务器会将id发送给从服务器，从服务器重新连接会根据原来的主服务器id和新的主服务器id判断是否是同一部主服务器，如果id不相同则执行全量同步。
2.如果id相同，但是偏移量版本不一致且主服务器的缓存里不能满足主从数据一致，则全量同步。
二.增量同步情况
主服务器id相同，且版本不一致，且缓存区里有数据使得主从一致，则增量同步

当主服务器挂了之后，需要手动选举新的主服务器：
步骤：
1.断开从服务器与主服务器关联。
2.从服务器选举成新的主服务器
3.其他的从服务器连接主服务器

手动设置新主很麻烦，redis有哨兵sentinel功能来监控主服务器情况自动切换新主

主从复制与哨兵sentinel
功能：
1.监控，监控主服务器和从服务器是否正常
2.提醒：向管理员发送故障信息
3.自动故障转移：
当主服务器故障则从服务器进行选举新的主服务器。

选举的依据==依次是：网络连接正常->5秒内回复过INFO命令->10*down-after-milliseconds内与主连接过的->从服务器优先级->复制偏移量->运行id较小的。选出之后通过slaveif no one将该从服务器升为新主服务器

哨兵会不断的发送接收主服务器的请求来保证主服务器活着。
故障转移原理：
哨兵判断服务器是否下线：
主观下线：一台哨兵ping主服务器过了有效答复时间就判断主服务器挂了，一个哨兵太主观
客观下线：
多台哨兵监控一台主服务器，设定流言数量，多个哨兵去发送接收主服务器的请求，如果断开连接的数量超过了留言数量，就表示主服务器已经客观下线，

方案2：redis内置集群cluster与哈希槽
当写达到一定的并发量时需要多台写服务器进行并发处理
redis集群解决写的并发问题
多台写服务器会造成数据同步问题
解决数据同步问题：
对服务的方法进行上锁。
可以进行数据库的分片处理，每个主服务器负责一部分数据的写，其他服务器不会去写这些值，但是数据是共享的，即其他服务器可以读取到不属于他们分片下的数据的值。

哈希槽介绍：
redis集群采用一种哈希槽的方式进行数据的分配，哈希槽默认槽数是16384个，当我们新增一个key时，哈希槽进行CRC16算法进行计算该key存储到具体哪个槽位。
槽位：CRC16（key的值）%16384

当我们有3个主服务器
节点之间需要不断进行PING/PANG通讯来达到哈希槽里的数据共享
则给每个主服务器配置哈希槽

• 节点A覆盖0－5460
• 节点B覆盖5461－10922
• 节点C覆盖10923－16383
  redis集群支持主从复制，即主服务器下有从服务器

一致性哈希算法介绍
一致性哈希算法是一种分布式算法，常运用于负载均衡，利用这种算法来实现key值均匀的分布在服务器上
哈希环：
利用传统算法hash key的值分布到 0~（2^32）-1的数字空间，

当用户在客户端进行请求时候，首先根据key计算路由hash值，然后看hash值落到了hash环的哪个地方，根据hash值在hash环上的位置顺时针找距离最近的节点：

当新增节点的时候，和之前的做法一样，只需要把受到影响的数据迁移到新节点即可

新增Master4节点：

当移除节点的时候，和之前的做法一样，把移除节点的数据，迁移到顺时针距离最近的节点

移除Master2节点

从上面的步骤可以看出，当节点个数变动时，使用哈希一致性映射关系失效的对象非常少，迁移成本也非常小

判断哈希算法好坏的标准：
1.平衡性：每个服务器负责的数据压力大致相同
2.单调性：服务器宕机后的故障转移时或者新增服务器，要么不移动，移动的话移动到新的服务器上，而不是移动到原来的服务器上
3.分散性：好的哈希算法应该尽量降低服务器之间的分散性
分布式环境中，客户端请求可能不知道所有服务器的存在，可能只知道其中一部分服务器，在客户端看来他看到的部分服务器会形成一个完整的hash环。如果多个客户端都把部分服务器作为一个完整hash环，多个服务器自成环，形成几个环，那么可能会导致，同一个用户的请求被路由到不同的服务器进行处理。这种情况显然是应该避免的，因为它不能保证同一个用户的请求落到同一个服务器。所谓分散性是指上述情况发生的严重程度。好的哈希算法应尽量量避免尽量降低分散性。 而一致性hash具有很低的分散性。

哈希倾斜：
哈希环中，当机器宕机后会顺时针找最近的服务器进行故障转移，那刚好下一个服务器也宕机了，就会造成很多的数据都让一个服务器处理，造成的哈希倾斜。
解决：原本的机器将虚拟出新的机器（节点）来存放数据，重新将数据进行转移达到相对平衡效果。

redis处理分布式锁：
1.用redis做分布式锁，每次访问数据库之前都会访问redis。
2.setnx（lock_sale_商品ID，1），最之前就给要访问的某个商品上锁，如果上锁成功就代表自己是第一个访问的人，可以去修改对象，如果不能设置成功，就表示前面已经有人访问了，不能去修改。
3.处理完对象之后的方法中，要去主动开锁：del（lock_sale_商品ID），这样其他的客户端就能去访问。
4.防止死锁，设置锁的存活时间：expire（lock_sale_商品ID，30）
或者set（lock_sale_商品ID，1，30，NX） ，一开始就设置存储在redis的锁的存活时间。
4.避免在设置的锁的有效期里，任务还没有执行完就提前放锁：守护线程：用来给快过期的还没有执行完成的线程续命，给锁加时间.
主线程执行完毕，守护线程也会跟着结束.

Redis的分布式锁是对某个特定的id进行

守护线程：子线程负责延时，主线程（执行的方法）中设置守护线程，主线程没有执行完，子线程一直在，主线程执行完，子线程也执行完。