当前位置： 首页 > news >正文

描述网站建设的基本流程,早期网页游戏,北京西站地铁是几号线,三项措施做好门户网站建设集群测试 1 ) SET/GET 命令 测试 set 和 get 因为其他命令也基本相似#xff0c;我们在 101 节点上尝试连接 103 \( /usr/local/redis/bin/redis-cli -c -a 123456 -h 192.168.10.103 -p 6376我们在插入或读取一个 key的时候#xff0c;会对这个key做一个hash运算#xff0c…集群测试 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 zhangsanusername 这个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值的数据大小-k1keep alive 0reconnect-rSET/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 10003 ) 集群测试

随机set/get1000000条命令1000个并发

bin/redis-benchmark -a 123456 -h 192.168.10.101 -p 6371 -t set, get -r 1000000 -n 1000000 -c 10004 ) 对比结果 综合上述单机和集群跑出来的数据结果单机要更快 集群原理 我们之前用到的单机主从哨兵这几种模式数据都是存在单个节点上 如果说是主从的话会有从节点从节点也只是对主节点的数据进行复制而我们单个节点它存储是有上限的而且我们说它还有写压力等 集群其实就是把请求包括数据的存储都分在了不同的节点上就是把数据进行了分片存储 当一个分片的数量达到上限的时候还可以给它分成多个分片
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 这个压缩率会很高