深入了解Redis

今天药忘吃喽~ 2022-09-25 07:27 221阅读 0赞

![Center][]

本文将主要从Redis适用范围，与Memcached, Java容器对比，核心功能（Pipelining，

Pub/Sub，LRU，Transactions， Persistence， Replication），分布式架构设计，Cluster，

内部实现及数据结构来深入了解Redis，适用于已经了解并有Redis操作经验之程序员。

**1. Redis介绍 **

REmote DIctionary Server（Redis）是一个开源（BSD协议）的，使用ANSI C语言编写，

基于内存in-memory数据存储结构，可以当作NoSQL数据库，缓存和消息代理来使用。支持

多种数据结构，包括string, hashes, lists, set, sorted sets, bitmaps, hyperloglogs等。此外，

Redis还支持内置replication, LRU (Least Recently Used )算法管理缓存，Pub/Sub，部分

原子性操作，简单事务支持，基于磁盘的数据持久化以及3.0实现了分布式Redis支持HA，

久违的Redis Cluster。从2013年5月开始，Redis的开发由Pivotal公司主持。

**2. Redis之父Antirez**

![Center 1][]

饮水思源，Redis之父Salvatore Sanfilippo， 一名来自意大利西西里岛（Sicily）出生于

1977年的程序员，网名Antirez, 常居住于Catania。Antirez的IT职业生涯开始于系统管理员，

IT安全，并于Web 2.0的年代创立一家web网络公司，主要开发社交应用。之后，在一次实时

统计分析产品开发中，为了节省成本以及高性能扩展性，Antirez意识到需要一种支持多种复杂

数据结构的in-memory数据库，并且支持快速操作。Redis就此诞生并开源。之后，VM慧眼相

中了Redis, 并雇佣Antirez去全职开发，而之后又衍生出Pivotal公司，Antirez则继续主持Redis

开发。

**3. Redis适用场景 **

Redis通常被大家称为数据结构服务器，一种轻量级K/V数据存储，如我们上文介绍，支持丰富

的数据类型。Redis以其速度而闻名，这使得其称为某一特定领域适用的最优选择。

那请问大家是在什么场景下选用Redis呢？有小伙伴说大多数情况是大量数据需要缓存吧。

那又请问这种情况为什么不用Memcached呢？又或者干脆选择Java自带容器ArrayList, HashMap,

ConcurrentHashMap, HashSet呢？我们带着这两个问题往下看。

**3.1 互联网/社交**

Redis的用户多为互联网公司如Twitter, Weibo（微博）, Uber, StackOverflow, Airbnb, Alibaba等。

对于社交网站Twitter, Weibo，这些网站主要使用Redis进行高效的社交关系管理，缓存用户好友，

粉丝，关注等，并且可以通过Redis内置数据模型快速计算共同好友等。

我们先看各大社交网站Twitter, Weibo（微博是国内最大的Redis用户）。这些网站的每个用户都有

好友，粉丝，关注等，并且可以相互查看共同好友等。Redis可以用来帮助高效管理这些社交关系，

如求共同好友：

![Center 2][]

如上，Redis很方便的使用有序集合的交集功能实现。其中user:100000:follow为用户1的粉丝列表，

user:200000:follow为用户2的粉丝列表，out:100000:200000为交集共同好友列表。

又如另一个常用场景，电商各种计数，如商品维度计数（关注度，喜欢数，评论数，浏览数等）。

可以采用Redis的Hash类型，并借助其原子性操作来维护计数。

![Center 3][]

用户维度计数（动态，关注数，粉丝数，发帖数等）

![Center 4][]

当然除了这些互联网用途，Redis最常用的功能还是被当作缓存。提到缓存，大家当然会想到memcached。

**Redis v.s. Memcached**

*  数据类型与操作：Redis拥有更多丰富的数据结构支持与操作，而Memcached则需客户端自己处理并进行网络交互

![Center 5][]

*  内存使用率：简单K/V存储，Memcached内存利用率更高（使用了slab与大小不同的chunk来管理内存），而如果采用Redis Hash来存储则其组合压缩，内存利用率高于Memcached
 *  性能：总体来说，二者性能接近；Redis使用了单核（单线程IO复用，封装了AeEvent事件处理框架，实现了epoll,kqueue,select），Memcached采用了多核，各有利弊；当数据大于100K的时候，Memcached性能高于Redis
 *  数据持久化：Redis支持数据文件持久化，RDB与AOF两种策略；Memcached则不支持
 *  分布式：Memcached本身并不支持服务器端分布式，客户端只能借助一致性哈希分布式算法来实现Memcached分布式存储；当然Redis也是从3.0版本开始才支持服务器端cluster的，重要的是现在支持了。
 *  其他方面：Redis提供其他一些功能，如Pub/Sub, Queue, 简单Transacation, Replication等。

好了，千言不抵一图：

![Center 6][]

**Redis v.s. HashMap**

作为单机数据缓存，Java自带容器也是备选方案之一。我们进行压力测试，采用ConcurrentHashMap, Memcached（假设近似于Redis）, MySQL进行Benchmark。

![Center 7][]

具体数据如下：

![Center 8][]

可以看出，HashMap（上图显示为一根线）整体操作插入/查询/移除都 25 - 90倍快于Memcached/Redis; 而Memcached/Redis又 5 -12 倍快于MySQL InnoDB，符合预期。究其原因，Java容器单机内存直接读取，无网络开销，无须序列化等。

而反之之所以要用Redis的原因与好处则包括：

HashMap单机受限于内存容量，而正是Redis分布式之优势

*  HashMap当数据量超过一定限制后，需要妥善管理堆内存，不然会造成内存溢出或者Memory Leak；Redis则具备了文件持久性，以及Failover达到HA.
 *  HashMap只能受限于本机，而Redis天生分布式，可以让多个App Server访问，负载均衡。

所以Redis适合全部数据都在内存的场景包括需要临时持久化，尤其作为缓存来使用，并支持对缓存数据进行简单处理计算；如涉及Redis与RDBMS双向同步的话，则需要引入一些复杂度。

**4. Redis核心功能  **

**4.1 Pipelining **

Reids是一个TCP客户端-服务器模式，使用了应请求/响应协议，客户端与服务器的交互是阻塞的方式。

如下一个请求/响应事例，客户端发起4个INCR命令，服务端依次响应:

*  Client:INCR X

*  Server:1

*  Client:INCR X

*  Server:2

*  Client:INCR X

*  Server:3

*  Client:INCR X

*  Server:4

客户端与服务器通过网络连接，影响性能的关键因素往返时间（RTT Round Trip Time）则受限于网络

速度，如在网速较慢情况下RTT需要250毫秒，哪怕服务器性能卓越可以每秒处理1万个请求，然而整体

则客户端受网络制约只能每秒处理4个请求。即便使用了loopback接口节省RTT时间，但如果需要大量的

写操作，整体性能仍不可观。

Redis引入了批处理，管道（Pipelining），即客户端可以一次发送多个命令给服务器，无须等待服务器的

返回，而服务器端则回将请求放入一个有序的管道中，在执行完成后，一次性将返回值发送回客户端。

上述事例在使用Pipelining时如下，客户端通过缓冲区，一次性批量发送请求INCR，服务端则处理后统一

返回结果：

*  Client:INCR X

*  Server:1

*  Server:2

*  Server:3

*  Server:4

**4.2 Pub/Sub**

Reids提供了解耦消息的发布/订阅（Pub/Sub）通信模式，Pub/Sub采用事件作为基本通信机制，支持时间

（非同时），空间（无须知道具体位置）与同步（可异步模式）等解耦合，而发布与订阅则通过通道

（channel）来通信。

Antirez称，最初引入Pub/Sub是应用户需求，并且Redis本身的架构已经支持Pub/Sub, 所以只用了150行

代码就把Pub/Sub已实现的内部功能暴露称Pub/Sub API。

![Center 9][]

上图为较早版本中发布消息的一段代码片段，可以看出消息保存在一个List链表数据结构中，消息的类型为

messagebulk。另外，Redis也支持通配符模式匹配的订阅方式。

**Pub/Sub v.s. 消息中间件**

Reids的Pub/Sub与消息中间件相比，并不支持持久化，如系统宕机，网络问题等都会造成消息丢失；

Redis的消息多用于实时性较高的消息推送，并不保证可靠性。Redis的消息也无法支持水平扩展，

如通过增加consumer或者订阅者分组之类进行负载均衡。

性能方面，Redis的Pub/Sub与常用消息中间件如著名的RabbitMQ比较，则伯仲之间。

![Center 10][]

上图以处理10万个消息为例，在发布消息方面，RabbitMQ的耗时为Redis的75%；订阅消费消息

RabbitMQ耗时为Redis的86%，可见整体性能Redis已与消息中间件相近。

**4.3 LRU **

LRU(Least Recently Used) 最近最久未使用算法，是多数缓存系统当内存受限时自动清理旧数据的

常用常用算法之一。当Redis使用内存达到配置maxmemory时，Redis会根据配置的policy进行数据置

换处理，其中策略包括如下：

*  noenviction（不清除）

*  allkeys-lru（从所有数据集选择最近最少用）

*  volatile-lru（从设置过期时间的数据集选择最近最少用）

*  allkeys-random（所有数据集随机选取淘汰），

*  volatile-random（以设置过期时间数据集中随机），

*  volatile-ttl（从已设置过期过期时间的数据集中选择，非LRU）

Redis出于性能及节约内存考量，采用的并非严格意义LRU算法算法，而是近似的LRU算法，即Redis通过采样

一小部分键，然后在样本池中进行LRU。当然在Redis 3.0中，算法进一步改进为维护回收候选键池，改善了性

能同时更接近于LRU算法行为。

下图为官网提供Reids LRU性能测试，分别为理论LRU算法，10个样本的Redis 3.0 LRU算法，以及5个样本的

Redis 2.8与3.0算法的表现，其中浅灰色表示被置换出去的key，灰色为没有被置换的key，绿色为新增的key。

![Center 11][]

测试算法较简单，首先默认导入一定数目key，之后从第一个key遍历至最后一个key（相当于按时间顺序使用过了

当前遍历的key），之后再增加50%的数目触发清理策略。

可以看出，理论算法为最旧的50%被替换；同样样本为5情况下，3.0表现要优于2.8，3.0则更接近于理论值，

2.8算法则略为逊色。

**4.4 Transactions **

绝大多数NoSQL选择不支持事务，而Reids以命令方式（MULTI, EXEC, DISCARD, WA WATCH）提供了简单的

类/伪事务支持，之所以称之为类/伪事务，是因为Redis的只保证了事务必须ACID的C（一致性），I（隔离性），

并不保证A（原子性）与持久性（D），Redis事务甚至不支持回滚操作。

实际上，Redis的事务提供了一种将多个命令打包并置入事务队列，之后批量一次性，有序的按照先进先出

（FIFO）的顺序执行机制。事务在执行过程中不会被中断，所有命令命令执行之后，事务才结束。

**Transaction v.s. Pipelining**

Redis的Transaction与Pipelining都是批量执行命令，其主要差别为：

*  Pipelining主要是提供了网络层面的优化，客户端通过缓存多个命令并按批次发送给服务端处理以节省网络RTT（Round Trip TIme）时间开销，但这些命令并不保证事务性（Redis的单线程保证了单个命令本身是原子的，但多个client可以发起多个命令串行执行）。

*  Transaction则保证了一个client发起的事务中的命令可以连续的执行，中间不会插入其它client的命令，而此则受益于Redis的单线程模式，很容易实现。

所以，Transaction与Pipelining不但不冲突，对于批量命令甚至可以结合起来使用以达到网络优化及事务性

保证双重收效。

**4.5 Persistence**

Redis提供了两种常用的不同级别的磁盘持久化方式，RDB与AOF（Append-Only-File）。RDB持久化在指定

的时间间隔生成数据集的时间点快照（Snapshot）, AOF则类似RDMS的binlog日志。

由于单线程运行，Redis的RDB在备份时为不影响系统正常使用，借助Linux的fork命令及copy on write机制，

在fork出的子进程中进行备份写RDB文件。RDB的备份相对简单并且文件小，但无法保证数据的完整性，

如Redis在RDB的间隔时间内宕机，则面临丢失期间的数据。RDB较适合定期的归档备份及方便灾难恢复。

而AOF则提供了更好的持久性，Redis会将每个命令都追加到AOF文件中，并提供了三种持久化策略：

*  no fsync at all：Redis不调用fsync持久化, 操作系统决定同步时机（多数30秒）

*  fsync everysecond：每秒（延迟会两秒）进行一次fsync将缓冲区数据写入磁盘

*  fsync always：每个命令都进行同步，持久化写入磁盘，安全但较慢

AOF后台执行的方式与RDB类似，也是借助fork开启子进程进行写入AOF文件。为了减少AOF文件的大小，

Redis提了了文件压缩命令，另外支持日志重写，后台重构AOF文件以减少所需命令。

**4.6 Replication**

Redis支持Master/Slave主从配置，实现弱一致性，支持负载均衡，提高HA。Redis的Master可以对应

多个Slave, Slave也可以级联多个Slave。通常Master负责读写服务，Slave负责读服务，Master与Slave

间靠Replication定期来进行同步。

Redis的主从结构如下图所示DAG（有向无环图）

![Center 12][]

Slave会定期给Master发送SYNC命令进行同步，如果第一次连接则进行全量同步否则增量同步。

Master则启动后台快找进程saving来收集最近修改数据集所有命令并将其用db file传输给Slave。

另外，Redis从2.8版本开始支持中断后（网络断开等故障）的断点续传功能，无须重新同步。

Master维护一个内存缓冲区，主从服务器都维护一个复制偏移量（offset）和master run id，

当断开重新连接后，Master判断两个master run id是否相同，并根据指定的偏移量继续断点续传。

**5. Redis系统架构  **

**Sentinel架构**

Reids Sentinel诞生于2012年（Redis 2.4版本），建议在单机Redis或者客户端模式Cluster的时候

（非 3.0版本Redis Cluster）采用，作为HA, Failover来使用。

![Center 13][]

Sentinel主要提供了集群管理，包括监控，通知，自动故障恢复。如上图，当其中一个master无法

正常工作时，Sentinel将把一个Slave提升为Master, 从而自动恢复故障。而Sentinel本身也做到了

分布式，可以部署多个Sentinel实例来监控Redis实例（建议基数，至少3个Sentinel实例来监控一

组Redis Master/Slaves），多个Sentinel进程间通过Gossip协议来确定Master是否宕机，通过

Agreement协议来决定是否执行故障自动迁移以及重新选主，整体设计类似ZooKeeper

（应该是作者参考了当年的ZK吧？）。

**Cluster架构**

Redis Cluster开始设计于2011年（早于Sentinel），正式诞生于2015年愚人节，Redis 3.0，其中之

苦辣酸甜只有Antirez自己知道。

![Center 14][]

如上图，从3.0开始， Redis从一个单纯的NoSQL内存数据库变成了一个真正分布式NoSQL数据库。

概括来说，所谓分布式即支持数据分片，并且自动管理故障恢复（failover）与备份（replication）。

![Center 15][]

如上图Redis Cluster采用了无中心结构，每个节点都保存，共享数据和集群状态，每个节点与

其它所有节点通信，使用Gossip协议来传播及发现新节点，通过分区来提供一定程度可用性，

当某个node的Master宕机时，Cluste会自动选举一个Slave形成一个新的Master，这里应该是

借鉴，重用了Sentinel的功能。

另外，Redis Cluster并没有使用通常的一致性哈希, 而引入哈希槽的概念，Cluster中固定有

16384个slot, 每个key通过CRC16校验后对16384取模来决定其对应slot的位置，而每个node

负责一部分的slot管理，当node变化时，动态调整slot的分布，而数据则无须挪动。对于客户端

来说，client可以向任意一个实例请求，Cluster会自动定位需要访问的slot。

![Center 16][]

上图查询路由过程中，我们随机发送到任意一个Redis实例，这个实例会按照上文提到的CRC16

校验后取模定位，并转发至正确的Redis实例中。

![Center 17][]

然而，完全去中心化的架构同时也失去了一些灵活与总控能力，如可通过引入中央控制的自动发

现节点的变化及时Rebalance，分区粒度的备份，故障时分区自动调整，Gossip消息的通信开销，

路由表维护等。

值得一提的是，Redis的企业版/商业版Redis Labs Enterprise Cluster（RLEC）则似乎解决了我们

上述问题，如引入了中央控制Cluster Manager来管理，监控，分片迁移等工作, 引入高性能Proxy

隐藏幕后的路由实现等。

![Center 18][]

当然，前提是商业化付费版本了，我们也期待未来的开源Redis逐步可以引入这些概念。

**6. Redis 内部数据结构  **

Redis支持丰富的数据类型，并提供了大量简单高效的功能。为了高效使用Redis，开发设计人员需要对Redis的数据结构进行选型，如选择链表还是集合等。 下面我们快速了解一下Redis内部数据结构及其代码实现。Redis的底层数据结构总览图：

![Center 19][]

上图列出了Redis内部底层的一些重要数据结构，包括List, Set, Hash, String等。

来看几个比较核心的的数据结构。

**Redis Object **

Redis 3.x后的redisObject如下图所示：

![Center 20][]

redisObject定义中使用了位字段（bit filed）。简单来说，redisObject定义了类型，编码方式，

LRU时间，引用计数，\*ptr指向实际保存值指针。

*  type: redisObject的类型，字符串，列表，集合，有序集，哈希表等
 *  encoding: 底层实现结构，字符串，整数，跳跃表，压缩列表等
 *  ptr：实际指向保存值的数据结构

举个具体例子，redisObject\{type: REDIS\_LIST, encoding:REDIS\_ENCODING\_LINKEDLIST\},

这个对象是Redis列表，其值保存在一个链表中，ptr指针指向这个列表。

用惯了JVM的虚拟机，我们也来回顾一下C或者Redis是如何管理对象的。总体而言，Redis自己实现对象管理机制，并基于引用计数的垃圾回收。

![Center 21][]

毫无疑问的直接malloc开辟内存空间，设置type，encoding，引用计数默认1，设置默认LRU。可以看出refcount，猜测其内部是基于引用计数来管理释放内存空间的。事实要以代码为准。

![Center 22][]  
果不其然，Redis提供了incrRefCount与decrRefCount来管理对象跟踪对象的引用,  当减少引用时检测计数器为是否需要释放内存对象。

**RedisDB    **

RedisDB内部数据结构，封装了数据库层面的信息：

![Center 23][]

从redisDB来看，几个重要属性：

*  id：数据库内部编号，仅供内部操作使用，如AOF等
 *  dict：存放整个数据库的键值对，键为字符串，值为Redis的数据结构，如List, Set, Hash等。
 *  expires：键的过期时间

具体代码如下：

![Center 24][]

代码注释较为清晰，其中long long是C99标准新加的，64位长整型。

**RedisServer    **

RedisServer代码在Redis 3.0支持Cluster后变得较复杂，我们只列出部分代码。

![Center 25][]

总体来说包含如下几个大部分：

*  通用部分：如pid进程id，数据库指针，命令字典表，Sentinel模式标志位等
 *  网络信息：如port TCP监听端口，Cluster Bus监听socket, 已使用slot数量，Active的客户端列表, 当前客户端，Slaves列表等。
 *  其它信息：如AOF信息，统计信息, 配置信息（如已经配置总db数量dbnum等），日志信息，Replication配置，Pub/Sub, Cluster信息，Lua脚本信息配置等等。

**Redis Hash**

Redis的哈希表/字典是其核心数据结构之一，值得深入研究。Redis Hash数据结构， Hash新创建时，

在不影响效率情况下，Redis默认使用zipmap作为底层实现以节省空间，只有当size超出一定限制后

（hash-max-zipmap-entries ），Redis才会自动把zipmap转换为下图Hash Table。

![Center 26][]

上图字典的底层实现为哈希表，每个字典包含2个哈希表，ht\[0\], ht\[1\], 1号哈希表是在rehash过程中才

使用的。而哈希表则由dictEntry构成。

![Center 27][]

代码层面，每个字典包含了3个内部数据结构：

*  Dict：字典的根结构，包含了2个dictht，其中2作为rehashing之用
 *  Dictht：包含了linkedlist dictEntry
 *  DictEntry：包含了3个数据结构（double/uint64\_6/int64t）的链表，类似Java HashMap中的Entry结构

**Hash算法**

目前Redis中引入了一些经典哈希算法，而HashTable则主要为以下两种：

*  MurmurHash2 32bit算法：著名的非加密型哈希函数，能产生32位或64位哈希值，最新版本为
 *  MurmurHash3。该算法针对一个字符串进行哈希，可表现较强离散性。

*  基于djb算法实现散列算法：该算法较为简单，同样是将字符串转换为哈希值。主要利用字符串中
 *  的ASCII码与一个随机seed，进行变换得到哈希值。

评估一个哈希算法的优劣，主要看其哈希值的离散均匀效果以及消除冲突程度。Redis在HashTable中

引入的上述两种算法不失简单高效，离散均匀。

**Rehash**

类似Java中的HashMap, 当有新键值对添加到Redis字典时，有可能会触发rehash。Redis中处理哈希

碰撞的方法与Java一样，都是采用链表法，整个哈希表的性能则依赖于它的大小size和它已经保存节点

数量used的比率。

比率在1:1时，哈希表的性能最好，如果节点数量比哈希表大小大很多的话，则整个哈希表就退化成多个

链表，其性能优势全无。

![Center 28][]

上图的哈希表，平均每次失败查找需要访问5个节点。为了保持高效性能，在不修改键值对情况下，

需要进行rehash，目标是将ratio比率维持在1:1左右。

**Ratio ＝ Used / Size**

**rehash触发条件：**

*  自然rehash：ratio >= 1, 且变量dict\_can\_resize为真
 *  强制rehash：ratio大于dict\_force\_resize\_ratio（v 3.2.1版本为5）

**rehash执行过程：**

*  创建ht\[1\]并分配至少2倍于ht\[0\] table的空间
 *  将ht\[0\] table中的所有键值对迁移到ht\[1\] table
 *  将ht\[0\]数据清空，并将ht\[1\]替换为新的ht\[0\]

Redis哈希为了避免整个rehash过程中服务被阻塞，采用了渐进式的rehash，即rehash程序激活后，并不是

马上执行直到完成，而是分多次，渐进式（incremental）的完成。同时，为了保证并发安全，在执行rehash

中间执行添加时，新的节点会直接添加到ht\[1\]而不是ht\[0\], 这样保证了数据的完整性与安全性。

另一方面，哈希的Rehash在还提供了创新的（相对于Java HashMap）收缩（shrink）字典，当可用节点远远

大于已用节点的时候，rehash会自动进行收缩，具体过程与上面类似以保证比率始终高效使用。

**7. 总结**

本文从Redis的一些核心功能，适用范围与本质原因，分布式架构设计，Cluster，重要内部数据结构及代码片段等层面深入了解，在Redis使用方面，开发及设计人员通常需要对Redis有一定深度理解，对业务模型进行相应的数据结构选型，还需提前预估内存使用，是否需要持久化，分布式等。总体来说，Redis非常适合与传统关系型数据库结合使用，做高性能数据缓存，轻量级消息队列及跨机器共享内存。希望本文对Redis开发人员有所帮助，碰到一些实现细节，建议还是要深入其源代码一探究竟。有关其它Redis的命令操作及其它高级功能则可参考Redis官网。

**公众号：技术极客TechBooster**

![Center 29][]

[Center]: /images/20220718/06eff52b1e094f07a155481aacdd05c6.png
[Center 1]: /images/20220718/2dd7ea891546419dbc48ccd158feec08.png
[Center 2]: /images/20220718/7019d1029c764ca58fbb5172c50d3499.png
[Center 3]: /images/20220718/1c7027567e524134ac1ee2f87c32b853.png
[Center 4]: /images/20220718/00032bec635f46988c66898f97b0757e.png
[Center 5]: /images/20220718/cf80070389c34dce926ad3670b5b113b.png
[Center 6]: /images/20220718/dd1300fe51164a47bacf17a0685524eb.png
[Center 7]: /images/20220718/d7df7a6654f14bfda23d9b8783bff021.png
[Center 8]: /images/20220718/b76867cc1f4840c7a48d69bfa1e4ec1b.png
[Center 9]: /images/20220718/fe69ab264f0340c6aa7b3a9759e44f43.png
[Center 10]: /images/20220718/0978d7b21a6c400f903a51c95598218e.png
[Center 11]: /images/20220718/f5a024e92ac549baa1d978d36b9ed94c.png
[Center 12]: /images/20220718/25d1bc6e8da94a4b9929a88c062bbbf7.png
[Center 13]: /images/20220718/9a69637c5b2f43db9454ac28195a6087.png
[Center 14]: /images/20220718/a15ef31203734e5b909fa0d72f0c3e4f.png
[Center 15]: /images/20220718/76672da13f854d58a1f7dfbc757f85d4.png
[Center 16]: /images/20220718/9ce7b4000d22415cb00c7222f5eb62eb.png
[Center 17]: /images/20220718/13e14aade9e24740a7bf24a3f19e7184.png
[Center 18]: /images/20220718/eae5874343cb4b87a6c07c377cc7d371.png
[Center 19]: /images/20220718/a0f322010bdf4cf6956c32c823e154f0.png
[Center 20]: /images/20220718/4f9a4ad4abe24512879005e85d75fe5a.png
[Center 21]: /images/20220718/b84679594a014b53816d2bc08cf597f0.png
[Center 22]: /images/20220718/c855fea2e0b246288968486880deb3ec.png
[Center 23]: /images/20220718/fa72a2affc994e3d80f09b245ecd9991.png
[Center 24]: /images/20220718/afb3685a269f4012be65235596f63752.png
[Center 25]: /images/20220718/5bdf018f3af94540b2cd96bba690e76e.png
[Center 26]: /images/20220718/76ac170c1bdd4acfa9e63da1c30b19cd.png
[Center 27]: /images/20220718/a274c70c092f4e04ab6aafb86aab40c2.png
[Center 28]: /images/20220718/bd3b8c070a6b49208b81053cccc097bf.png
[Center 29]: /images/20220718/5554a52f7d4c4f16ba26f02c9ec2ea3a.png