最后附上前篇Blog链接Redis进阶之持久化机制及主从复制干货满满如有需要的小伙伴可点击查看哦~

Redis

另外主从模式薪火相传模式主机宕机导致ip地址发生变化应用程序中配置需要修改对应的主机地址、端口等信息。

之前通过代理主机来解决但是redis3.0中提供了解决方案。

就是无中心化集群配置。

1.2

集群实现了对Redis的水平扩容即启动N个redis节点将整个数据库分布存储在这N个节点中每个节点存储总数据的1/N。

Redis

集群通过分区partition来提供一定程度的可用性availability

1.3

制作6个实例6379,6380,6381,6389,6390,6391

1.4.1

修改好redis6379.conf文件拷贝多个redis.conf文件

使用查找替换修改另外5个文件

/usr/myredis/redis6391.conf1.4.4

将六个节点合成一个集群

192.168.136.172:6391此处不要用127.0.0.1

请用真实IP地址

1、可能直接进入读主机存储数据时会出现MOVED重定向操作。

所以应该以集群方式登录。

2、-c

分配原则尽量保证每个主数据库运行在不同的IP地址每个从库和主库不在一个IP地址上。

1.5

在redis-cli每次录入、查询键值redis都会计算出该key应该送往的插槽如果不是该客户端对应服务器的插槽redis会报错并告知应前往的redis实例地址和端口。

redis-cli

不在一个slot下的键值是不能使用mget,mset等多键操作。

可以通过{}来定义组的概念从而使key中{}内相同内容的键值对放到一个slot中去。

1.7

3、如果所有某一段插槽的主从节点都宕掉redis服务是否还能继续?

如果某一段插槽的主从都挂掉而cluster-require-full-coverage

为yes

如果某一段插槽的主从都挂掉而cluster-require-full-coverage

为no

existing_host:existing_port最后一个主节点的

redis-cli

74d466622c60f66710da4c3d1cc1e2a0d478add3查看节点情况添加节点成功

但没有分配槽数

host:port集群中随便一个节点的IP:PORT用于连接集群。

--cluster-from

node_id表示的是取出的槽添加给哪个节点也就是新添加的那个主节点

--cluster-slots

--cluster-yes不用再次确认分槽信息直接移动。

分配前

分配后

271edc34349164d7f8404b5211c8e374a2344e0d

--cluster-to

abd6ba38d0b05182f8a1044552c34a3a047a298f

--cluster-slots

271edc34349164d7f8404b5211c8e374a2344e0d

--cluster-to

abd6ba38d0b05182f8a1044552c34a3a047a298f

--cluster-slots

existing_host:existing_port所属主节点的IP和端口

--cluster-slave添加从节点

abd6ba38d0b05182f8a1044552c34a3a047a298f查看添加结果

1.10

无中心化主从集群。

无论从哪台主机写的数据其他主机上都能读到数据。

1.11

由于集群方案出现较晚很多公司已经采用了其他的集群方案而代理或者客户端分片的方案想要迁移至redis

Redis应用问题解决

缓存击穿redis中一个热点key过期大量用户访问该热点key但是热点key过期

2.1

key对应的数据在数据源种并不存在每次针对此key的请求从缓存获取不到请求都会压到数据源从而可能压垮数据源。

比如用一个不存在的用户id获取用户信息不论缓存还是数据库都没有若黑客利用此漏洞进行攻击可能压垮数据库。

2.1.2

获取的数据在数据库中也不存在数据库查询未得到对应数据Redis获取到null数据未进行持久化直接返回下次此类数据到达重复上述过程出现黑客攻击服务器

2.1.4

一个一定不存在缓存及查询不到的数据由于缓存是不命中时被动写的并且出于容错考虑如果从存储层查不到数据则不写入缓存这将导致这个不存在的数据每次请求都要到存储层去查询失去了缓存的意义。

解决方案

对查询结果为null的数据进行缓存长期使用定期清理设定短时限例如30-60秒最高5分钟

白名单策略

提前预热提前加载当加载正常数据时放行加载异常数据时直接拦截效率偏低使用布隆过滤器有关布隆过滤器的命中问题对当前状况可以忽略

实施监控

实时监控redis命中率业务正常范围时通常会有一个波动值与null数据的占比

非活动时段波动通常检测3-5倍超过5倍纳入重点排查对象活动时段波动通常检测10-50倍超过50倍纳入重点排查对象

key加密

问题出现后临时启动防灾业务key对key进行业务层传输加密服务设定校验程序过来的key校验

例如每天随机分配60个加密串挑选2到3个混淆到页面数据id中发现访问key不满足规则驳回数据访问

2.2

key对应的数据存在但在redis中过期此时若有大量并发请求过来这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存这个时候大并发的请求可能会瞬间把后端DB压垮。

2.2.2

Redis中某个key过期该key访问量巨大多个数据请求从服务器直接压到Redis后均未命中Redis在短时间内发起了大量对数据库中同一数据的访问

2.2.3

key可能会在某些时间点被超高并发地访问是一种非常“热点”的数据。

这个时候需要考虑一个问题缓存被“击穿”的问题。

解决问题

当某一个请求去数据库查询的时候同时在redis中将值设为null待他从数据库查到数据返回后设置具体的值预先设定

以电商为例每个商家根据店铺等级指定若干款主打商品在购物节期间加大此类信息key的过期时长

注意购物节不仅仅指当天以及后续若干天访问峰值呈现逐渐降低的趋势现场调整

监控访问量对自然流量激增的数据延长过期时间或设置为永久性key后台刷新数据

2.3

key对应的数据存在但在redis中过期此时若有大量并发请求过来这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存这个时候大并发的请求可能会瞬间把后端DB压垮。

缓存雪崩与缓存击穿的区别在于这里针对很多key缓存缓存击穿则是某一个key

2.3.2

此周期内请求访问过期的数据redis未命中redis向数据库获取数据

Redis大量请求被积压开始出现超时现象

用加锁或者队列的方式保证来保证不会有大量的线程对数据库一次性进行读写从而避免失效时大量的并发请求落到底层存储系统上。

不适用高并发情况

记录缓存数据是否过期设置提前量如果过期会触发通知另外的线程在后台去更新实际key的缓存。

将缓存失效时间分散开

比如我们可以在原有的失效时间基础上增加一个随机值比如1-5分钟随机这样每一个缓存的过期时间的重复率就会降低就很难引发集体失效的事件。