引言提及Redis，大多数从事IT工作的都知道它是一种非常快的数据库。如果进一步问它为什么那么快，可能大多数人会回答“它是运行在内存里的数据库，所以快”。其实Redis是因为很多维度的创新才支撑了“快”的评价。如果我们了解了它在数据模型、处理模式等方面的特点，就会更加了...(more)

Redis版本选择和升级“很麻烦”，一旦决策不当可能会引起较大的稳定性问题。最近稳定性话题很热，我也来蹭个热度，聊一聊Redis版本升级的“最佳实践”。虽然本文聊的是Redis版本升级，但是我觉得可能对其他产品升级也有借鉴意义。一、认知对齐一般认为，数据库产品求稳不求新，我想...(more)

覆盖了Redis数据结构、持久化、复制、redissentinel、rediscluster等.

Redis死键的定义不尽相同，通常有两种：写到Redis里后，由于过期时间过长或者压根没有过期时间，加之长期不访问，这类key可以被称为死键。明明已经过了过期时间，但还占用Redis内存（没有真的删除），这类key也可以被称为死键。注释：本文讨论第二种情况一、两个例子下面两个列子中的键值均...(more)

为了更好的做好容灾保障，使业务能够应对机房级别的故障，滴滴的存储服务都在多机房进行部署。本文简要分析了Redis实现异地多活的几种思路，以及滴滴Redis异地多活架构演进过程中遇到的主要问题和解决方法，抛砖引玉，给小伙伴们一些参考。Redis异地多活的主要思路业界实现Redis异...(more)

某个周末的晚上突然收到一波耗时上升报警，仔细一看报警消息，原来是出现了慢查请求导致集群耗时大幅上升，此时业务同学也收到上游服务受影响报警。在处理问题过程中，运维同学发现Redis集群中只有部分实例出现cpu利用率上升，慢查日志也集中在这几个实例，而上游业务此时没有上线或...(more)

本文是Redis成本优化系列文章的第3篇，讲述了hashtable的相关优化。一、几个实验hash相关配置before 7.0hash-max-ziplist-entries:512hash-max-ziplist-value:64after 7.0hash-max-listpack-entries 512hash-max-listpack-value 64如下三个场景，hash的内部实现都是hash...(more)

本文是Redis成本优化系列文章的第2篇，这篇篇幅较少，但是是Redis内存优化的重要里程碑。一、2个实验写入1万条hash键值对：key为37字节、1000对field(f0..f99)-value(2字节)版本2.8.243.0.73.2.134.0.145.0.146.0.206.2.157.0.12容量MB995.83995.83776.72461.61461.61461.6146...(more)

做了一阵子的成本优化，一直想整理些文章发出来，由于比较懒且“怂”一直没弄，最近决定还是整理下，本文是该系列文章的第一篇。一、几个实验Redis实验版本(撰写文本的最新版本)：2.8.24、3.0.7、3.2.13、4.0.14、5.0.14、6.0.20、6.2.15、7.0.12，容量MB：去掉了Redis自身的容量。1....(more)

需求：根据当前客户的生产环境，模拟安装部署Redis的测试环境，方便后续的功能测试。1.准备工作Redis的版本和虚拟主机数量都按照客户的生产环境来准备：Redis版本：3.2.10准备3台虚拟机，具体环境信息为:系统版本主机名IP地址主机内存磁盘空间RHEL6.8test01192.168.1.1214G20GRHEL6....(more)