Redis高可用集群实战:
map:JVM堆栈
redis:物理内存
之前的5种数据格式(String /hash/ list/ set/ sorted set(Zset)) + 地理位置信息查询等新的数据格式
范围查询:bitmap
地理空间:geospatial 索引半径查询
高级特性:
单副本:1个Redis服务端
多副本:主从模式
高可用:哨兵Sentinel、集群Cluster
没有太多的,做缓存使用
新浪微博:使用Redis量很高。点赞和评论很重要,只要不是大量的丢失就能够接受。
限制Redis性能:CPU、网络
单点故障:缓存击穿和缓存雪崩。
解决方法:数据备份。备份多少合理?比较安全的备份3份。主也算1+2=3.
2n+1=
拜占庭问题:实现最少资源的公平选举, 故障数据<存活的节点数据
选举的机制:2n+1.
多副本:
主主不支持备份,
解决方案:将从服务器在主挂掉之后,提升成主服务。(本身不能主动支持,要手动将从----变成主服务)
微博之前发生这种问题,临时性手动解决这种问题。
-------自动?
哨兵模式解决这种问题:
可靠性要求高的场景:分布式锁、
常见架构:
哨兵方式:
toC大多数是读多写少的场景。不能够写多。
主挂掉:立即进行选举。TCP/ip心跳实现检查。
服务直接连接哨兵的端口,
1、不用直接连接主Redis节点。
2、哨兵会帮服务找到主节点,并将该节点返回给服务端
3、服务端知道ip+端口
4、对主节点进行连接
哨兵能够监控多套数据集群。
哨兵模式的搭建:
Docker实现 ,
哨兵要进行选举。
redis查看当前节点的身份命令:info replication(把之前的主关机)
将之前的主进行开启,之后再进行开启,,这时的身份为从节点。
主从身份由哨兵进行管理,会竞争权限,当重新上线时如果有两台从节点,1<2 之前的节点会继续选举成为主节点,本例中的只有一台从节点,选举不会成功,。
集群方式:
进行改进,水平拓展,会修改很多的配置文件,slave数量从新进行改写。
如果不多的redis数据集群都挂掉,整个服务变得不可用。
同时,Redis占用的内存量很大,主写入1G的内存,从也会写入1G的内存数据,整个系统就会占用3G的内存(1主2从)
基于上述3种情况,这里使用集群分布的方式实现部署。
JedisCluster
1G的数据,key 根据hash槽 (0-16383个槽节点redi实例)下图1-6个槽,进行hash运算之后,得到1,之后只会将1G的数据写到对应的槽当中去,减少内存资源的损耗。(之前是1G* N个节点)
拓展,很容易实现。
通过JedisCluster进行读取数据,key(找到hash槽)----拿到数据
client不会到相应的master进行数据的拿取。
大型互联网公司的使用:
来源:CSDN
作者:qq_29235677
链接:https://blog.csdn.net/qq_29235677/article/details/103593028