redis集群解决单点故障

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

Redis缓存的问题：

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

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

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

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

**在Springboot中的配置应用**

spring:
      redis:
        lettuce:      
          pool:
            max-active: 10
            min-idle: 3
            max-wait: 10000
        sentinel:
          nodes:
          - 127.0.0.1:26379
          - 127.0.0.1:26380
          - 127.0.0.1:26381
          master: mymaster

复制原理：

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

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

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

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

Redis是使用fork函数复制一份当前进程(父进程)的副本(子进程)
    		子进程开始将数据写到临时RDB文件中
    		当子进程完成写RDB文件，用新文件替换老文件
    		这种方式可以使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文件里面

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

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

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

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

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

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

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

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

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

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

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

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