一站式学习Redis 从入门到高可用分布式实践

数据类型	每个userId占用空间	需要存储的用户量	内存使用总量
set	32位(假设userId用的是整型)	100,000	32位*100,000=4MB
Bitmap	1位	100,000,000	1位*100,000,000=12.5MB

41:连接代码

public static void main(String[] args) {
    Set<String> IPS = new HashSet<String>();
    IPS.add("192.168.136.158:26379");
    JedisSentinelPool pool = new JedisSentinelPool("mymaster", IPS);
    Jedis jedis=null;
    try{
        jedis = pool.getResource();
        jedis.set("foo", "bar");
        System.out.println(jedis.get("foo"));
    } catch(Exception e){
        e.printStackTrace();
       // logger.error(e.getMessage(),e);
    } finally {
        if(jedis != null)
            jedis.close();
    }

42：.Redis Sentinel实现原理

5.1 Redis Sentinel内部的三个定时任务

Redis Sentinel内部有三个定时任务来对redid节点进行故障判断和转移

1.每10秒每个sentinel对master和slave执行info命令，以发现slave节点和确认主从关系

sentinel在master节点执行info replication命令，从命令执行结果中解析出slave节点

2.每2秒每个sentinel通过master节点的channel交换信息(发布订阅)

master节点上有一个发布订阅的channel频道：__sentinel__:hello，用于所有sentinel之间进行信息交换

一个sentinel发布消息，消息包含当前sentinel节点的信息，对其他sentinel节点的判断以及当前sentinel对master节点和slave节点的一些判断

其他sentinel都可以接收到这条消息

新加入sentinel节点时，sentinel节点之间可以相互感知，以达到信息交互的功能

3.每1秒每个sentinel对其他sentinel节点和Redis节点执行ping操作

每个sentinel都可以知道其他sentinel节点，当监控的master发生故障时，方便进行判断和新master的挑选，这个定时任务是master进行故障判定的依据

5.2 主观下线和客观下线

主观下线：每个sentinel节点对Redis节点失败的'偏见'

在redis-sentinel配置文件中，有下面这种配置

sentinel monitor <master-name> <ip> <redis-port> <quorum>
sentinel down-after-milliseconds <master-name> <timeout>

一个sentinel集合可以同时监控多个master,slave的节点

sentinel对多个master，slave节点进行区分的标识就是master-name,ip和port是master节点的IP地址和端口,quorum是master客观下线之后sentinel进行判断的节点数

sentinel对master进行主观下线判断的时间，单们为毫秒

每个sentinel每秒对master和slave执行ping操作，当sentinel对master或slave在timeout定义的毫秒时间内没有回复，则sentinel会认为这个节点已经被主观下线了

在前面的例子中对sentinel的配置是

sentinel monitor mymaster 192.168.81.100 6379 2
sentinel down-after-milliseconds mymaster 30000

解释：

sentinel集合监控名为mymaster的master,slave节点
被监控的master节点的IP地址是192.168.81.100，端口为6379，
sentinel会在`__sentinel__:hello`频道中交流对master节点的看法，如果sentinel节点都对master节点ping失败'达成共识'，sentinel个数超过quorum的个数，sentinel集合则会认为master节点客观下线
当两个sentinel对master节点执行ping操作，在30000毫秒(30秒)时间内没有得到回复，则认为节点已经被主观下线

quorum建议设置为：(sentinel节点数 / 2) + 1，可以根据应用场景进行设定

43： sentinel领导者选举

要点：

只需要一个sentinel节点就可以完成故障转移
通过`sentinel is-master-down-by-addr`命令来完成sentinel交换对master节点的失败判定和新master的选举

完成sentinel领导者选举步骤：

1.每个做主观下线的sentinel节点向其他sentinel节点发送命令，要求将自己设置为领导者
2.收到命令的sentinel节点如果没有同意同意其他sentinel节点发送的命令，那么将同意该请求，否则拒绝
3.如果该sentinel节点发现自己的票数已经超过sentinel集合半数且超过quorum，将成为领导者
4.如果此过程中有多个sentinel节点成为领导者，那么将等待一段时间重新进行选举

5.4 故障转移(由sentinel领导者节点完成)

故障转移步骤：

1.从slave节点中选出一个合适的节点作为新的master节点
2.对选出的slave节点执行`slaveof no one`命令，使成为新的master节点
3.向剩余的slave节点发送命令，让slave节点成为新master节点的slave节点，然后从新master节点同步数据
    数据同步规则和parallel-syncs参数有关
    如一个一主三从架构中，master故障，sentinel领导者从3个slave中选出一个作为新的master节点，剩余的两个slave节点会成为新master节点的slave，从新master节点同步同步数据
    master节点只需要生成一次RDB文件
        如果parallel-syncs参数设置为1，则剩余两个slave节点会按顺序从新master节点拷贝数据，一个slave切点拷贝完成，另外一个slave才会从新master节点拷贝数据
        如果parallel-syncs参数设置为2，则两个slave节点会同时从master节点进行数据拷贝，这无疑会加入新master的开销
4.sentinel领导者会把原来的master节点设置为slave节点，并保持对其'关注'，当原来的master节点恢复后，sentinel会使其去复制新master节点的数据

5.5 slave节点的选择

slave节点选择规则

1.选择slave-priority(slave节点优先级)最高的slave节点，如果存在则返回，不存在则继续
2.选择复制偏移量(offset)最大的slave节点,offset最大说明对master的数据复制的最完整，如果存在则返回，不存在则继续
3.选择run_id最小的slave节点，run_id最小说明slave节点启动最早

6.总结：

Redis Sentinel是Redis的高可用实现方案：故障发现，故障自动转移，配置中心，客户端通知
Redis Sentinel是Redis 2.8版本开始才正式生产可用，之前版本不可用于生产
尽可以在不同物理机上部署Redis Sentinel所有节点，但是最好一个局域网内
Redis Sentinel中sentinel节点个数应该大于等于3，且最好为奇数，可以保证判断的公平
Redis Sentinel中的数据节点与普通数据节点没有区别
客户端初始化时连接的是Sentinel节点集合，不是具体的Redis节点，但是Sentinel只是配置中心不是代理
Redis Sentinel通过三个定时任务实现了Sentinel节点对于master，slave，其余sentinel节点的监控
Redis Sentinel在对节点做失败判定时分为主观下线和客观下线
看懂Redis Sentinel故障转移日志对于Redis Sentinel以及问题排查非常有帮助
Redis Sentinel实现读写分离高可用可以依赖Redis Sentinel节点的消息通知，获取Redis数据节点的状态变化

44:数据分布

顺序分区和哈希分区

修改：顺序分布其实不支持批量操作

哈希分布

节点取余分区 --------建议多倍扩容比较好，数据迁移量少
```
扩容可能会迁移80%的数据 ，多倍扩容可能只迁移50%的数据
```
一致性哈希分区 --------token环，只影响邻近节点，对其他节点影响小（节点多时候建议），保证最小数据迁移和数据负载均衡
一致性哈希算法

假如有一个环平均分为4分，分割点就是图中的node1、node2、node3、node4。

如果有一个key通过hash计算落在了node3余node4之间，则按照顺时针的规则，将这个数据归node3管理。

下面来看两种假设情况：

【1】现在增加一个node5节点，只会影响node4和node1之间的数据。就是原来在node4与node5之间的数据，之前是归node1节点，现在归node5节点，会产生少量的数据迁移问题。新增节点或者删除节点不会影响全部的节点。node2、node3和node4管理的数据要比node5、node1多，达不到负载均衡的效果，会产生数据倾斜。

【2】node3不幸宕机，node1和node2节点不会受影响。只是原来归属node3的key现在需要由node4负责。如果一个节点不可用，则受影响的数据仅仅是此节点到其环空间中前一节点。假如node2也发生了宕机，则node3还要承受原本属于node的key，久而久之就会产生雪崩现象。

针对上述问题的解决方案——虚拟节点机制

通常情况下，一个台机器只负责一个节点，引入虚拟节点机制后，每台机器可以负责更多节点（下面以2个节点为例：node1A和node1B）。

如果存放node1A和node1B点机器挂掉了，数据的迁移如下：

我们可以看到，数据迁移到了两个节点上，相对于没有加入虚拟节点，数据负担更加均匀。当虚拟节点越多时，数据负担就会越均匀！
虚拟槽分区 --------前两者是客户端分片，后者是redis-cluster，服务端管理节点、槽、数据
1. 45：
  - 缓存更新策略
  1.LRU/LFU/FIFO算法剔除：例如maxmemory-policy
  
  2.超时剔除：例如expire
  
  3.主动更新：开发控制生命周期

缓存穿透优化----大量请求不命中
解决方法：

1.缓存空对象

2.布隆过滤器拦截

1)无底洞问题介绍：

无底洞问题的发现：
2010年，FaceBook有3000个memcache节点，发现加机器后性能没有提升，反而下降了。机器越多，性能下降越多。
产生该问题原因：批量操作的变化
一次mget的操作随着机器的增加，网络时间也会增加。

当然这只对节点非常多的情况下有很大影响。
问题的关键点：
更多的机器!=更多的性能
批量接口需求(mget.mset等)
数据增长与水平扩展需求

2)无敌洞问题优化(优化I/O)：

命令本身的优化：减少使用慢查询及hgetall bigkey等这种命令
优化网络时间：减少网络通信时间(Redis这种命令执行很快的主要优化这个)
具体一点可以查看前面的集群中的批量操作。
(在Mysql这种命令执行较慢的数据库中一般会去选择优化SQL语句本身)
降低客户端连接成本：长连接，连接池，NIO(非阻塞IO)等。

5.热点key的重建优化

1)问题简介：
1. 问题出现：
  
  在重建时有大量的数据访问缓存，大量的线程都进行查询数据与缓存重建，对数据库数据源有很大的压力，会减缓IO的时间。
2. 三个目标：
  - 减少重建缓存的次数
  - 数据尽可能一致
  - 减少潜在的危险
2)两个解决方案：
1. 两个解决方案：
  - 互斥锁
  - 永不过期
2. 互斥锁示意图：
  
  在进行查询及重建的过程中其他线程阻塞。
3. 互斥锁的简单代码：
4. 永远不过期方案：
  缓存层面：不会设置key的expire过期时间
  功能层面：为每个value添加一个逻辑过期时间，额外创建一个单独的线程来管理逻辑过期时间，如果超过了这个过期时间则进行重建。
  (会出现数据不一致的情况，但是不会阻塞线程)
5. 永远不过期的示意图：
6. 两种方案的对比

一站式学习Redis 从入门到高可用分布式实践

与原生M（mget,mset等）操作对比

bitmap位图的概念

全量复制开销~

部分复制

5.1 Redis Sentinel内部的三个定时任务

5.2 主观下线和客观下线

5.4 故障转移(由sentinel领导者节点完成)

5.5 slave节点的选择

6.总结：

一致性哈希算法

缓存穿透优化----大量请求不命中

5.热点key的重建优化