虎年除夕(2022-01-31)，Redis7.0RC1发布，这是新的Redis团队开发的第2个版本(6.2和7.0)，该版本提供了很多新的特性、做了很多改进(尤其是在性能和内存优化上，关键字Significant)，当然也修复了很多小bug，总结下重点如下：RedisFunction：新的服务脚本编程模式内存和性能优化：非用户功能...(more)

dict是Redis的基础数据结构，Redis的键值、hash|set|zset数据结构均用到了dict。本文介绍了Redis7在dict上的优化，思路清晰简单但效果明显，值得重点关注(降本增效)。来源：Significantmemorysavingsin case of many hash or zset keys (#9228)一、优化前的dict结构7.0...(more)

Redis7.0共享复制缓冲区的设计与实现以下文章来源于RedisGossip，作者ShooterIT本文将主要分析Redis主从复制中的内存消耗过多和堵塞问题，以及Redis7.0(尚未发布)的共享复制缓冲区方案是如何解决这些问题的。1Redis主从复制原理简介尽管本文的目的不是讲解Redis主从复制的原...(more)

架构的演变过程经历了从单体架构、SOA架构、微服务架构，再进入容器化，如今又流行无服务架构，虽然架构在逐步在升级，但是随着业务量的发展会发现版本迭代频率会逐步频繁，随之而引发的代码冲突、模块耦合问题似乎并没有减少。既然都已经是微服务架构了，怎么还是会出现这样的问题...(more)

这个在当时的文章里没有讨论，因为这个问题很难绝对化，但背后的知识还是很有讨论价值的，我们来看一段对话：解析一、存在哪？1.哈希表(hashtable)要知道能存多少，首先要知道Redis的键值对存在哪？你可能已经猜到了哈希表，它是天然的键值对数据结构，各种语言都支持该数据结构，基本上是使...(more)

老生常谈的bigkey原文【强制】：拒绝bigkey(防止网卡流量、慢查询)string类型控制在10KB以内，hash、list、set、zset元素个数不要超过5000。反例：一个包含200万个元素的list。非字符串的bigkey，不要使用del删除，使用hscan、sscan、zscan方式渐进式删除，同时要注意防止bigkey过期...(more)

本篇是第一篇：由键名设计想到的SDS内存优化原文1.key名设计(1)【建议】:可读性和可管理性以业务名(或数据库名)为前缀(防止key冲突)，用冒号分隔，比如业务名:表名:idugc:video:1(2)【建议】：简洁性保证语义的前提下，控制key的长度，当key较多时，内存占用也不容忽视，例如：user:{uid}:...(more)

之前白馨在Redis技术交流群里，总结了一下Redis从2.8~4.0关于过期键相关的fix记录，非常有帮助，但有些东西未尽详细，本文将进行详细说明。先从一个问题来看，运行环境如下：Redis:2.8.19db0:keys=10000000,expires=10000000主从结构从下图中可以看到，在从节点gethello非空，在主节点ge...(more)

虽然Redisreleasenotes里经常有提到，由于某bug会造成Rediscore了。也许很幸运，使用多年官方的Redis，我确实没有遇到过core(ps：目前管理实例数是六位数的)。讲真，写这么一篇文章，我瑟瑟发抖，一直以来虽然我一直做Redis相关的工作，但处理这种问题不太多，所以哪里写的不对，欢迎指正。...(more)

一、缓存无底洞现象生活中对无底洞的描述大概是这样：不断的投入，但没什么产出，对于键值类型的分布式缓存来说也有类似的问题，来看下面一段对话：这个其实就是典型的缓存无底洞问题，为了满足数据量的增长以及整体性能提升，集群规模一直变大，但批量操作反而性能下降，现在管理的Redis...(more)