Redis使用经验、常用架构对比以及标准原生redis集群解析

爱被打了一巴掌 2022-03-16 09:44 131阅读 0赞

**Redis特点：**Redis作为一个非关系型数据库，其不支持sql但以key-value键值对的形式存储数据性能非常好、读写速度非常快，读的速度能达到110000次/s,写的速度能达到81000次/s ，并且它的数据类型也很多，很好的满足我们对数据类型的需求。而且redis中的读写操作是单线程的，原子性的，并且通过MULTI和EXEC指令可以进行一个事物的封装操作，这就保证了其安全性也非常好。将其定义为内存型数据库，读写直接对内存操作远远高于磁盘I/O的读写速度，但它依然支持持久化进行一个数据备份。可将其作为缓存也可以作为数据库使用。并且它很好的支持集群架构master-slave模式，可用性和灾备方面效果都很好。

**Redis功能：**持久化数据库、缓存中间件、消息中间件（消息队列、发布订阅等模式）等

**Redis数据类型以及操作指令：**

<table> 
 <tbody> 
 <tr> 
 <td style="width:116px;">数据类型</td> 
 <td style="width:448px;">特点</td> 
 <td style="width:173px;">应用场景</td> 
 <td style="width:342px;">部分操作命令</td> 
 </tr> 
 <tr> 
 <td style="width:116px;">String</td> 
 <td style="width:448px;"> 操作字符串，对整数、浮点数，自增increment、自减decrement </td> 
 <td style="width:173px;">String可以用作普通的K-V、计数类</td> 
 <td style="width:342px;"> <a href="http://www.runoob.com/redis/strings-set.html" rel="nofollow">SET key value</a>&nbsp;设置key <a href="http://www.runoob.com/redis/strings-get.html" rel="nofollow">GET key</a>&nbsp;获取key <a href="http://www.runoob.com/redis/strings-setex.html" rel="nofollow">SETEX key seconds value</a>&nbsp;加过期时间 <a href="http://www.runoob.com/redis/strings-incr.html" rel="nofollow">INCR key</a>&nbsp;指定key自增1 <a href="http://www.runoob.com/redis/strings-decr.html" rel="nofollow">DECR key</a>指定key自减1 </td> 
 </tr> 
 <tr> 
 <td style="width:116px;"> List </td> 
 <td style="width:448px;">链表。两端推入或弹出，根据偏移量进行修剪trim，读取单个或者多个元素，根据值查找或者移除元素</td> 
 <td style="width:173px;">List可以用作消息队列、粉丝/关注列表等</td> 
 <td style="width:342px;"> lpush key value[value...]将一个或多个value插入到列表的表头 lpop key移除并返回列表key的头元素（后进先出），若key不存在返回nil &nbsp; </td> 
 </tr> 
 <tr> 
 <td style="width:116px;"> Hash </td> 
 <td style="width:448px;">包含键值对的无序散列表。添加、获取、移除、单个键值对，获取所有键值对</td> 
 <td style="width:173px;">Hash可以用作对象如商品、经纪人等，包含较多属性的信息</td> 
 <td style="width:342px;"> <a href="http://www.runoob.com/redis/hashes-hmset.html" rel="nofollow">HMSET key field1 value1 [field2 value2 ]</a>&nbsp;同时将多个 field-value (域-值)对设置到哈希表 key 中 <a href="http://www.runoob.com/redis/hashes-hget.html" rel="nofollow">HGET key field</a>&nbsp;获取存储在哈希表中指定字段的值 </td> 
 </tr> 
 <tr> 
 <td style="width:116px;"> Set </td> 
 <td style="width:448px;"> 无序且唯一的集合。添加、获取、移除、单个元素；检查一个元素是否存在于集合中，计算交集，并集，差集，从集合里面随机获取元素 </td> 
 <td style="width:173px;">Set可以用于推荐</td> 
 <td style="width:342px;"> <a href="http://www.runoob.com/redis/sets-sadd.html" rel="nofollow">SADD key member1 [member2]</a>&nbsp;向集合添加一个或多个成员 <a href="http://www.runoob.com/redis/sets-scard.html" rel="nofollow">SCARD key</a>&nbsp;获取集合的成员数 </td> 
 </tr> 
 <tr> 
 <td style="width:116px;"> SortSet </td> 
 <td style="width:448px;">按照元素分值排列的有序集合。添加，获取，删除，单个元素，根据分值范围，或者成员来获取元素</td> 
 <td style="width:173px;">Sorted Set可以用于排行榜等</td> 
 <td style="width:342px;"> <a href="http://www.runoob.com/redis/sorted-sets-zadd.html" rel="nofollow">ZADD key score1 member1 [score2 member2]</a>&nbsp;向有序集合添加一个或多个成员，或者更新已存在成员的分数 <a href="http://www.runoob.com/redis/sorted-sets-zcard.html" rel="nofollow">ZCARD key</a>&nbsp;获取有序集合的成员数 </td> 
 </tr> 
 </tbody> 
</table>

**数据持久化：**

**快照：**

1、满足条件‘指定时间段内有指定数量的写操作执行‘ 特点是每次都将全量的数据保存到磁盘上有异步BGSAVE和同步SAVE两种方式，

2、大量数据不适合做快照，几个G尚可，几十G就会，导致Redis的性能降低。

3、基本上是要求 剩余内存>redis内存，性能才会比较高。

4、创建BGSAVE进程的过程是阻塞的，根据虚拟机架构的不同也会导致创建bgsave的时间不同，我们常用的KVM架构：1G=10～20毫秒，XEN架构 1g=200~300毫秒，创建BGSAVE进程的过程是阻塞的

**AOF：**

1、将所有数据库的写命令，写入一个文件里面

2、三种同步策略（从不同步、每秒同步一次、每写入一个命令就同步一次）根据性能和数据重要性决定。

3、文件较大，恢复慢。

4、后台进程： Bgrewriteaof，跟BGSAVE原理一样

**性能&内存优化以及使用注意点：**

目标：节省内存，提升性能。方法：减少体积 （KEY 和 Value）

1、尽量使用短结构，每个Key增加过期时间

2、存储的Key一定要设置超时时间：如果应用将Redis定位为缓存Cache使用，对于存放的Key一定要设置超时时间！因为若不设置，这些Key会一直占用内存不释放，造成极大的浪费，而且随着时间的推移会导致内存占用越来越大，直到达到服务器内存上限！另外Key的超时长短要根据业务综合评估，而不是越长越好！(某些业务要求key长期有效。可以在每次写入时，都设置超时时间，让超时时间顺延。)

3、对于必须要存储的大文本数据一定要压缩后存储：对于大文本【超过500字节】写入到Redis时，一定要压缩后存储！大文本数据存入Redis，除了带来极大的内存占用外，在访问量高时，很容易就会将网卡流量占满，进而造成整个服务器上的所有服务不可用，并引发雪崩效应，造成各个系统瘫痪！

4、线上Redis禁止使用Keys正则匹配操作：Redis是单线程处理，在线上KEY数量较多时，操作效率极低【时间复杂度为O(N)】，该命令一旦执行会严重阻塞线上其它命令的正常请求，而且在高QPS情况下会直接造成Redis服务崩溃！如果有类似需求，请使用scan命令代替！

5、可靠的消息队列服务：Redis List经常被用于消息队列服务。假设消费者程序在从队列中取出消息后立刻崩溃，但由于该消息已经被取出且没有被正常处理，那么可以认为该消息已经丢失，由此可能会导致业务数据丢失，或业务状态不一致等现象发生。为了避免这种情况，Redis提供了RPOPLPUSH命令，消费者程序会原子性的从主消息队列中取出消息并将其插入到备份队列中，直到消费者程序完成正常的处理逻辑后再将该消息从备份队列中删除。同时还可以提供一个守护进程，当发现备份队列中的消息过期时，可以重新将其再放回到主消息队列中，以便其它的消费者程序继续处理。

6、谨慎全量操作Hash、Set等集合结构：在使用HASH结构存储对象属性时，开始只有有限的十几个field，往往使用HGETALL获取所有成员，效率也很高，但是随着业务发展，会将field扩张到上百个甚至几百个，此时还使用HGETALL会出现效率急剧下降、网卡频繁打满等问题【时间复杂度O(N)】,此时建议根据业务拆分为多个Hash结构；或者如果大部分都是获取所有属性的操作,可以将所有属性序列化为一个STRING类型存储！同样在使用SMEMBERS操作SET结构类型时也是相同的情况！

7、根据业务场景合理使用不同的数据结构类型：目前Redis支持的数据库结构类型较多：字符串（String），哈希（Hash），列表（List），集合（Set），有序集合（Sorted Set）, Bitmap, HyperLogLog和地理空间索引（geospatial）等,需要根据业务场景选择合适的类型，常见的如：String可以用作普通的K-V、计数类；Hash可以用作对象如商品、经纪人等，包含较多属性的信息；List可以用作消息队列、粉丝/关注列表等；Set可以用于推荐；Sorted Set可以用于排行榜等！

8、Key的命名： :分隔符 是最常见的分割符，也有.  /   |  但是没有分隔符的长KEY是不对的？为什么呢？合适的key，便于查看，统计，排错。":"-作为key分隔符，方便客户端工具作为目录分级

**常用的命令地址：**

[1][][、][1][http://doc.redisfans.com][1]

[2][1][、][1][https://redis.io/commands][1]

3、[https://github.com/antirez/redis][https_github.com_antirez_redis]

**集群架构：**

**阿里云redis集群架构：**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x5bHk0NDEz_size_16_color_FFFFFF_t_70][]

架构解析:

￭Master-Slave +redis-proxy+Configserver

解析:

￭redis\-proxy 无状态，一个集群根据集群规格可挂多个proxy节点。(节点水平可扩)

￭redis-config 双节点，支持容灾。

￭提供独立的组件HA负责集群的主备切换等。

￭阿里云的redis集群基于proxy，用户对路由信息无感知，同时提供vip给客户端访问，客户端只需一个连接地址即可，无须关心proxy访问的负载均衡等。

￭性能逼近原生redis cluster db节点

￭ 自研命令:举例:**info key** **user\_key**

用于查某个key所在的slot和db

**Redis哨兵模式：**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x5bHk0NDEz_size_16_color_FFFFFF_t_70 1][]

架构解析:

￭在主从架构的基础上，增加了监听功能，保障服务的高可用

￭每个实例数据全量存储，容易形成木桶效应且浪费内存

￭为了同时保障服务高可用和高并发，主流模式是多哨兵模式但仍不能避免木桶效应

**原生的redis cluster架构图：**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x5bHk0NDEz_size_16_color_FFFFFF_t_70 2][]

架构解析:

￭无proxy层,M和S之间使用异步replication通讯

￭线性扩展:官方推荐的最大节点可达1000个

￭ 高可用性:当某个Master节点失效时，集群能将投票产生的Slave提升为Master接管服务

￭数据存储特点:分布式存储,集群被划分成16384个slot(hash槽)，集群中每个M节点负责16384个槽位的其中一部分

￭数据分布:算法hash\_slot = crc16(key) mod 16384，尽可能保证数据能被平均分布

￭支持数据增量同步

￭数据一致性: write命令提交到Master，Master执行完毕后向Client返回“OK”，但由于异步replication，此时数据还没传播给Slave；如果此时Master不可达的时间超过阀值，此时集群将触发对应的slave选举为新的Master，此时没有replication同步到slave的数据将丢失.(其它模式对比)

￭支持读写分离

￭协议解析:进程之间使用**流言协议（****gossip protocols)**来接收关于主服务器是否下线的信息， 并使用**投票协议（****agreement protocols****）**来决定是否执行自动故障迁移， 以及选择哪个从服务器作为新的主服务器。

￭支持事务

# **redis cluster集群主要参数解析：** #

￭ port:通讯端口

￭ pidfile:pid进程

￭ logfile:日志输出

￭ cluster-enabled:yes 开启集群模式

￭ cluster-config\-file:记录了节点信息

￭ cluster-require-full-coverage:no 设置非全槽覆盖,保障高容灾

￭ cluster-node-timeout:请求超时时间设定(默认5000毫秒)

￭ appendonly:开启aof持久化需根据需要手动开启(默认开启RDB数据持久化)

￭ bind:提供服务的ip(尽可能不要使用0.0.0.0或者127.0.0.1这种)

￭ readOnly:是否开启读写分离(默认不开启)

￭ maxmemory-policy:key删除策略

其它参数列表: daemonize,save等

**Redis事务常用命令介绍：**

￭MULTI:用于标记事务块的开始。Redis会将后续的命令逐个放入队列中，然后才能使用EXEC命令原子化地执行这个命令序列。

￭EXEC:在一个事务中执行所有先前放入队列的命令，然后恢复正常的连接状态。

￭DISCARD:清除所有先前在一个事务中放入队列的命令，然后恢复正常的连接状态

￭WATCH:当某个事务需要按条件执行时，就要使用这个命令将给定的键设置为受监控的

￭UNWATCH:清除所有先前为一个事务监控的键,如果调用了EXEC或DISCARD命令，那么就不需要手动调用UNWATCH命令

**Redis和关系型数据库同步原理(一)：**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x5bHk0NDEz_size_16_color_FFFFFF_t_70 3][]

**Redis和关系型数据库同步原理(二)：**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x5bHk0NDEz_size_16_color_FFFFFF_t_70 4][]

**两个概念:缓存穿透和缓存雪崩：**

**￭缓存穿透****:**缓存穿透是指查询一个一定不存在的数据，由于缓存是不命中时需要从[数据库][Link 1]查询，查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到数据库去查询，造成缓存穿透

￭**缓存雪崩****:**当缓存服务器重启或者大量缓存集中在某一个时间段失效，这样在失效的时候，会给关系型数据库带来很大压力，造成数据库后端故障，从而引起应用服务器雪崩

**可能导致缓存雪崩的场景:**

￭ 大面积key同时失效

￭ ddos攻击

￭ 程序bug

￭ 硬件故障

￭ 其它

**缓存穿透和缓存雪崩的应对方法:**

应对缓存穿透:

￭布隆过滤

￭缓存空对象

应对缓存雪崩：

￭加锁排队

￭数据预热

￭做二级缓存，或者双缓存策略

￭不设置过期时间

[1]: https://redis.io/commands
[https_github.com_antirez_redis]: https://github.com/antirez/redis
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x5bHk0NDEz_size_16_color_FFFFFF_t_70]: /images/20220316/5327d6c3f17f44c89efab6a954b34f7a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x5bHk0NDEz_size_16_color_FFFFFF_t_70 1]: /images/20220316/6520f0295cf74d92b0c88761c04369d1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x5bHk0NDEz_size_16_color_FFFFFF_t_70 2]: /images/20220316/600cd07254494c2eb1f79439c33a3b40.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x5bHk0NDEz_size_16_color_FFFFFF_t_70 3]: /images/20220316/2bdbd144567a426cbb3bee56d74fdeb7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x5bHk0NDEz_size_16_color_FFFFFF_t_70 4]: /images/20220316/1c344d301ed94b3e8cc9cf6ff9a4fec8.png
[Link 1]: http://lib.csdn.net/base/mysql