redis主存,哨兵,集群的应用(生产环境可用)
启动
* redis的数据类型:
* 本质上是key-value的数据结构.而这个value分为:
* String :单值和多值
* hash :
* set
* zset
* list
* 核心: 具有业务标示的key.过期策略指的是key的过期,key过期,key对应的值就会失效(如分布式锁中,超时时间指的是key的失效时间
* 而非value的失效时间)
* 设计key:设计成为 具有业务标示的key;
* 用redis去实现功能.减少磁盘IO
*https://blog.csdn.net/weixin_33905756/article/details/94532850
* 社交app中用到的
* 1.set : 交集,并集,差集(以第一个为基准-(第二个和第三个的并集){过滤掉相同的远元素,剩余的是第一个的元素就是需要的数据}})
* 2.微信抽奖的应用,点赞的程序
* 3.放开数据库去做操作;
* 4.常用的api,减少数据库的查询
* zset:排行榜的热搜应用;
*
* 2.redis为什么快?
* 1.基于内存操作
* 2.单线程操作,避免了多线程的上下文操作;
* 3.为什么支持高并发?用到了io多路复用的技术
*3.持久化:
* 为了防止redis基于内存操作,当redis挂了之后,进行数据的保存,防止当redis重启时发生缓存雪崩或者缓存缓存穿透
* 两种:
* rdb: 生成策略 自动
* save 900 1 //900 时间 1 次数 set命令 900s时间改动了1次,会生成一次二进制的快照
* save 300 10
* save 60 10000
* 手动:
* bgsave
* save
* aof:
* 指令级别:每执行一次就持久化到内存
* appendfsync always 每执行一条命令,会直接到磁盘,对数据是安全的,对性能不好
* appendfsync everysec 写到缓存里,当到达1s了,会直接持久化到磁盘,会丢失数据
* appendfsync no 由操作系统决定,数据不安全
* 三个命令之间是或的关系
* 缓存的主要功能是:抗并发,大的流量直接在redis返回,而不去操作数据库
* 恢复数据:
* rdb :二进制命令,恢复速度快
* aof:一条指令指令的恢复,恢复速度慢
* 手动:
* bgrewriteaof
* 默认情况下:会优先选用aof恢复数据,因为aof的数据完整性比较好
* 混合持久化:
* rdb 和aof的结合:
* aof-use-rdb-preamble yes # 开启混合持久化
* 注意:写到aof文件中
* 主存复制原理:
* 防止数据丢失;
* 1.主存架构:
* 没有选举的,master和slave之间不能自动切换;一主两存;手动的去修改
* 数据复制: 全量同步: slave --->psyne --->master bgsave 生成rdb命令 ----->slave
* 增量同步: 缓存区=---->buffer -->
* 二者合并:关键点是bgsave
* 存在一个偏移量:
* 2.哨兵架构:
* 主存架构的高级版.
* java 连接的是哨兵.通过哨兵去获取java
* 解决的是:主存之间的切换,当主节点挂了之后,哨兵会从slave节点中选举为master节点,
* 哨兵去监听每一台redis(master+slave)
* 高可用架构
* 配置注意以下两点:
* 1.必须保证主存架构中配置好主存节点的关系
* 2.哨兵中配置相应的redis的主节点
* 存在的问题:
* 1. qps 只有一个节点提供写服务
* 2.访问瞬断
* 设置内存:
* redis单节点设置的内存是:4g,不建议设置过大:
* 1.数据主存同步很慢
* 2.重启之后,持久化的数据加载很慢
* 集群:
* 主存结构构成了redis集群,那么数据是怎么保存的?
* 1.数据切片保存. 1)分片存储: 对key进行hash,进行路由,数据独立存储,不会重复,存在于其中的一个主存的主节点上,
* 分片只是在主节点,存节点只是数据备份的.
* 分片原理:
* JedisClusterCRC16.getCRC16("zhoujian"); -->源码底层的可以直接取出来用
* redis官方测试,水平扩展不要超过1000个节点,否则影响性能;
* 2.一个节点是10万的qps,
* 3.访问瞬断的问题:并没有彻底的解决掉,
* 搭建集群的关键点:
* 1.cluster-enabled yes
* 2.cluster-config-file nodes-8001.conf
* 3. cluster-node-timeout 5000 #网络抖动
* 启动集群:
* 4.../java/redis-5.0.3/src/redis-cli --cluster create --cluster-replicas 1 192.168.0.88:8001 192.168.0.88:8002 192.168.0.88:8003 192.168.0.88:8004 192.168.0.88:8005 192.168.0.88:8006
* 自动分配节点:实现主存节点以及集群搭建
* 5.../java/redis-5.0.3/src/redis-cli -c -h 192.168.0.88 -p 8001 集群信息 cluster info
* 6.节点信息 :cluster nodes
* 7.节点动态扩容:
* ../java/redis-5.0.3/src/redis-cli --cluster add-node 192.168.0.88:8007 192.168.0.88:8001
* 分配slot
* ../java/redis-5.0.3/src/redis-cli --cluster reshard 192.168.0.88:8001 (任意一个存在的主节点)
* 节点的Id :作为迁移的标准
* 8.把其中的一个节点作为另外一个节点的存节点
* cluster replicate 7184228905566dc56e24acc3aca3ff6ec70ac85b (主节点的ID)
* 缩容:
* 9.删除节点(slave)
* ../java/redis-5.0.3/src/redis-cli --cluster del-node 192.168.0.88:8008 9ed6c99d9a9dd0c8d618b2f2d8605f4960f9dbde
* 10.删除主节点;
* 1.首先恢复slot槽位,然后在移除节点,不然会有数据的丢失
* 2.删除节点
* 节点挂掉之后会自动选举为master,是一个虚拟的hash曹,只是给主节点
* 节点之间的通信机制:gossip协议 : ping pong
* 通信的端口是:redis的节点的端口加1 比如:8001 --->100081
* 选举原理:
* slave ->master
* 每一个节点之间是可以相互通信的.fail
* 选举原理:超过半数以上的节点通信,则为主节点 gossip
* 为什么需要奇数?
* 多个master就是为了达到高可用,节约机器,比如3和4个机器,挂掉两个,根据半数的选举原理,二者都是无法参与选举的;
* 核心就是:半数以上的选举原理.
作者：航海到IT的转变,梦想一直在路上
相关文章
Winona
2023-07-20
Lillian
2023-07-20
Rochelle
2023-07-20
Wanda
2023-07-20
Ophelia
2023-07-20
Rayna
2023-07-20
Agnes
2023-07-20
Rhea
2023-07-20
Hazel
2023-07-20
Habiba
2023-07-20
Kamiisa
2023-07-20
Bianca
2023-07-20
Nafisa
2023-07-21
Irene
2023-07-21
Winola
2023-07-21
Madge
2023-07-21