吴声子夜歌的博客

以Redis Cluster为例，它会造成整体流量的不均衡，个别节点出现OPS过大的情况，极端情况下热点key甚至会超过Redis本身能够承受的OPS，因此寻找热点key对于开发和运维人员非常重要。客户端其实是距离key“最近”的地方，因为Redis命令就是从客户端发出的，例如在客户端设置全局字典（key和调用次数）​，每次调用Redis命令时，使用这个字典进行记录，如下所示。如果站在机器的角度，可以通过对机器上所有Redis端口的TCP数据包进行抓取完成热点key的统计，如图所示。下面是三种方案的思路。

bigkey的存在并不是完全致命的，如果这个bigkey存在但是几乎不被访问，那么只有内存空间不均匀的问题存在，相对于另外两个问题没有那么重要紧急，但是如果bigkey是一个热点key（频繁访问）​，那么其带来的危害不可想象，所以在实际开发和运维时一定要密切关注bigkey的存在。下表展示了非字符串类型的数据结构在不同数量级、不同元素大小下对bigkey执行del命令的时间，总体上看元素个数越多、元素越大，删除时间越长，相对于字符串类型，这种删除速度已经足够可以阻塞Redis。

Redis的默认端口是6379，不使用默认端口从一定程度上可降低被入侵者发现的可能性，因为入侵者通常本身也是一些攻击程序，对目标服务器进行端口扫描，例如MySQL的默认端口3306、Memcache的默认端口11211、Jetty的默认端口8080等都会被设置成攻击目标，Redis作为一款较为知名的NoSQL服务，6379必然也在端口扫描的列表中，虽然不设置默认端口还是有可能被攻击者入侵，但是能够在一定程度上降低被攻击的概率。如果被入侵者获取root权限后，就可以在这台机器以及相关机器上“为所欲为”了。

综上所述，如果AOF已经开启了，那么用AOF来恢复是比较合理的方式，但是如果AOF关闭了，那么RDB虽然数据不是很实时，但是也能恢复部分数据，完全取决于RDB是什么时候备份的。2)如果要用AOF文件进行数据恢复，那么必须要将AOF文件中的flushall相关操作去掉，为了更加安全，可以在去掉之后使用redis-check-aof这个工具去检验和修复一下AOF文件，确保AOF文件格式正确，保证数据恢复正常。所以如果AOF重写发生了，也就意味着之前的数据就丢掉了，那么利用AOF文件来恢复的办法就失效了。

info all命令包含Redis最全的系统状态信息，下表 info all命令涉及的所有section，其中每个模块名就是我们上面提到的section，例如info Server是查看Redis服务的基本信息。下表是info Commandstats模块的统计信息，是Redis命令统计信息，包含各个命令的命令名、总次数、总耗时、平均耗时。下表是info Stats模块的统计信息，是Redis的基础统计信息，包含了：连接、命令、网络、过期、同步等很多统计信息。下表是Redis客户端的相关配置。

虽然Redis并没有对多个服务器的时钟有严格要求，但是假如多个Redis实例所在的服务器时钟不一致，对于一些异常情况的日志排查是非常困难的，例如Redis Cluster的故障转移，如果日志时间不一致，对于我们排查问题带来很大的困扰（注：但不会影响集群功能，集群节点依赖各自时钟）​。Linux操作系统中，/proc/{pid}目录是存储指定进程的相关信息，其中/proc/{pid}/smaps记录了当前进程所对应的内存映像信息，这个信息对于查询指定进程的swap使用情况很有帮助。

Redis Cluster使用CRC16算法计算出散列值，再取对16383的余数就可以算出slot值，同时10.5节我们提到过Smart客户端会保存slot和节点的对应关系，有了这两个数据就可以将属于同一个节点的key进行归档，得到每个节点的key子列表，之后对每个节点执行mget或者Pipeline操作，它的操作时间=node次网络时间+n次命令时间，网络次数是node的个数，整个过程如图所示，很明显这种方案比第一种要好很多，但是如果节点数太多，还是有一定的性能问题。造成缓存穿透的基本原因有两个。

但是当持有槽的主节点下线时，从故障发现到自动完成转移期间整个集群是不可用状态，对于大多数业务无法容忍这种情况，因此建议将参数cluster-require-full-coverage配置为no，当主节点故障时只影响它负责槽的相关命令执行，不会影响其他主节点的可用性。集群模式下从节点不接受任何读写请求，发送过来的键命令会重定向到负责槽的主节点上（其中包括它的主节点）​。当自动故障转移失败时，只要故障的主节点有存活的从节点就可以通过手动转移故障强制让从节点替换故障的主节点，保证集群的可用性。

只有持有槽的主节点才会处理故障选举消息(FAILOVER_AUTH_REQUEST)，因为每个持有槽的节点在一个配置纪元内都有唯一的一张选票，当接到第一个请求投票的从节点消息时回复FAILOVER_AUTH_ACK消息作为投票，之后相同配置纪元内其他从节点的选举消息将忽略。当从节点收集到N/2+1个持有槽的主节点投票时，从节点可以执行替换主节点操作，例如集群内有5个持有槽的主节点，主节点b故障后还有4个，当其中一个从节点收集到3张投票时代表获得了足够的选票可以进行替换主节点操作，如图所示。

在集群模式下，Redis接收任何键相关命令时首先计算键对应的槽，再根据槽找出所对应的节点，如果节点是自身，则处理键命令；否则回复MOVED重定向错误，通知客户端请求正确的节点。这个过程称为MOVED重定向，如图所示。例如，在之前搭建的集群上执行如下命令：执行set命令成功，因为键key：test：1对应槽5191正好位于6379节点负责的槽范围内，可以借助clusterkeyslot{key}命令返回key所对应的槽，如下所示：再执行以下命令，由于键对应槽是9252，不属于6379节点，则回复MOVE

这里我们故意忽略了槽和数据在节点之间迁移的细节，目的是想让读者重点关注在上层槽和节点分配上来，理解集群的水平伸缩的上层原理：集群伸缩=槽和数据在节点之间的移动，下面将介绍集群扩容和收缩的细节。当下线主节点具有从节点时需要把该从节点指向到其他主节点，因此对于主从节点都下线的情况，建议先下线从节点再下线主节点，防止不必要的全量复制。扩容之初我们把6385、6386节点加入到集群，节点6385迁移了部分槽和数据作为主节点，但相比其他主节点目前还没有从节点，因此该节点不具备故障转移的能力。

集群中每个节点通过一定规则挑选要通信的节点，每个节点可能知道全部节点，也可能仅知道部分节点，只要这些节点彼此可以正常通信，最终它们会达到一致的状态。当节点出故障、新节点加入、主从角色变化、槽信息变更等事件发生时，通过不断的ping/pong消息通信，经过一段时间后所有的节点都会知道整个集群全部节点的最新状态，从而达到集群状态同步的目的。消息处理完后回复pong消息，内容同样包含消息头和消息体，发送节点接收到回复的pong消息后，采用类似的流程解析处理消息并更新与接收节点最后通信时间，完成一次消息通信。

首次启动的节点和被分配槽的节点都是主节点，从节点负责复制主节点槽信息和相关的数据。文件内容记录了集群初始状态，这里最重要的是节点ID，它是一个40位16进制字符串，用于唯一标识集群内一个节点，之后很多集群操作都要借助于节点ID来完成。6379节点启动成功，第一次启动时如果没有集群配置文件，它会自动创建一份，文件名称采用cluster-config-file参数项控制，建议采用node-{port}.conf格式定义，通过使用端口号区分不同节点，防止同一机器下多个节点彼此覆盖，造成集群信息异常。

每个节点会负责一定数量的槽，如图所示。这种方式的突出优点是简单性，常用于数据库的分库分表规则，一般采用预分区的方式，提前根据数据量规划好分区数，比如划分为512或1024张表，保证可支撑未来一段时间的数据量，再根据负载情况将表迁移到其他数据库中。使用特定的数据，如Redis的键或用户ID，再根据节点数量N使用公式：hash(key)%N计算出哈希值，用来决定数据映射到哪一个节点上。由于Redis Cluster采用哈希分区规则，这里我们重点讨论哈希分区，常见的哈希分区规则有几种，下面分别介绍。

所以很多时候，Redis Sentinel中的从节点仅仅是作为主节点一个热备，不让它参与客户端的读操作，就是为了保证整体高可用性，但实际上这种使用方法还是有一些浪费，尤其是在有很多从节点或者确实需要读写分离的场景，所以如何实现从节点的高可用是非常有必要的。所以在设计Redis Sentinel的从节点高可用时，只要能够实时掌握所有从节点的状态，把所有从节点看做一个资源池（如图所示）​，无论是上线还是下线从节点，客户端都能及时感知到（将其从资源池中添加或者删除）​，这样从节点的高可用目标就达到了。

当Sentinel主观下线的节点是主节点时，该Sentinel节点会通过sentinel is-master-down-by-addr命令向其他Sentinel节点询问对主节点的判断，当超过<quorum>个数，Sentinel节点认为主节点确实有问题，这时该Sentinel节点会做出客观下线的决定，这样客观下线的含义是比较明显了，也就是大部分Sentinel节点都对主节点的下线做了同意的判定，那么这个判定就是客观的，如图所示。从节点、Sentinel节点在主观下线后，没有后续的故障转移操作。

下面代码就是MasterListener的核心监听代码，代码中比较重要的部分就是订阅Sentinel节点的+switch-master频道，它就是Redis Sentinel在结束对主节点故障转移后会发布切换主节点的消息，Sentinel节点基本将故障转移的各个阶段发生的行为都通过这种发布订阅的形式对外提供，开发者只需订阅感兴趣的频道即可​，这里我们比较关心的是+switch-master这个频道。3)验证当前获取的“主节点”是真正的主节点，这样做的目的是为了防止故障转移期间主节点的变化，如图所示。

对指定主节点进行强制故障转移（没有和其他Sentinel节点“协商”​）​，当故障转移完成后，其他Sentinel节点按照故障转移的结果更新自身配置，这个命令在Redis Sentinel的日常运维中非常有用。当前Sentinel节点对符合<pattern>（通配符风格）主节点的配置进行重置，包含清除主节点的相关状态（例如故障转移）​，重新发现从节点和Sentinel节点。例如下面，sentinel-1节点取消对mymaster-1节点的监控，但是要注意这个命令仅仅对当前Sentinel节点有效。

当Sentinel节点集合对主节点故障判定达成一致时，Sentinel领导者节点会做故障转移操作，选出新的主节点，原来的从节点会向新的主节点发起复制操作，parallel-syncs就是用来限制在一次故障转移之后，每次向新的主节点发起复制操作的从节点个数。但实际上Sentinel节点会对所有节点进行监控，但是在Sentinel节点的配置中没有看到有关从节点和其余Sentinel节点的配置，那是因为Sentinel节点会从主节点中获取有关从节点以及其余Sentinel节点的相关信息。

Redis Sentinel是一个分布式架构，其中包含若干个Sentinel节点和Redis数据节点，每个Sentinel节点会对数据节点和其余Sentinel节点进行监控，当它发现节点不可达时，会对节点做下线标识。对于Redis的运维方来说，整个故障转移的过程是需要人工来介入的，故障转移实时性和准确性上都无法得到保障，图1到图5展示了一个1主2从的Redis主从复制模式下的主节点出现故障后，是如何进行故障转移的，过程如下所示。1)如图所示，主节点出现故障，此时两个从节点与主节点失去连接，主从复制失败。

参与复制的Redis实例划分为主节点(master)和从节点(slave)。默认情况下，Redis都是主节点。每个从节点只能有一个主节点，而主节点可以同时具有多个从节点。复制的数据流是单向的，只能由主节点复制到从节点。配置复制的方式有以下三种：综上所述，slaveof命令在使用时，可以运行期动态配置，也可以提前写到配置文件中。例如本地启动两个端口为6379和6380的Redis节点，在127.0.0.1：6380执行如下命令：slaveof配置都是在从节点发起，这时6379作为主节点，6380作为从节点。

客户端连接Redis使用的是TCP协议，直连的方式每次需要建立TCP连接，而连接池的方式是可以预先初始化好Jedis连接，所以每次只需要从Jedis连接池借用即可，而借用和归还操作是在本地进行的，只有少量的并发同步开销，远远小于新建TCP连接的开销。Redis是用单线程来处理多个客户端的访问，因此作为Redis的开发和运维人员需要了解Redis服务端和客户端的通信协议，以及主流编程语言的Redis客户端使用方法，同时还需要了解客户端管理的相应API以及开发运维中可能遇到的问题。

熟悉关系型数据库的读者应该对事务比较了解，简单地说，事务表示一组动作，要么全部执行，要么全部不执行。例如在社交网站上用户A关注了用户B，那么需要在用户A的关注表中加入用户B，并且在用户B的粉丝表中添加用户A，这两个行为要么全部执行，要么全部不执行，否则会出现数据不一致的情况。Redis提供了简单的事务功能，将一组需要一起执行的命令放到multi和exec两个命令之间。multi命令代表事务开始，exec命令代表事务结束，它们之间的命令是原子顺序执行的，例如下面操作实现了上述用户关注问题。可以看到sadd命

OK。

一个新的命令满足慢查询条件时被插入到这个列表中，当慢查询日志列表已处于其最大长度时，最早插入的一个命令将从列表中移出，例如slowlog-max-len设置为5，当有第6条慢查询插入的话，那么队头的第一条数据就出列，第6条慢查询就会入列。所谓慢查询日志就是系统在命令执行前后计算每条命令的执行时间，当超过预设阀值，就将这条命令的相关信息（例如：发生时间，耗时，命令的详细信息）记录下来，Redis也提供了类似的功能。需要注意，慢查询只统计步骤3)的时间，所以没有慢查询并不代表客户端没有超时问题。

布隆过滤器（Bloom Filter）是1970年由布隆提出的。它实际上是一个很长的二进制向量和一系列随机映射函数。布隆过滤器可以用于检索一个元素是否在一个集合中。它的优点是空间效率高和查询时间短，缺点是有一定的误识别率和元素删除困难。布隆过滤器是一种空间效率很高的随机数据结构，它利用位数组很简洁地表示一个集合，并能判断一个元素是否属于这个集合。布隆过滤器由一个很长的位数组和一系列散列函数组成，数组的每个元素都只占1 bit空间，并且每个元素只能为0或1。

redis-stat提供了一种简易的方式实现对Redis的监控，但多数场景下可能需要进行定制，例如鉴权方式、统计指标、告警等。为了实现更灵活的控制，可利用类似的方式对INFO信息进行解析，以实现对Redis的统一监控。在本节我们使用Spring Boot做一个自定义Redis监控平台，前端使用Bootstrap 3页面展示Redis的监控指标，使用WebSocket技术实时监控Redis数据库db0的keys数量，在页面中使用曲线图形动态地显示keys数量。完整的自定义监控页面如图所示。

微服务是一种架构风格，是一种使用一套微小服务来开发单个应用的方法。每个服务运行在自己的进程中，通过轻量的通信机制联系，经常是基于HTTP资源的API。这些服务基于业务能力构建，能够通过自动化部署方式独立部署。微服务，简单地说就是将一个大服务（项目）划分为多个子服务（项目）​。典型微服务架构如图所示。从图可以看出微服务的好处：每个微服务组件都是简单、灵活的，能够独立部署；微服务应用不需要一个庞大的应用服务器来支撑；微服务之间是松耦合的，内部是高内聚的，每个微服务很容易按需扩展；

Tomcat是Nginx配置的服务器集群名称，Nginx会根据权重把请求分配给名称为Tomcat的服务器集群上对应的http://192.168.11.14:8080和http://192.168.11.15:8080的Web应用上，权重越大，Web应用获得分配请求的概率越大。当高并发量的请求到达服务器的时候通过负载均衡的方式发送到集群中的某个服务器，这样就可能导致同一个用户的多次请求被发送到集群的不同服务器上，就会出现取不到Session数据的情况，于是Session的共享就成了一个问题。

从Redis集群架构中可以很容易地看出，首先将数据根据散列规则分配到6个槽中，然后根据循环冗余校验（Cyclic Redundancy Check，CRC）算法和取模算法将6个槽分别存储到3个不同的Master节点中，每个Master节点又配套部署了一个Slave节点，当一个Master节点出现问题后，Slave节点可以顶上。哨兵（Sentinel）进程监控Redis集群中Master主服务器工作的状态，在Master发生故障的时候，可以实现Master和Slave的切换，保证系统的高可用性。

SAVE命令会使用同步的方式生成RDB快照文件，将当前Redis实例的所有数据快照（Snap Shot）以RDB文件的形式保存到硬盘，默认情况下会把Redis数据持久化到dump.rdb文件中，并且在Redis服务器重启后自动读取dump.rdb文件。Redis的所有数据都保存在内存中，如果没有配置持久化功能，Redis重启后数据就会全部丢失，所以需要开启Redis的持久化功能，将数据保存到磁盘上，这样当Redis重启后，可以从磁盘中恢复数据。在接下来的可靠性配置中，可以配置从硬盘缓存写入硬盘的时间。

在生成的报告中有database（key所在的Redis数据库编号）​、type（key类型）​、key（键）​、size_in_bytes（key占用的内存大小）​、encoding（RDB编码方式）​、num_elements（key中的value的个数）​、len_largest_element（key中的value的长度）和expiry（key的过期时间）在笔者的计算机上，Redis配置文件保存在/usr/local/redis/conf/redis.conf目录下，读者需要根据实际情况进行修改。

SCAN命令是一个基于游标的迭代器，每次被调用之后都会向用户返回一个新游标，用户在下次迭代时需要使用这个新游标作为SCAN命令的游标参数，以此来延续之前的迭代过程。在本例中，我们设置cache_page2的过期时间是60s，然后我们不断用TTL来获取cache_page2的剩余时间，直至为-2，说明cache_page2已过期。在本例中，我们使用FLUSHALL命令删除了所有数据库中的key，查看数据库0中的key，发现都被删除了；EXISTS用于查看key是否存在，如果key存在则返回1，否则返回0。

HyperLogLog的优点是，在输入元素的数量非常多时，计算基数所需的空间总是很小。例如数据集{1，3，5，7，5，7，8}，那么这个数据集的基数集为{1，3，5，7，8}，基数为5。举个例子，有两个列表source和destination，列表source有元素a、b、c，列表destination有元素x、y、z，执行RPOPLPUSH source destination之后，列表source包含元素a、b，列表destination包含元素c、x、y、z，并且元素c被返回。

如果元素的位置按分数值递增（从小到大）的顺序排序，那么下标参数start和stop都以0为起始值，也就是说，下标0对应有序集合中的第一个元素，下标1对应有序集合中的第二个元素，以此类推。zscan命令用于迭代有序集合中的元素（包括元素本身及其分数值）​，返回的每个元素都是一个有序集合的元素（每个有序集合的元素由一个元素本身及其分数值所组成）​。zrevrange命令通过索引、分数返回有序集合中指定区间内的元素，其中元素的位置按分数值从大到小排列，其中具有相同分数值的元素按字典序的逆序排列。

brpop命令用于从列表中弹出最后一个元素。如果列表中没有元素，就会阻塞列表直到等待超时或发现列表中有可弹出的元素为止。如果在指定时间内没有任何元素被弹出，就会返回nil和等待时长；否则返回一个含有两个元素的列表，一个元素是被弹出元素所属的键，另一个元素是被弹出元素的值。2) "redis"3) "mysql"1) "mysql"2) "mysql"192.168.3.202:1> brpop mylistkey 100 # mylistkey不存在(nil)(132.00s)

如果数据不在缓存中，则去MySQL数据库查询，然后把查询到的数据缓存到Redis中再把结果返回给客户端，当下一次请求同样的数据时，就可以直接从Redis获取数据，避免了再去MySQL数据库查询，这从很大程度上提升了程序的响应性能。缓存击穿说的是热点数据过期，缓存雪崩说的是大面积的数据过期。如果大量请求查询的数据既不在缓存中，也不在MySQL数据库中，那么会造成每次的查询操作都会对数据库进行查询，因为不存在的数据是没有办法缓存的，于是就造成MySQL数据库承受高并发的查询请求，如图所示。

安全特性：互斥。在任何给定时刻，只有一个客户端可以持有锁。高可用性：无死锁。即使持有锁资源的客户端崩溃或分区了，也始终可以获得锁。容错性：容错能力。只要大多数Redis节点都处于运行状态，客户端就可以获取和释放锁。

同样可以把LFU算法理解为一个链表，新数据放在链表尾部，链表中的数据按照被使用的次数降序排列，被使用次数相同的数据按最近使用的时间降序排列，链表满的时候从链表尾部移出数据。Redis中使用的算法近似于LRU算法，比如修改配置文件maxmemory–samples=5，表示在Redis中随机采样5个键，然后从中淘汰最少使用的键，因此采样键的数量与Redis库中键的数量越接近，淘汰的规则就越接近LRU算法。Redis内存碎片的形成可能由两方面引起：一个是操作系统的内存分配机制，另一个是Redis的负载特征。

布隆过滤器(Bloom Filter)是一种概率型数据结构，它高效且占用空间小，常用于判断某个元素是否在一个集合中。不过，这个结果并不是完全准确的，只是一个具有概率性的结果，只要正确使用，在足够大体量的数据中这个概率的不完全准确几乎就可以忽略不计了。布隆过滤器用于解决缓存穿透的问题，比如故意搜索一些缓存和数据库中没有的数据、恶意穿透缓存形成对数据库的攻击。本章主要讲解它的安装和原理，后续我们会介绍它的用途。