太仓手机网站建设,宣传网站建设,四川超宇建设集团网站,网站推广排名公司生产环境中热 key 处理
热 key 问题就是某一瞬间可能某条内容特别火爆#xff0c;大量的请求去访问这个数据#xff0c;那么这样的 key 就是热 key#xff0c;往往这样的 key 也是存储在了一个 redis 节点中#xff0c;对该节点压力很大
那么对于热 key 的处理就是通过热…生产环境中热 key 处理
热 key 问题就是某一瞬间可能某条内容特别火爆大量的请求去访问这个数据那么这样的 key 就是热 key往往这样的 key 也是存储在了一个 redis 节点中对该节点压力很大
那么对于热 key 的处理就是通过热 key 探测系统对热 key 进行计数一旦发现了热 key就将热 key 在 jvm 本地缓存中再存储一份那么当再有大量请求来读取时就直接在应用的 jvm 缓存中读取到直接返回了不会再将压力给到同一个 redis 节点中了如下图 京东开源了高性能热 key 探测中间件JD-hotkey可以实时探测出系统的热数据生产环境中可以基于 JD-hotkey 来解决热 key 的问题
生产环境中大 key 监控和切分处理方案
大 key 问题是指在 Redis 中某一个 key 所存储的 value 值特别大几个 mb 或者几十 mb那么如果频繁读取大 key就会导致大量占用网络带宽影响其他网络请求
对于大 key 会进行特殊的切片处理并且要对大 key 进行监控如果说发现超过 1mb 的大 key则进行报警并且自动处理将这个大 key 拆成多个 k-v 进行存储比如将 big-key 拆分为 — big-key01big-key02 ...
那么大 key 的解决方案如下
通过 crontab 定时调度 shell 脚本每天凌晨通过 rdbtools 工具解析 Redis 的 rdb 文件过滤 rdb 文件中的大 key 导出为 csv 文件然后使用 SQL 导入 csv 文件存储到 MySQL 中的表 redis_large_key_log 中使用 canal 监听 MySQL 的 redis_large_key_log 表的 binlog 日志将增量数据发送到 RocketMQ 中这里该表的增量数据就是解析出来的大 key将大 key 的数据发送到 MQ 中由 MQ 消费者来决定如何对这些大 key 进行处理在 MQ 的消费端可以通过一个大 key 的处理服务来对大 key 进行切分分为多个 k-v 存储在 Redis 中
那么在读取大 key 的时候需要判断该 key 是否是大 key如果是的话需要对多个 k-v 的结果进行拼接并返回
数据库与缓存最终一致性解决方案
如果不采用更新数据时双写来保证数据库与缓存的一致性的话可以通过 canal RocketMQ 来实现数据库与缓存的最终一致性对于数据直接更新 DB通过 canal 监控 MySQL 的 binlog 日志并且发送到 RocketMQ 中MQ 的消费者对数据进行消费并解析 binlog过滤掉非增删改的 binlog那么解析 binlog 数据之后就可以知道对 MySQL 中的哪张表进行 增删改 操作了那么接下来我们只需要拿到这张表在 Redis 中存储的 key再从 Redis 中删除旧的缓存即可那么怎么取到这张表在 Redis 中存储的 key 呢
可以我们自己来进行配置比如说监控 sku_info 表的 binlog那么在 MQ 的消费端解析 binlog 之后就知道是对 sku_info 表进行了增删改的操作那么假如 Redis 中存储了 sku 的详情信息key 为 sku_info:{skuId}那么我们就可以在一个地方可以在配置文件中也可以在枚举类中进行配置对这个信息进行配置
// 配置下边这三个信息
tableName sku_info; // 表示对哪个表进行最终一致性
cacheKey sku_info:; // 表示缓存前缀
cacheField skuId; // 缓存前缀后拼接的唯一标识// data 是解析 binlog 日志后拿到的 key-value 值data.get(skuId) 就是获取这一条数据的 skuId 属性值
// 如下就是最后拿到的 Redis 的 key
redisKey cacheKey data.get(cacheField)那么整体的流程图如下
