Redis: 集群测试和集群原理

集群测试

1 ) SET/GET 命令

• 测试 set 和 get 因为其他命令也基本相似，
• 我们在 101 节点上尝试连接 103 $ /usr/local/redis/bin/redis-cli -c -a 123456 -h 192.168.10.103 -p 6376
• 我们在插入或读取一个 key的时候，会对这个key做一个hash运算，运算完以后会得到对应槽的索引值
• 之后，就会把key插入槽里，当执行 $ set username zhangsan，username 这个key就会被hash运算

  - > Reddirecte to slot [14315] located at 192.168.10.103:6375
  

• 可见 username 的 槽是 14315，在 103:6375 这个实例上
• 并且，我现在如果执行 set 的时候主机是 6376，命令行会重定向到 6375，这是内部的一个转向
  
• 这是它内部在做的一个转向操作，之后，执行 $ set age 18 这个 age 运算完后插入 741槽
• 这里又有了一个转向，741 这个槽在 6371的实例范围之内, 这些范围在 $ cluster nodes 返回可见
  
  
  
  
• 执行 $ set address sh 发现并没有做转向，原因肯定是 address 运算之后，在 6371 实例槽的范围之内
  
  
  
  
• 注意，get 也一样，会转向, 不再演示

2 ) 开启从节点只读模式

• 关于从节点的只读模式，通过上面的例子，可以看出，所有的操作都是转发到主节点上去的
• 目前从节点只起到备份容灾的角色，而非读的角色分担压力，目前还没有开启从节点的读功能
• 我现在要释放压力，把读的压力给从节点，我只需要在从节点中执行一个 $ READONLY 命令即可
• 注意，这个 $ READONLY 命令只支持自己主节点的key的范围
  • 就是如果获取的 key 不在这个从节点复制的主节点中
  • 它是没有办法给你直接返回的，它还是会去做转发，这是必然的

单节点和集群模式的性能测试

• 我们对性能进行一个测试，通过 Redis 自带的 redis-benchmark 命令
• Redis 是通过同时执行多个命令实现的
• 把集群和单机分别执行一百万的get和set，看一下谁的性能更高，其实单机的性能是比较高的
• 在集群环境测试的时候，get/set 它内部会去做一个转向的处理, 单机没有这个过程

1 ）语法

• $ redis-benchmark [option] [option value]

• 参数

  选项	描述
  -h	指定服务器主机名
  -p	指定服务器端口
  -s	指定服务器 socket 方式连接
  -c	指定并发连接数
  -n	指定请求数
  -d	以字节的形式指定SET/GET值的数据大小
  -k	1=keep alive 0=reconnect
  -r	SET/GET/INCR 使用随机 Key
  -P	通过管道传输请求
  -q	指定强制退出 Redis
  –csv	以CsV格式输出
  -l	生成循环，永久执行测试
  -t	仅运行以逗号分隔的测试命令列表

2 ) 单机测试

# 随机set/get1000000条命令1000个并发
bin/redis-benchmark -a 123456 -h 192.168.10.101 -p 6379 -t set,get -r 1000000 -n 1000000 -c 1000

3 ) 集群测试

# 随机set/get1000000条命令1000个并发
bin/redis-benchmark -a 123456 -h 192.168.10.101 -p 6371 -t set, get -r 1000000 -n 1000000 -c 1000

4 ) 对比结果

• 综合上述单机和集群跑出来的数据结果，单机要更快！

集群原理

• 我们之前用到的单机，主从，哨兵这几种模式数据都是存在单个节点上
  • 如果说是主从的话，会有从节点，从节点也只是对主节点的数据进行复制
  • 而我们单个节点它存储是有上限的，而且我们说它还有写压力等
• 集群其实就是把请求包括数据的存储都分在了不同的节点上，就是把数据进行了分片存储
  • 当一个分片的数量达到上限的时候，还可以给它分成多个分片

1 ) 哈希槽

• 集群的原理是什么? 它的本质是哈希槽
  • Redis 集群，它并没有选用一致性哈希，一致性哈希它是一个圆环，它的节点是分配在这个圆环上
  • 当我们插入和删除节点的时候，它是会影响响临近的节点，对其他的节点没有影响，这是它的优点
  • 但是缺点就是在节点比较少的情况下，当你插入一个新的节点的时候，它影响到数据会比较多
  • 因为我们要做数据迁移，除非你有上千个节点，这个时候添加一个节点影响的就微乎其微了
  • 所以说它不太适合那种节点比较少的分布式的缓存
  • 一般我们公司里的集群不可能达到上千个节点，因为它性能本身就很高
  • 所以说 Redis 的集群它并没有选择一致性哈希算法
  • 它采用的是哈希槽的这种概念，主要原因就是一致性哈希它对于数据的分布
  • 节点的位置的控制并不是很友好
• 哈希槽其实是两个概念
  • 第一个概念就是哈希算法，Redis Cluster 的 hash算法，它不是简单的 hash()
    • 而是内部的一个crc16的算法, 是一种校验算法
  • 第二个就是槽位的一个概念，就是空间分配的规则
    • 其实哈希槽的本质和一致性哈希算法是非常相似的
    • 不同点就是对于哈希空间的定义
      • 一致性哈希的空间是一个圆环，节点分布是基于圆环的
        • 没有办法很好的就是控制数据的分布
        • 圆环节点分布在圆环上，你节点比较少的时候，插入一个节点
        • 对临近的节点有影响，数据迁移就会比较多
        • 除非现在这个环上有上千个节点，在添加一个节点的时候，它的影响就非常非常小了
        • 所以它不适合少量数据节点的分布式方案
      • 而 Redis Cluster 槽位空间，它是可以自定义分配的
        • 就类似于像windows 盘符分区, 这种分区可以自定义大小，自定义位置
        • 就很好的可以去方便的管理，比如说我现在在D盘上右键扩展卷
        • 我就把D盘的一部分分出去变成一个E盘，对E盘还可以合并其他盘或删除E盘
        • 这样来回操作都没有什么问题，非常方便管理
• 注意，对于槽位的转移和分派，Redis集群是不会自动进行的，而是需要人工配置的
  • 所以，Redis集群的高可用是依赖于节点的主从复制和主从间的故障转移。
• Redis Cluster 它内部的哈希槽是 16384 个，通过 之前 check 检查的命令可以看出
  • 对于主节点的槽位的分配还是非常平均的
  • 这默认是Redis Cluster 自己去做的，当然我们人为的也可以去做这样的分配
  • 每个key 通过计算都会落在一个具体的槽位上，这个槽位，比如说属于哪个节点的
  • 然后这个我们自己在添加槽的时候，就可以自己来定义了
  • 比如说你的这个机器硬盘比较小，我们给它分配少一点
• 哈希槽的这种概念就很好的解决了一致性哈希的一个缺点，而且它在容错和扩展上也非常的方便
• 虽然说它表象跟一致性哈希一样，都是对受影响的数据进行转移
• 但哈希槽本质其实是对槽位的转移
  • 就是它会把故障的节点负责的这个槽位转到其他正常的节点上
  • 扩展节点也是一样的, 比如说我现在新加了一个节点
  • 我可以把其他节点上的槽再转移到这个新的节点上，就非常的方便，影响很低的
  • 因为它固定了聚集在这些槽的某一个节点

2 ) 16384 个 slots (槽位)

• Redis Cluster 没有单机那种 16个数据库 (0 - 15) 数据库的概念了，就是我们已经看不到数据库了

• 而是分成了 16384 个 slots (槽位) ，每个节点负责其中一部分槽位，槽位的信息存储于每个节点中

• 那我们客户端这边是怎么来操作集群的呢？

  • 当客户端连接集群的时候，首先它会得到一份集群的槽位配置信息
  • 然后把它缓存到客户端本地，这样客户端要查找某个key的时候，就可以直接定位到目标节点
  • 同时因为槽位的信息可能会存在客户端服务器不一致的情况
  • 那这个里边还会有纠错机制来实现槽位信息的一个调整
  • 客户端，随便找一台都能连上，对吧？都能连上，然后连上之后看到的效果都是一样的

3 ）槽位定位算法

• Redis Cluster 默认会对key值使用CRC16算法进行hash得到一个整数值
• 再把这个整数对 16384 取余，取完余以后会得到一个具体的槽位
• 这个就是槽位的计算公式： HASH_SLOT = CRC16(key) mod 16384
• 不管是 SET/GET 都是用这个方式
• 基于此，Redis Cluster 它提供了灵活的节点的扩容和缩容的方案
  • 而且可以在不影响集群对外提供服务的情况下，为我们的集群添加节点进行扩容
  • 也可以下线部分节点进行缩容
• 这里的槽其实就是 Redis Cluster 管理数据的基本单位
  • 集群的伸缩，其实就是咱们的槽和对应的数据在节点之间的移动
  • 对于这个槽位算法，简单的理解就扩容缩容之后槽需要重新分配，数据也需要重新迁移
  • 但是服务不需要下线，而且他对于数据和节点的影响非常的小
• 为什么是 16834 个槽，而不是别的数字呢？
  • https://github.com/redis/redis/issues/2576
  • 这里考虑心跳消息头的一个大小, 会达到 8k，过于庞大，比较占带宽
  • 还有就是关于节点，数量不可能到达1000的，16834 足够
  • 第三个就是就是槽位越小节点少的情况下压缩率越高
    • 哈希槽的存储是通过 bitmap 形式来进行保存的
    • 传输的过程中会对 bitmap 进行压缩
    • 如果哈希槽越多，压缩率就会很低，而 16834 / 8 约等于 2kb 这个压缩率会很高