Redis集群和分布式锁
Redis集群概述
集群的核心意义只有一个：保证一个节点出现了问题之后，其他的节点可以继续提供服务使用。
Redis基础部分讲解过主从配置：对于主从配置可以有两类：一主二从，层级关系。开发者一主二从是常用的手段。
Redis的主从配置是所有Redis集群的一个基础。但是只是依靠主从依然无法实现高可用的配置。
Redis集群有以下两种方案
1)keepalived+twemproxy+HAProxy+sentinel
对redis集群而言，首先在主从的基础上发展出了一个叫哨兵的处理机制，所谓的哨兵的处理机制指的是，当我三台主机的master节点出现了问题之后，会自动的在两个slave节点下重新退选举出一个新的master节点，这样就可以保证原master出现问题之后，redis数据依然存在有主从的配置。
但是哨兵机制也只是针对于一种单主机的配置形式。因为不可能只使用一台主机来实现我们redis的配置。而推特网站发布了一个代理机制。可以有效的实现数据的分片存储。即：根据不同算法 实现不同主机的分片存储。
以保证负载均衡，同时可以结合keepalivedh和HAProxy组件实现twemproxy的高可用。
2)Redis Cluster
Redis在后来的版本发展之中也推出了一个自己的redis Cluster集群配置，利用这样的配置可以不用自己来通过配置文件实现主从关系的实现，而直接通过命令完成。
keepalived+twemproxy+HAProxy+sentinel
哨兵机制简介
只要是进行高可用的架构部署，那么就必须保证多节点，在Redis里面使用了主从模式可以多节点配置，但是传统的主从模式设计 一旦master主机出现问题之后，两台Slave主机无法提供正常的工作支持，列如：Slave主机为只读主机，而且如果要想继续提供支持，那么至少应该通过剩余的几台Slave里面去推选出一个新的Master，并且最为重要的是：这个新的Master能够被用户的程序找到。
如果要想进行哨兵机制的实现，一定需要具备有如下的几个特点：
sentinel的功能
1）监控Monitoring
sentinel时刻监控着redis master-slave是否正常运行；
2）通知Notification
sentinel可以通过api来通知管理员，被监控的redis master-slave出现了问题。
3）自动故障转移Automatic failover
当redis master出现故障不可用状态，sentinel会开始一次故障转移，将其中一个salve提升为一个新的master，将其他salve重新配置使用新的master同步，并使用Redis的服务器应用程序连接时收到使用新的地址连接。
4）配置提供者Configuration provider
sentinel作为在集群中的权威来源，客户端连接到sentinel来获取某个服务的当前Redis主服务器的地址和其他信息。当故障发生转移时，Sentinel会报告新地址(更改哨兵文件对应的配置内容)。
通常一台主机运行三个哨兵，并且该哨兵运行的端口不同，但是这三个哨兵都要去监控同一个master的地址。(找到了master就等于找到了所有的slave)
twemproxy分片处理
不管你电脑性能多好，只要你运行了Redis,那么就有可能造成一种非常可怕的局面：你电脑的内存将立刻被占满，而且一台Redis数据库的性能终归是有限制的。
TwemProxy是一个专门为了这种nosql数据库设计的一款代理工具软件，这个工具软件最大的特征是可以实现数据的分片处理。所为的分片指的是根据一定的算法将要保存的数据保存到不同的节点之中。
twemProxy整合sentinel
Twemproxy如果要与Redis集成使用的是Redis的Master节点，因为只有Master节点才具有写功能。
一旦某一个Master被干掉了，则一定要重新选举出一个新的Master节点，但是这个时候会出现有一个问题：twemproxy所使用的配置文件时单独存在的。哨兵选举完成后，需要更新配置文件
如果要想保证所有的Redis集群高可用设计，需要单独准备一个shell脚本与所有的哨兵机制一起使用。 两步操作：1.、更改redis_master.conf文件(twemproxy的配置文件) 2、重新启动twemproxy进程
HAProxy与twemproxy集成
Twemproxy主要功能在于数据的分片处理，而且会发现在整个Redis集群里面必须通过twemProxy，于是这个时候就有可能造成一种问题你后面Redis集群一定会速度爆快，因为一堆的redis数据库。但是所有的性能都卡在了代理上
解决办法：用HAProxy做twemproxy的代理。
HAProxy是一个开源的，高性能的，基于TCP第四层和http第七应用层的千万级高并发负载均衡软件；
为了保证HAProxy的高可用设计，所以应该设计有两套的HAProxy的代理主机，但是现在就出现了一个问题，如果现在提供了两套的HAProxy主机，用户应该怎么访问？需要记住两个地址吗。
用户访问Keepalived虚拟IP，Keepalived访问主(备)HAProxy
Keepalived是一个基于VRRP协议来实现的服务高可用方案，可用利用其来避免IP单点故障，类似的工具还有heartbeat，pacemaker。但是它一般不会单独出现，而是与其他负载均衡技术(如lvs，nginx，haproxy)一起工作来达到集群高可用。
VRRP协议全称Virtual Router Redundancy Protocol，即虚拟路由冗余协议。
以下是keepalived+twemproxy+HAProxy+sentinel的整个架构图(小人是指哨兵)
Redis Cluster
以上Redis集群作为项目的部署环境，需要追加twemproxy代理做分片，而后使用HAProxy做twemproxy的负载均衡，而后使用Keepalived作为HAProxy的vip技术，但是这样的设计成本太高。
redis-cluster，直接使用redis就可以实现所谓的分片，高可用。
1）自动将数据进行分片，每个master上放一部分数据
2）提供内置的高可用支持，部分master不可用时，还是可以继续工作的
redis-cluster设计的时候考虑到了去中心化，中间件，因为中心点的存在导致了性能的瓶颈，解决一个问题 会解决第二个 第三个问题。。。
redis-cluster中每一个redis的服务它都可以具备分片，都可以具备集群的功能。
也就是说集群中的每个节点都是平等的关系，每个节点都保存各自的数据和整个集群的状态。每个节点都和其它所有节点连接，而且这些连接保持活跃。
这样就保证了我们只需要连接集群中的任意一个节点，就可以获取到其他节点的数据。
redis-cluster选举(容错)
选举过程是集群中所有master参与，如果半数以上master节点与当前master节点通信超过设置时间(cluster-node-timeout)，认为当前master节点挂掉。
当我发现某一台主机的master挂掉了，我们从新选举一个salve当做master：参考raft协议(整个过程中把哨兵避免了，不需要修改哨兵的配置文件了)
这样可以去掉所有的代理层组件，由Redis自己来完成，这就是redis-cluster的设计方案。
Redis 之间通过互相的 ping-pong 判断是否节点可以连接上。如果有一半以上的节点去
ping 一个节点的时候没有回应，集群就认为这个节点宕机了，然后去连接它的从节点。如
果某个节点和所有从节点全部挂掉，我们集群就进入 fail 状态。还有就是如果有一半以上的
主节点宕机，那么我们集群同样进入 fail 了状态。这就是我们的 redis 的投票机制，
缓存穿透和雪崩
缓存穿透：外界请求一个不存在的id，因为缓存没有，透过缓存不断攻击数据库
解决办法：缓存空对象/布隆过滤器在取redis缓存前进行拦截(你永远可以通过加一层进行解决问题)
把要查询的值先过布隆过滤器，判断是否存在，存在就走redis缓存，不存在就直接返回，并且配合缓存空值，可以有效解决缓存穿透问题，虽然存在一定误差，但是在业务范围内允许接受。
布隆过滤器是一个二进制数组，主要作用就是判断数据存不存在这个数组中，存在是1 不存在是0。
布隆过滤器把数据转换成0 1：计算数据的hash值比如7，在由hash值映射到数组的下标，把数组第七个位置改成1。
布隆过滤器误判：
因为存在Hash碰撞，不同数据存在的Hash值相同，就会存在误判的情况，可以通过多个hash函数来减少误判，但效率会低
布隆过滤器空间使用：
10亿条数据 用布隆过滤器，如果允许3%的误差，占用空间0.3GB，如果用set集合 80GB
缓存击穿：当某个key过期的瞬间，有大量请求打到数据库
解决办法：设置热点数据永不过期/分布式锁/限流
缓存雪崩：某一个时间段缓存集中失效。redis宕机 大量请求打到数据库
解决办法：redis高可用/限流降级/数据预热(设置不同的过期时间，让缓存失效的时间点尽量均匀)
思考？以上全是不是都可以通过guava限流来防止？
Redis分布式锁
在程序中调用setIfAbsent方法来获取锁，如果返回true，则说明该key值不存在，表示获取到了锁；
如果返回false，则说明该key值存在，已经有程序在使用这个key值，从而实现了分布式加锁的功能。serIfAbsent封装了Redis原生的SETNX原子操作。
疑问1：获取锁的时候为了防止机器宕机导致锁一直释放不了，所以增加了过期时间TTL，但是一个线程1请求TTL导致锁被释放此时线程1任务还没结束，则另一个线程2进来的时候 同样会获得到锁，
这样线程2可能会释放线程1的锁。
解决办法：1.value放进去的是一个requestId释放锁的时候比较requestId是否一致(高并发的时候 线程2可能删除线程1的key)。
2.设置定时任务检查 比如锁是10s时间，定时任务5s检查一次 如果主线程还持有这把锁(key还存在)并且锁还有1s到期，则重新更新锁的过期时间
疑问3：因为redis是主从架构，在主节点setnx的值之后，还没有同步到从节点，但此时主节点挂掉了，把从节点选为新的master。
新的线程发现没有这个key 可以再次加锁成功。
1.可以采用ZooKeeper 参考zookeeper一致性原理：https://www.cnblogs.com/ssskkk/p/14940829.html#_label4
zookeeper加锁步骤：https://www.cnblogs.com/ssskkk/p/14940829.html#_label2
2.采用Redis 的RedLock，此算法会尝试在每个Redis Node上面都上锁，大多数节点都能上锁成功才算上锁成功，此时 如果有某个redis节点宕机了，还是可以保证分布式锁可以上成功的。
