chenjian723122704的专栏

Redis 使用 RESP 协议（Redis Serialzation Protocol）协议定义了客户端和服务器端交互的命令、数据的编码格式。在 Redis 2.0 版本中，RESP 协议正式称为客户端和服务器端的标准通信协议。从 Redis 2.0 到 Redis 5.0 ，RESP 协议都称为 RESP 2 协议，从 Redis 6.0 开始，Redis 就采用 RESP 3 协议了。

Redis学习资料、运维说明及使用规范建议

这几年，新型非易失存储（Non-Volatile Memory，NVM）器件发展得非常快。NVM器件具有容量大、性能快、能持久报错数据的特性，这些刚刚就是 Redis 追求的目标。同时NVM器件像 DRAM 一样，可以让软件以字节粒度进行寻址访问，所以，在实际应用中，NVM可以作为内存来使用，称为NVM内存。Redis 作为内存键值数据库，如果能和 NVM 内存结合起来使用，可以充分享受到这些特性。

Redis 6.0 新增了几个关键新特性，分别是面向网络处理的多 IO 线程、客户端缓存、细粒度的权限控制，以及 RESP 3 协议的使用。其中，面向网络处理的多 IO 线程可以提高网络请求处理的速度，而客户端缓存可以让应用直接在客户端本地读取数据，这两个特性可以提升 Redis 的性能。除此之外，细粒度权限控制让 Redis 可以按照命令粒度控制不同用户的访问权限，加强了 Redis 的安全保护。RESP 3 协议则增强客户端的功能，可以让应用更加方便地使用 Redis 的不同数据类型。

Redis Cluster 能保存的数据量以及支撑的吞吐量，跟集群实例规模相关。Redis 官方给出了 Redis Cluster 的规模上线，就是一个集群运行 1000 个实例。其实，限定 Redis Cluster 集群规模的一个关键因素就是，，在集群超过一定规模时（比如 800 节点），集群吞吐量反而会下降。所以，集群的实际规模会受到限制。

在切片集群中，数据会按照一定的规则分散到不同的实例上保存。比如，Redis Cluster 或 Codis 会先按照 CRC 算法的计算值对 Slot（逻辑槽）取模，同时 Slot 又有运维管理员分配到不同的实例上。这样，数据就被保存到相应的实例上了。如果发生了数据倾斜，那么保存了大量数据，或者是保存了热点数据的实例的处理压力就会增大，速度变慢，甚至还可能会引起这个实例的内存资源耗尽，从而崩溃。

秒杀是一个非常经典的活动场景，比如，在双 11、618 等电商促销活动中，都会有秒杀场景。秒杀场景的业务特点是，业务系统要处理瞬时的大量高并发请求，而 Redis 就经常被用来支撑秒杀活动。秒杀场景包含多个环节，可以分成秒杀前、秒杀中和秒杀后三个阶段，每个阶段的请求处理需求不同，Redis 并不能支撑秒杀场景的每一个环节。Redis 具体在秒杀场景的哪个环节起到支撑作用的呢？又是如何支持的呢？清楚了解这个问题，我们才能知道再秒杀场景中，如何使用 Redis 来支撑高并发压力，并且做好秒杀场景的应对方案。

Redis 的切片集群使用多个实例保存数据，能很好的应对大数据量的场景。在《》中，介绍了 Redis 官方提供的切片集群方法 Redis Cluster。本章，再来学习下，在方案正式发布前，业界广泛使用的Codis。

所谓，就是指在主从集群中，同时有两个主节点，它们都能接收写请求。而脑裂最直接的影响就是客户端不知道该往哪个主节点写入数据，结果就是不同的客户端会往不同的主机诶点上写入数据。而且，严重的话，脑裂会导致数据丢失。在使用主从集群时，曾遇到过这样一个问题：主从集群有 1 个主库、5 个从库和 3 个哨兵实例，在使用过程中，发现客户端发送的一些数据丢失了，这直接影响了业务层的数据可靠性。通过一系列的问题排查，我们才知道，这其实是主从集群中的问题导致的。

Redis 的主从同步机制不仅可以让从库服务更多的读请求，分担主库的压力，而且还能在主库发生故障时，进行主从库切换，提供高可靠服务。不过，在实际使用主从机制时会踩到一些“坑”：主从数据不一致、读到过期数据以及配置项设置得不合理而导致服务挂掉。

事务是数据库的一个重要功能。所谓的事务，就是指对数据进行读写的一系列操作。事务在执行时，会提供专门的属性保证，包括原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）和持久性（Durability），也就是 ACID 属性。这些属性既包括了对事务执行结果的要求，也有对数据库在执行前后的数据状态变化的要求。我们先了解下 ACID 属性对事务执行的具体要求，有了这个知识基础后，我们才能准确地判断 Redis 的事务机制能够保证 ACID 属性。

Redis 本身可以被多个客户端共享访问，正好就是一个共享存储系统，可以用来保存分布式锁。而且 Redis 的读写性能高，可以对应高并发锁操作的场景。

为了保证并发访问的正确性，Redis 提供了两种方法，分别是加锁和原子操作。当一个客户端获得锁后，就会一直持有这把锁，直到客户端完成数据更新，才释放这把锁。

随着业务数据的增加（比如电商业务中，随着用户规模和商品数量的增加），就需要 Redis 能保存更多的数据。本文介绍 Pika ，基于 SSD 单实例扩容的技术方案。

在一些常见下，有些数据被访问的次数非常少，甚至只会被访问一次。当这些数据请求后，还继续留存在缓存中的话，只会白白占用缓存的空间。这种情况就是缓存污染。当缓存污染不严重时，只有少量数据占据缓存空间，此时对缓存系统的影响不大。但是，缓存污染一旦变得验证后，就会有大量不在访问的数据滞留在缓存中。

我们常常会面临缓存异常的三个问题，分别是缓存雪崩、缓存击穿和缓存穿透。这三个问题一旦发生，会导致大量的请求积压到数据库层。如果请求的并发量很大，就会导致数据库宕机或是故障，这就是很严重的生产事故了。

只要使用 Redis 缓存，就必须面对缓存和数据库的一致性问题。重要的是，如果数据不一致，那么业务应用从缓存中读取的数据就不是最新数据，这会导致严重的问题。

Redis 缓存使用内存来保存数据，避免业务应用直接从数据库读取数据，可以提升应用的访问速度。但是，我们又没有办法做到把所有的数据都放入缓存，因为这样做的性价比不高，而且缓存也存不下数据库中的所有数据。例如，Mysql 中有 1TB 的数据，如果使用 Redis 把这些数据都缓存起来，虽然应用都能在内存中访问数据了，但是这样配置并不合理，因为性价比低。一方面内存的价格比磁盘的价格贵很多。另一方面，数据访问都是有局部性的，也就是“二八原理”，80% 的请求实际只访问了 20% 的数据。

我们知道，Redis 提供了高性能的数据存取功能，广泛应用在缓存场景中，既可以提升业务的响应速度，又可以避免把高并发的请求发送到数据库。本章介绍 Redis 作为旁路缓存的工作原理及如何选择应用系统的缓存类型。

缓冲区的功能其实很简答，主要就是用一块内存空间来暂时存放命令数据，以免出现因为数据和命令的处理速度慢于发送速度而导致的数据丢失和性能的问题。但是因为缓冲区的内存空间有限，如果往里面写入数据的速度持续地大于从里面读取数据的速度，就会导致缓冲区需要越来越多的内存来暂存数据。当缓冲区占用的内存超出了设定的上限阈值时，就会出现缓冲区溢出。如果发生了溢出，就会丢失数据了。那是不是不给缓冲区的大小设置上限，就可以了呢？

在使用 Redis 是，经常会遇到一个问题：明明做了数据删除，数据量不大，但是 使用 top 命令查看时，发现 Redis 还是占用了很多内存。这是因为，当删除数据后，Redis 释放的内存空间会由内存分配器管理，并不会立即返回操作系统，所以，操作系统操作系统仍然会记录这给 Redis 分配了大量内存。这往往会伴随一个潜在的风险点： Redis 释放的内存空间可能并不是联系的，那么，这些不连续的内存空间可能处于一种闲置的状态。这会导致一个问题：虽然有空闲时间，Redis 却无法用来保存数据。

在 Redis 的实际应用中，有一个非常严重的问题，就是 Redis 突然变慢了。举个例子，在秒杀场景下，一旦 Redis 变慢了，大量的用户下单请求就会被拖慢，也就是说，用户提交了下单申请，确没有得到响应，这会给用户带来非常糟糕的体验，甚至可能会导致用户流失。而且，在实际的生产环境中，Redis 往往只是业务系统中的一个环节，（例如作为缓存或是数据库）。一旦 Redis 上的请求延迟增加，就可能引起业务系统中的一串儿“连锁反应”。

可能很多人都认为 Redis 和 CPU 的关系简单，Redis 的线程在 CPU 上运行，CPU 快 Reids 处理请求的速度也很快。其实，这种认知是片面的，CPU 的多核架构及多 CPU 结构，也会影响到 Redis 的性能。如果不了解 CPU 对 Redis 的影响，那么在进行 Redis 调优时，可能会遗漏一些调优方法，不能把 Redis 的性能发挥到极致。

Redis 被广泛应用的原因是因为它支持高性能访问。所以，我们要重视所有可能影响 Redis 性能的因素（如命令操作、系统配置、关键机制、硬件配置等）。

Redis 时间序列数据处理

日常生活中，“附近停车场”、打车软件的叫车，这些都离不开基于位置信息服务（LBS）的应用。LBS 应用访问的数据是和人或物关联的一组经纬度信息，且要能查询相邻的经纬度范围，Redis 的 GEO 就非常适合应用在 LBS 服务的场景中。

Redis 集合的统计操作技巧讲解，可以当做笔记

这篇文章，了解下 String 类型的内存消耗问题，以及选择节省内存开销的数据类型的解决方案。先分析一个案例：开发一个文件存储系统，要求这个系统能快速记录文件 ID和图片在存储系统中保存的文件存储对象 ID。同时，系统可根据文件 ID 快速查找到图片存储对象 ID。因文件数量巨大，所以采用 10 位数字来表示文件 ID和文件存储对象 ID的关系。如，文件 ID为 1111100021 ，它在存储系统中的ID 为 3333300021。文件 ID和文件存储对象 ID。

为了保存大量数据，我们使用了大内存云主机和切片集群两种方法。实际上，这两种方法分别对应着 Redis 应对数据量增多的两种方案：纵向扩展和横向扩展。

总体来说，Redis 得到主从库同步的基本原理，有三种模式：全量同步、基于长链接的命令传播，以及增量同步。全量复制虽然耗时，但是对于从库来说，如果是第一次同步，全量复制是无法避免的，所以，建议一个 Redis 的数据量不要太大，一个实例的大小在几 GB 级别比较合适，这样可以减少 RDB 文件生成、传输和重新加载的开销。另外，为了避免多个从库同时和主库进行全量复制，给主库过大压力，可以采用“主 - 从 - 从”级联模式，来缓解主库压力。

总所周知，Redis 绝大部分事业场景是当做缓存使用，但是有个问题是绝对不能忽略的：一旦服务器宕机，内存中的数据将全部丢失。虽然从后端数据库可以恢复这些数据，但是这种方式存在两个问题：一是需要频繁访问数据库，给数据库带来巨大压力；二是这些数据是从慢速数据库中读取出来的，性能肯定比不上从 Redis 中读取，导致使用这些数据的应用程序响应变慢。所以，对于 Redis 来说，实现数据持久化，避免从后端数据库中进行恢复，是至关重要的。

redis为什么慢-从底层原理剖析开始