redis集群解决单点故障

落日映苍穹つ 2022-04-04 14:54 425阅读 0赞

Redis缓存的问题：

  1. 1.缓存穿透是指查询一个一定不存在的数据，由于缓存是不命中时被动写的，并且出于容错考虑，如果从存储层查不到
  2. 数据则不写入缓存，这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义。在流量大时，可
  3. 能DB就挂掉了，要是有人利用不存在的key频繁攻击我们的应用，这就是漏洞。
  5. 2.缓存雪崩是指在我们设置缓存时采用了相同的过期时间，导致缓存在某一时刻同时失效，请求全部转发到DB，DB瞬时
  6. 压力过重雪崩。
  8.    对于一些设置了过期时间的key，如果这些key可能会在某些时间点被超高并发地访问，是一种非常“热点”的数据。这个
  9. 时候，需要考虑一个问题：缓存被“击穿”的问题，这个和缓存雪崩的区别在于这里针对某一key缓存，前者则是很多key。

Redis缓存的限制：
内存限制 单点故障

Redis集群: 解决单点故障问题

  1. 设置主从
  2.         主机：master
  3.             不需要添加特殊配置   redis-server redis.conf
  4.         从机： slaver
  5.             slaveof 主机的地址  连接的端口号，例如slaveof 127.0.0.1 6379
  6.                 如果主从在同一个设备上，还需要注意端口号冲突问题，修改port为6380
  7.         哨兵：sentinel
  8.             sentinel是哨兵，用于监视主从服务器的运行状况，如果主
  9.         服务器挂掉，会在从服务器中选举一个作为主服务器        
  10.             port 26379
  11.             sentinel monitor mymaster 127.0.0.1 6379 2 指向主机    
  13.             启动哨兵   redis-server sentinel.conf --sentinel

在Springboot中的配置应用

  1. spring:
  2.   redis:
  3.     lettuce:      
  4.       pool:
  5.         max-active: 10
  6.         min-idle: 3
  7.         max-wait: 10000
  8.     sentinel:
  9.       nodes:
  10.       - 127.0.0.1:26379
  11.       - 127.0.0.1:26380
  12.       - 127.0.0.1:26381
  13.       master: mymaster

复制原理：

  1. 1、从数据库向主数据库发送sync命令
  2. 2、主数据库接收sync命令后，执行BGSAVE命令（保存快照），创建一个RDB文件，在创建RDB文件期间的命令将保存在
  3. 缓冲区中
  4. 3、当主数据库执行完BGSAVE时，会向从数据库发送RDB文件，而从数据库会接收并载入该文件
  5. 4、主数据库将缓冲区的所有写命令发给从服务器执行
  6. 5、以上处理完之后，之后主数据库每执行一个写命令，都会将被执行的写命令发送给从数据库

Redis分片：解决内存不足问题
Redis 的分片承担着两个主要目标：

  1. 1.允许使用很多电脑的内存总和来支持更大的数据库。没有分片，你就被局限于单机能支持的内存容量
  2. 2.允许伸缩计算能力到多核或多服务器，伸缩网络带宽到多服务器或多网络适配器
  4. 范围分片的替代方案是哈希分片(hash partitioning)。这种模式适用于任何键
  5.     哈希槽设置
  6.         key-->hashcode-->16384

Redis持久化存储的方案
1、RDB：Redis Database，就是快照snapshots。缺省情况情况下，Redis把数据快照存放在磁盘上的二进制文件中，文件名为dump.rdb。可以配置Redis的持久化策略，例如数据集中每N秒钟有超过M次更新，就将数据写入磁盘；或者你可以手工调用命令SAVE或BGSAVE。
　　工作原理

  1. Redis是使用fork函数复制一份当前进程(父进程)的副本(子进程)
  2.         子进程开始将数据写到临时RDB文件中
  3.         当子进程完成写RDB文件，用新文件替换老文件
  4.         这种方式可以使Redis使用copy-on-write技术。

2、AOF：Append Only File。快照模式并不十分健壮，当系统停止或者无意中Redis被kill掉，最后写入Redis的数据就会丢失。这对某些应用也许不是大问题，但对于要求高可靠性的应用来说，Redis就不是一个合适的选择。Append-only文件模式是另一种选择。可以在配置文件中打开AOF模式
Redis中提供了3中同步策略，即每秒同步、每修改同步和不同步。事实上每秒同步也是异步完成的，其效率也是非常高的，所差的是一旦系统出现宕机现象，那么这一秒钟之内修改的数据将会丢失。

3、虚拟内存方式。当key很小而value很大时，使用VM的效果会比较好，因为这样节约的内存比较大。当key不小时可以考虑使用一些非常方法将很大的key变成很大的value，如可以考虑将key/value组合成一个新value.
vm-max-threads这个参数,可以设置访问swap文件的线程数,设置最好不要超过机器的核数,如果设置为0,那么所有对swap文件的操作都是串行的.可能会造成比较长时间的延迟,但是对数据完整性有很好的保证.用虚拟内存性能也不错。如果数据量很大，可以考虑分布式或者其他数据库

redis.windows.conf
daemonize no默认情况下redis不是作为守护进程运行的，如果想让它在后台运行，就把它改成yes。当redis作为守护进程运行的时候，它会写一个pid到/var/run/redis.pid文件里面

  1. port 6379监听端口号，默认为6379，如果设为0，redis将不在socket上监听任何客户端连接。
  3.    tcp-backlog 511设置TCP监听的最大容纳数量。在高并发的环境下，需要把这个值调高以避免客户端连接缓慢的问
  4. 题。Linux内核会把这个值缩小成/proc/sys/net/core/somaxconn对应的值，所以要修改这两个值才能达到你的预期。
  6.    bind 192.168.1.100 10.0.0.1默认情况下，redis在server上所有有效的网络接口上监听客户端连接。如果只
  7. 想让它在一个网络接口上监听，那就绑定一个IP或者多个IP。多个IP用空格隔开
  9.    timeout 0指定在一个client空闲多少秒之后关闭连接（0就是不管它）
  11.    loglevel notice定义日志级别。可以是：debug适用于开发或测试阶段、verbose类似debug信息但是内容更少
  12. 些、notice适用于生产环境、warning仅仅一些重要的消息被记录
  14. 将redis安装为服务的命令
  15.     redis-server --service-install redis.windows-service.conf --loglevel verbose
  17. 启动服务
  18.     net start Redis

redis持久化机制：
snapshot—RDB
对应的快照文件为dump.rdb

  1. save 900 1在900秒(15分钟)之后，如果至少有1个key发生变化，则dump内存快照
  2.         save 300 10在300秒(5分钟)之后，如果至少有10个key发生变化，则dump内存快照
  3.         save 60 1000在60秒(1分钟)之后，如果至少有10000个key发生变化，则dump内存快照
  4. 分别表示900秒（15分钟）内有1个更改，300秒（5分钟）内有10个更改以及60秒内有10000个更改。
  6. AOF
  7.     appendfsync always每次有数据修改发生时都会写入AOF文件
  8.     appendfsync everysec 每秒钟同步一次，该策略为AOF的缺省策略。在性能和持久化方面作了很好的折中
  9.     appendfsync no从不同步。高效但是数据不会被持久化。
  11. 持久化机制建议：
  12.     更新频繁，一致性要求比较高，AOF策略为主
  13.     更新不频繁，可以容忍少量数据丢失或错误，snapshot策略为主

Redis事务
redis事务是通过MULTI，EXEC，DISCARD和WATCH四个原语实现的。

  1. MULTI命令用于开启一个事务，它总是返回OK。
  2.         MULTI执行之后，客户端可以继续向服务器发送任意多条命令，这些命令不会立即被执行，而是被放到一个队列中，当EXEC命令被调用时，所有队列中的命令才会被执行。
  3.         另一方面，通过调用DISCARD，客户端可以清空事务队列，并放弃执行事务。
  5. redis事务范围
  6.     从multi命令开始，到exec或者discard为止，整个操作过程是原子性的，不能打乱顺序，也不能插入操作
  7.     但是出错之前的操作会正常提交
  9. WATCH 命令可以为 Redis 事务提供 check-and-set （CAS）行为。                    
  10.     被 WATCH 的键会被监视，并会发觉这些键是否被改动过了。 如果有至少一个被监视的键在 EXEC 执行之前
  11. 被修改了， 那么整个事务都会被取消， EXEC 返回空多条批量回复（null multi-bulk reply）来表示事务已
  12. 经失败。

使用Redis实现分布式锁：
申请加锁操作：

  1. 1、向Redis中存放固定key的值，如果key不存在则实现存放并获取锁；如果key已经存在则不能获取锁
  2.             （依靠Redis中的原子操作进行CAS比对，实现锁的互斥）
  3. 2、获取key所对应的时间，时间是锁预期的实效时间，如果已经实效，则存储新值，并获取锁
  4. 3、否则获取锁失败
  6. 解锁：
  7.     删除指定key的redis列

抢购、秒杀是如今很常见的一个应用场景，主要需要解决的问题有两个：

  1. 1、高并发对数据库产生的压力
  2. 2、竞争状态下如何解决库存的正确减少（"超卖"问题）

对于第一个问题，已经很容易想到用缓存来处理抢购，避免直接操作数据库，例如使用Redis。

Redis使用watch完成秒杀抢购功能：
使用redis中两个key完成秒杀抢购功能，mywatchkey用于存储抢购数量和mywatchlist用户存储抢购列表。

  1. 优点：
  2.     1、首先选用内存数据库来抢购速度极快
  3.     2、速度快并发自然没不是问题
  4.     3、使用悲观锁，会迅速增加系统资源
  5.     4、比队列强的多，队列会使内存数据库资源瞬间爆棚
  6.     5、使用乐观锁，达到综合需求

发表评论

表情：
评论列表 （有 0 条评论，425人围观）

还没有评论，来说两句吧...

相关阅读

    相关 Redis集群中故障恢复

    Redis集群中故障恢复 问题1：如果主节点下线？从节点能否自动升为主节点？ 答：主节点下线，从节点自动升为主节点。 ![在这里插入图片描述][2021012622

    桃扇骨桃扇骨/ 0 赞/ 277 阅读