Redis为什么能够支持如此高的并发呢?

  1. 纯内存访问

    将所有数据都放到内存中,内存响应时间为100纳秒,是redis达到每秒万级别访问的重要基础。

  2. 非阻塞IO

    redis使用epoll作为I/O多路复用技术,redis自身的事件处理模型将epoll中的连接、读写、关闭都转换为事件,不在网络I/O上浪费过多时间。

  3. 单线程

    避免了线程切换和竞态产生的消耗,简化了数据结构和算法的实现。

怎么应对阻塞问题?

因为redis是单线程模型,如果某个命令执行时间过长,会造成其他命令阻塞,对redis来说是致命的。

产出阻塞的场景举例

API或数据结构使用不合理

解决方案:

a. 避免使用某些易造成阻塞的命令如:keys sort hgetall smembers 执行showlog get [n] 可以获取最近n条执行慢的记录,对于执行超过一定时间 (默认10ms,线上建议设置为1ms)的命令都会记录到一个定长队列(默认128,可调整)中。
b. 防止一次操作获取过多数据:缩减大对象或者把大对象拆分为多个小对象 发现大对象的命令:redis-cli -h{ip} -p{port} bigkeys 内部原理:采用分段进行scan操作,把历史扫描过的大对象统计出来 c. 防止大量key同时过期:如果有很多key在同一秒内过期,超过了所有key的25%,redis主线程就会阻塞直到过期key比例下降到25%以内, 因此要避免同一时间过期大量key,过期时间可做散列处理。 redis4.0引入的lazyfree机制可以避免del、flushdb、flushall、rename等命令引起的redis-server阻塞,提高服务稳定性

CPU饱和

单线程的redis处理命令时只能使用一个CPU,CPU饱和是指redis把单核的CPU使用率跑到接近100%。

解决方案:

首先要确定redis的并发量是否达到极限,通过redis-cli-h{ip} -p{port}–stat 获取redis当前使用情况。 如果达到每秒6w+左右的qps,说明单台已跑到极限,需要水平扩展。 如果qps只有几百或者几千CPU就已经饱和,可能使用了高算法复杂度的命令或者是对内存的过度优化 (如放宽了ziplist的使用条件,虽然使用的内存会变少,但是更耗CPU)。

持久化操作

持久化引起主线程的阻塞操作主要有:fork阻塞、AOF刷盘阻塞、HugePage写操作阻塞

a. fork阻塞 发生在RDB和AOF重写时,redis主线程调用fork操作产生共享内存的子线程,由子线程完成持久化文件的重写工作,若fork操作耗时过长会引起阻塞。 避免使用内存过大的实例。
b. AOF刷盘阻塞 开启AOF持久化功能时,一般会采用1次/s的刷盘方式,后台线程每秒对AOF文件做fsync操作,当硬盘压力过大时fsync操作需要等待直到写入完成。 如果主线程距离上一次的fsync成功超过2s,为了数据安全会阻塞直到后台线程执行完fsync完成。这种阻塞是由于磁盘压力引起。 尽量独立部署 c. HugePage写操作阻塞 子进程在执行重写期间利用linux的copyonwrite机制,会拖慢写操作的执行时间,导致大量写操作慢查询。 优化linux配置

什么是内存穿透?

缓存穿透是指查询一个根本不存在的数据,缓存层和存储层都不命中,且不将空结果写到缓存中。 会导致后端存储负载变大,造成后端存储宕机等问题。可以在程序中分别统计总调用数、缓存命中数、存储命中数,若有大量存储层空命中,可能是出现了缓存穿透。

产生原因:1.自身代码或数据出现问题 2.恶意攻击,爬虫造成空命中

如何解决:

  1. 缓存空对象 存储层不命中,扔将空对象保存到缓存层。 适用场景:数据频繁变化、实时性高 带来问题: a.缓存了空值,会占用内存空间;可以设置较短过期时间,自动剔除。 b.数据不一致,若存储层添加了此数据,有短暂不一致;可主动清除掉缓存的空对象。
  2. 布隆过滤器 在访问缓存层和数据层之前将存在的key用布隆过滤器提前保存起来,做第一层拦截。 适用场景:大用户集,实时性要求较低的场景,如有几亿的数据集,每隔一段时间会新增用户进去,在更新之前新用户的访问会存在缓存穿透问题。 缺点:代码维护复杂

无底洞问题

随着数据量和访问量的增长,需要增加更多的节点做水平扩容,键值会分布到更多的节点上,若客户端进行批量操作则通常会从不同的节点上获取数据,相比于单机批量操作只涉及一次网络操作,分布式批量操作会涉及多次网络交互。 随着节点数的增多,客户端一次批量操作涉及的网络交互耗时也会不断增大;网络连接数增多,对节点性能也有一定影响。 更多的节点不代表更高的性能,这就是无底洞问题。

雪崩问题

由于缓存层承载着大量请求,有效的保护了存储层,但如果缓存层由于某些原因不能提供服务,所有请求都会压到存储层,存储层流量暴增,导致存储层也会级联宕机。

解决方案

  1. 保证缓存层服务高可用性 Redis Sentinel或者Redis Cluster都实现了高可用
  2. 隔离限流降级 对重要的资源Redis、Mysql、外部接口调用都进行隔离,机器、进程、线程等层面都可做隔离。 可使用漏桶、令牌桶等方式进行限流操作,将流量挡在应用上层。 对出现问题的数据或功能做降级处理,友好的展示给用户。
  3. 提前演练测试

热点key重建优化

缓存+过期时间策略即可以加速数据读写,又保证数据的定期更新,若出现如下两个问题,可能会对应用产生致命危害:

  1. 当前key是一个热点key,并发量非常大
  2. 重建缓存不能在短时间内完成,如:复杂的sql、多次IO、多个依赖等。 在缓存失效的瞬间,有大量的线程来创建缓存,造成后端负载加大,甚至导致系统崩溃。

解决方案:

  • 互斥锁

    只允许有一个线程去重建数据,其他线程等待构建完缓存,重新从缓存中获取数据。

    该方案思路简单,能保证一致性;但代码复杂度增大,存在死锁风险,存在线程池阻塞风险。

  • 永远不过期

    设置逻辑过期时间,判断逻辑时间和当前时间大小,然后异步去构建数据覆盖老数据。

    该方案基本可以杜绝热点key问题;但不保证一致性,逻辑过期时间增加代码维护成本

参考

https://segmentfault.com/a/1190000014262882

https://segmentfault.com/a/1190000014440285

https://segmentfault.com/a/1190000020155561