redis06

Posted 2022-08-02 quyangyang

缓存的使用与设计

 

1.受益

加速读写
CPU L1/L2/L3 Cache、浏览器缓存、Ehcache缓存数据库结果
降低后端负载
后端服务器通过前端缓存降低负载：业务端使用Redis降低后端mysql的负载

 

2.成本

数据不一致：缓存层和数据层有时间窗口不一致问题，和更新策略有关
代码维护成本：多了一层缓存逻辑
运维成本：例如Redis Cluster

 

3.使用场景

降低后端负载
对高消耗的SQL：join结果集/分组统计结果缓存
加速请求响应
利用Redis/Memcache优化IO响应时间
大量写合并为批量写
入计数器先Redis累加再批量写DB

 

缓存的更新策略

 

LRU等算法剔除：例如 maxmemory-policy

 

2.超时剔除：例如expire

3.主动更新：开发控制生命周期

4.两条建议
低一致性数据：最大内存和淘汰策略
高一致性：超时剔除和主动更新结合，最大内存和淘汰策略兜底

 

缓存粒度问题

通用性：全量属性更好
占用空间：部分属性更好
代码维护：表面上全量属性更好

 

 

 

缓存穿透优化

查询一个不存在的数据，由于缓存是不命中时需要从数据库查询，查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到数据库去查询

产生原因
业务代码自身问题
恶意攻击、爬虫
发现问题
业务的响应时间，受到恶意攻击时，普遍请求被打到存储层，必会引起响应时间提高，可通过监控发现

业务本身问题
相关指标：总调用数、缓存层命中数、存储层命中数

解决方法1：缓存空对象（设置过期时间）

当存储层查询不到数据后，往cache层中存储一个null，后期再被查询时，可以通过cache返回null。
缺点
cache层需要存储更多的key
缓存层和数据层数据“短期”不一致

 1 public String getPassThrough(String key) 
 2     String cacheValue = cache.get(key);
 3     if( StringUtils.isEmpty(cacheValue) ) 
 4         String storageValue = storage.get(key);
 5         cache.set(key , storageValue);
 6         if( StringUtils.isEmpty(storageValue) ) 
 7             cache.expire(key , 60 * 5 );
 8          
 9         return storageValue;
10      else 
11         return cacheValue;
12     
13 

 

 

解决方法2：布隆过滤器拦截（适合固定的数据）

将所有可能存在的数据哈希到一个足够大的bitmap中，一个不存在的数据会被这个bitmap拦截掉，从而避免了对底层存储系统的查询压力

 

 

 

缓存雪崩优化

 

由于cache服务器承载大量的请求，当cache服务异常脱机，流量直接压向后端组件，造成级联故障。或者缓存集中在一段时间内失效，发生大量的缓存穿透

解决方法1：保证缓存高可用性

做到缓存多节点、多机器、甚至多机房。
Redis Cluster、Redis Sentinel
做二级缓存

解决方法2：依赖隔离组件为后端限流

使用Hystrix做服务降级

解决方法3：提前演练（压力测试）

解决方法4：对不同的key随机设置过期时间

 

 

无底洞问题

 

添加机器时，客户端的性能不但没提升，反而下降
关键点
更多的机器 != 更高的性能
更多的机器 = 数据增长与水平扩展
批量接口需求：一次mget随着机器增多，网络节点访问次数更多。网络节点的时间复杂度由O(1) -> O(node)

优化IO的方法
命令本身优化：减少慢查询命令：keys、hgetall、查询bigKey并进行优化
减少网络通信次数
mget由O(keys)，升级为O(node)，O(max_slow(node)) , 甚至是O(1)
降低接入成本：例如客户端长连接/连接池、NIO等

 

 

热点Key的重建优化

 

热点Key（访问量比较大） + 较长的重建时间（重建过程中的API或者接口比较费时间）
导致的问题：有大量的线程会去查询数据源并重建缓存，对存储层造成了巨大的压力，响应时间会变得很慢

 

 

1.三个目标

减少重建缓存的次数
数据尽可能一致
减少潜在危险：例如死锁、线程池大量被hang住（悬挂）

 

2.两种解决方案

互斥锁（分布式锁）
第一个线程需要重建时候，对这个Key的重建加入分布式锁，重建完成后进行解锁
这个方法避免了大量的缓存重建与存储层的压力，但是还是会有大量线程的阻塞

jedis.set(lockKey, requestId, SET_IF_NOT_EXIST, SET_WITH_EXPIRE_TIME, expireTime)

String get(String key) 
    String SET_IF_NOT_EXIST = "NX";
    String SET_WITH_EXPIRE_TIME = "PX";
    
    String value = jedis.get(key);
    if( null == value ) 
        String lockKey = "lockKey:" + key;
        if( "OK".equals(jedis.set(lockKey , "1" , SET_IF_NOT_EXIST , 
                      SET_WITH_EXPIRE_TIME , 180)) ) 
            value = db.get(key);
            jedis.set(key , value);
            jedis.delete(lockKey);
         else 
            Thread.sleep(50);
            get(key);
        
    
    return value;

 

永远不过期

缓存层面：不设置过期时间（不使用expire）
功能层面：为每个value添加逻辑过期时间，单发现超过逻辑过期时间后，会使用单独的线程去重建缓存。
还存在一个数据不一致的情况。可以将逻辑过期时间相对实际过期时间相对减小

 

 

Redis规模化的困扰

发布构建繁琐，私搭乱盖
节点&机器等运维成本
监控报警比较低级

 

 

CacheCloud的主要功能

一键开启Redis（单点、Sentinel、Cluster）
机器、应用、实例监控和报警
客户端：透明使用、性能上报
可视化运维：配置、扩容、Failover、机器/应用/实例上下线
已存在Redis直接移入和数据迁移

 

 

布隆过滤器引出

问题引出：现有50亿个电话号码，有10万个电话号码，要快速准确判断这些电话号码是否已经存在
1. 通过数据库查询：实现快速有点难
2. 数据预先放在内存集合中：50亿 * 8字节 = 40GB（***内存***浪费或不够）
3. hyperloglog：准确有点难

 

 

布隆过滤器原理

需要参数
m个二进制向量（m个二进制位数）
n个预备数据（类似于问题中的50亿个电话号码）
k个hash函数（每个数据，逐个进行hash，将指定向量标识为1）
构建布隆过滤器
将n个数据逐个走一遍hash流程
判断元素是否存在
将元素逐个hash进行执行
如果得到的hash结果再向量中全都是1，则表明存在，反之当前元素不存在

 

 

布隆过滤器误差率

对的数据的返回结果必然是对的，但是错误的数据也可能是对的
直观因素
m / n 的比例：比例越大，误差率越小
hash函数的个数：个数越多，误差率越小

本地布隆过滤器

实现类库：Guava

 1 Funnel<Integer> funnel = Funnels.integerFunnel();
 2 int size = 1000_000;
 3 double errorChance = 0.001;        //错误率
 4 BloomFilter<Integer> filter = BloomFilter.create(funnel , size , errorChance);
 5 for(int i = 0 ; i < size ; i++ ) 
 6     filter.put(i);
 7 
 8 for(int i = 0 ; i < size ; i++ ) 
 9     if( !filter.mightContain(i) ) 
10         System.out.println("发现不存在的数据 : " + i);
11     
12 

 

布隆过滤器的问题

容量受到限制
多个应用存在多个布隆过滤器，构建同步过滤器复杂

 

 

Redis单机布隆过滤器

基于bitmap实现，利用setbit、getbit命令实现
hash函数：
MD5
murmur3_128
murmur3_32
sha1
sha256
sha512
基于Redis单机实现存在的问题
速度慢：与本机比，输在网络
解决方法1：单独部署、与应用同机房甚至同机架部署
解决方法2：使用pipeline
容量限制：Redis最大字符串为512MB、Redis单机容量
解决方法：基于RedisCluster实现

 

Redis Cluster实现布隆过滤器

多个布隆过滤器：二次路由
基于pipeline提高效率

 

 

内存管理

 

Redis内存消耗

内存使用统计

info memory

 

 

 2.内存消耗划分

used_memory的组成部分
自身内存（800K左右）
缓冲内存
客户端缓冲区
复制缓冲区
AOF缓冲区
对象内存
Key对象
Value对象
Lua内存
内存碎片 = used_memory_rss - used_memory（申请内存的会超过使用内存，内存预留与内存暂未释放）

 

3.子进程内存消耗

 

redis在bgsave与bgrewriteaof时候都会使用fork创建出子进程，fork是copy-on-write的，当发生写操作时，就会复制出一份内存
优化方式
去除THP特性：在kernel 2.6.38中新增的特性。这个特性可以加快fork的速度，但是在复制内存页的时候，会比原来的内存页扩大了512倍。例如原来是4K，扩大后为2M。当写入量比较大时，会造成不必要的阻塞与内存的暴增。
overcommit_memory=1 可以保证fork顺利完成

 

 

 

客户端缓冲区

 #查看已连接客户端的基本信息

info clients

 

 

#查看所有Redis-Server的所有客户端的详细信息
client list

 

 

输入缓冲区

各个客户端执行的Redis命令会存储在Redis的输入缓冲区中，由单线程排队执行
- 注意：输入缓冲区最大1GB，超过后会被强制断开，不可动态配置

 

输出缓冲区

1 client-output-buffer-limit $class $hard limit $soft limit $soft seconds
2 ## class 客户端类型
3 ##        normal        普通客户端
4 ##        slave        从节点用于复制，伪装成客户端
5 ##        pubsub        发布订阅客户端
6 ## hardLimit 如果客户端使用的输出缓冲区大于hardLimit，客户端会被立即关闭
7 ## softLimit 如果客户端使用的输出缓冲区超过了softLimit并且持续了softSeconds秒，客户端会立即关闭
8 ## 其中hardLimit与softLimit为0时不做任何限制

 

 

1.普通客户端

默认配置：client-output-buffer-limit normal 0 0 0
注意：需要防止大命令或者monitor，这两种情况会导致输出缓冲区暴增

2.slave客户端

默认配置：client-output-buffer-limit slave 256mb 64mb 60
建议调大：可能主从延迟较高，或者从节点数量过多时，主从复制容易发生阻塞，缓冲区会快速打满。最终导致全量复制
注意：在主从网络中，从节点不要超过2个

3.pubsub客户端

默认配置：client-output-buffer-limit pubsub 32mb 8mb 60
阻塞原因：生产速度大于消费速度
注意：需要根据实际情况进行调试

 

 

缓冲内存

 

1.复制缓冲区

此部分内存独享，默认1MB，考虑部分复制，可以设置更大，可以设置为100MB，牺牲部分内存避免全量复制。

2.AOF缓冲区

无论使用always、everysecs还是no的策略，都会进行刷盘，刷盘前的数据存放在AOF缓冲区中。

另外在AOF重写期间，会分配一块AOF重写缓冲区，重写时的写数据会存放在重写缓冲区当中。

为了避免数据不一致的发生，在重写完成后，会将AOF重写缓冲区的内容，同步到AOF缓冲区中。

AOF相关的缓冲区没有容量限制。

 

 

对象内存

Key：不要过长，量大不容忽视，建议控制在39字节之内。（embstr）
Value：尽量控制其内部编码为压缩编码。
内存碎片
在jemalloc中必然存在内存碎片
原因
与jemalloc有关，jemalloc会将内存空间划分为小、大、巨大三个范围；每个范围又划分了许多小的内存块单位；存储数据的时候，会选择大小最合适的内存块进行存储。

redis作者为了更好的性能，在redis中实现了自己的内存分配器来管理内存，不用的内存不会马上返还给OS，从而实现提高性能。
修改cache的值，且修改后的value与原先的value大小差异较大。

 

优化方法

重启redis服务，
redis4.0以上可以设置自动清理 config set activedefrag yes，也可以通过memory purge手动清理，配置监控使用性能最佳。
修改分配器（不推荐，需要对各个分配器十分了解）
避免频繁更新操作

 

内存回收策略

 

1.删除过期键值

惰性删除
1. 访问key
2. expired dict
3. del key
定时删除：每秒运行10次，采样删除

2.maxmemory-policy

Noevition：默认策略，不会删除任何数据，拒绝所有写入操作并返回错误信息。
volatile-lru：根据lru算法删除设置了超时属性的key，直到腾出空间为止。如果没有可删除的key，则将退回到noevition。
allkeys-lru：根据lru算法删除key，不管数据有没有设置超时属性，直到腾出足够空间为止。
allkeys-random：随机删除所有键，直到腾出足够空间为止。
volatile-random：随机删除过期键，直到腾出足够空间为止。
volatile-ttl：根据键值对象的ttl属性，删除最近将要过期的数据。如果没有，回退到noevicition。

 

 

客户端缓冲区优化

 

案例：一次线上事故，主从节点配置的maxmemory都是4GB，发现主节点的使用内存达到了4GB即内存已打满。而从节点只有2GB。

思考方向
考虑Redis的内存自身组成
主从节点之前数据传输不一致（会导致对象内存不一致）
dbsize
查看info replication中的slave_repl_offset
查看缓冲区方面
通过info clients查看最大的缓冲区占用
通过client list查看所有客户端的详细信息

 

问题发现：

存在一个monitor客户端对命令进行监听，由于Redis的QPS极高，monitor客户端无法及时处理，占用缓冲区。
问题预防
运维层面：线上禁用monitor（rename monitor "")
运维层面：适度限制缓冲区大小
开发层面：理解monitor原理，可以短暂寻找热点key
开发层面：使用CacheCloud可以直接监控到相关信息

 

内存优化其他建议

不要忽视key的长度：1个亿的key，每个字节都是节省
序列化和压缩方法：拒绝Java原生序列化，可以采用Protobuf、kryo等

 

不建议使用Redis的场景

数据：大且冷的数据
功能性：关系型查询、消息队列

 

 

 

 

完