lin启动完redis后怎么退回到命令行 redis怎么退出

转载

mob64ca140fd7c1 2023-08-23 16:31:09

文章标签 redis订阅怎么退出 redis 缓存数据 文章分类 Redis 数据库

redis单点吞吐量

单点TPS达到8万/秒，QPS达到10万/秒。

redis的5中存储类型

string、list、set、map(hash)、stored-set

redis的string类型

能表达3中类型：字符串、整数和浮点数。根据场景相互间自动转型，并且根据需要选取底层的承载方式

value内部以int、sds作为结构存储。int存放整型数据，sds存放字节/字符串和浮点型数据

sds内部结构：

用buf数组存储字符串的内容，但数组的长度会大于所存储内容的长度。会有一格专门存放”\0”(C标准库)作为结尾，还有预留多几个空的(即free区域)，当append字符串的长度小于free区域，则sds不会重新申请内存，直接使用free区域

扩容：当对字符串的操作完成后预期的串长度小于1M时，扩容后的buf数组大小=预期长度*2+1；若大于1M，则buf总是会预留出1M的free空间

value对象通常具有两个内存部分：redisObject部分和redisObject的ptr指向的sds部分。创建value对象时，通常需要为redisObject和sds申请两次内存。单对于短小的字符串，可以把两者连续存放，所以可以一次性把两者的内存一起申请了

redis的list类型

list类型的value对象内部以linkedlist或ziplist承载。当list的元素个数和单个元素的长度较小时，redis会采用ziplist实现以减少内存占用，否则采用linkedlist结构

linkedlist内部实现是双向链表。在list中定义了头尾元素指针和列表的长度，是的pop/push操作、llen操作的复杂度为O(1)。由于是链表，lindex类的操作复杂度仍然是O(N)

ziplist的内部结构

所有内容被放置在连续的内存中。其中zlbytes表示ziplist的总长度，zltail指向最末元素，zllen表示元素个数，entry表示元素自身内容，zlend作为ziplist定界符

rpush、rpop、llen，复杂度为O(1);lpush/pop操作由于涉及全列表元素的移动，复杂度为O(N)

redis的map类型

map又叫hash。map内部的key和value不能再嵌套map了，只能是string类型：整形、浮点型和字符串

map主要由hashtable和ziplist两种承载方式实现，对于数据量较小的map，采用ziplist实现

hashtable内部结构

主要分为三层，自底向上分别是dictEntry、dictht、dict

dictEntry：管理一个key-value对，同时保留同一个桶中相邻元素的指针，一次维护哈希桶的内部连

dictht：维护哈希表的所有桶链

dict：当dictht需要扩容/缩容时，用于管理dictht的迁移

哈希表的核心结构是dictht，它的table字段维护着hash桶，它是一个数组，每个元素指向桶的第一个元素(dictEntry)

set值的流程：先通过MurmurHash算法求出key的hash值，再对桶的个数取模，得到key对应的桶，再进入桶中，遍历全部entry，判定是否已有相同的key，如果没有，则将新key对应的键值对插入到桶头，并且更新dictht的used数量，used表示hash表中已经存了多少元素。由于每次插入都要遍历hash桶中的全部entry，所以当桶中entry很多时，性能会线性下降

扩容：通过负载因子判定是否需要增加桶数。负载因子=哈希表中已有元素/哈希桶数的比值。有两个阈值，小于1一定不扩容；大于5一定扩容。扩容时新的桶数目是现有桶的2n倍

缩容：负载因子的阈值是0.1

扩/缩容通过新建哈希表的方式实现。即扩容时，会并存两个哈希表，一个是源表，一个是目标表。通过将源表的桶逐步迁移到目标表，以数据迁移的方式实现扩容，迁移完成后目标表覆盖源表。迁移过程中，首先访问源表，如果发现key对应的源表桶已完成迁移，则重新访问目标表，否则在源表中操作

redis是单线程处理请求，迁移和访问的请求在相同线程内进行，所以不会存在并发性问题

ziplist内部结构

和list的ziplist实现类似。不同的是，map对应的ziplist的entry个数总是2的整数倍，奇数存放key，偶数存放value

ziplist实现下，由哈希遍历变成了链表的顺序遍历，复杂度变成O(N)

redis的set类型

set以intset或hashtable来存储。hashtable中的value永远为null，当set中只包含整数型的元素时，则采用intset

intset的内部结构

核心元素是一个字节数组，从小到大有序存放着set的元素

由于元素有序排列，所以set的获取操作采用二分查找方式实现，复杂度O(log(N))。进行插入时，首先通过二分查找得到本次插入的位置，再对元素进行扩容，再将预计插入位置之后的所有元素向右移动一个位置，最后插入元素，插入复杂度为O(N)。删除类似

redis的sorted-set类型

类似map是一个key-value对，但是有序的。value是一个浮点数，称为score，内部是按照score从小到大排序

内部结构以ziplist或skiplist+hashtable来实现

redis客户端与服务器的交互模式

串行的请求/响应模式

每一次请求的发送都依赖于上一次请求的相应结果完全接收，同一个连接的每秒吞吐量低

redis对单个请求的处理时间通常比局域网的延迟小一个数量级，所以串行模式下，单链接的大部分时间都处于网络等待

双工的请求/相应模式(pipeline)

适用于批量的独立写入操作。即可将请求数据批量发送到服务器，再批量地从服务器连接的字节流中一次读取每个响应数据，减少了网络延迟，所以单连接吞吐量较串行会提高一个数量级

原子化的批量请求/响应模式(事务)

客户端通过和redis服务器两阶段的交互做到批量命令原子执行的事务效果：入队操作(即服务器端先将客户端发送过来的连接对象暂存在请求队列中)和执行阶段(依次执行请求队列中的所有请求)

一个连接的请求在执行批量请求的过程中，不会执行其他客户端的请求

redis的事务不是一致的，没有回滚机制。如果中途失败，则返回错误信息，但已经成功执行的命令不会回滚

事务里面有可能会带有读操作作为条件，由于批量请求只会先入队列，再批量一起执行，所以一般读操作不会跟批量写请求一起执行，这时候就有可能会导致批量写之前和之后读到的数据不一致，这种可以通过乐观锁的可串行化来解决，redis通过watch机制实现乐观锁。具体实现过程看下一题

发布/订阅模式

发布端和订阅者通过channel关联

channel的订阅关系，维护在reids实例级别，独立于redisDB的key-value体系。所有的channel都由一个map维护，键是channel的名字，value是它所有订阅者client的指针链表

脚本化的批量执行(脚本模式)

redis通过watch机制实现乐观锁流程

将本次事务涉及的所有key注册为观察模式

执行只读操作

根据只读操作的结果组装写操作命令并发送到服务器端入队

发送原子化的批量执行命令EXEC试图执行连接的请求队列中的命令

如果前面注册为观察模式的key中有一个货多个，在EXEC之前被修改过，则EXEC将直接失败，拒绝执行；否则顺序执行请求队列中的所有请求

redis没有原生的悲观锁或者快照实现，但可通过乐观锁绕过。一旦两次读到的操作不一样，watch机制触发，拒绝了后续的EXEC执行

redis的网络协议

redis协议位于TCP层之上，即客户端和redis实例保持双工的连接，交互的都是序列化后的协议数据

redis处理命令的主要逻辑

redis服务器对命令的处理都是单线程的，但是I/O层面却面向多个客户端并发地提供服务，并发到内部单线程的转化通过多路复用框架来实现

首先从多路服用框架(epoll、evport、kqueue)中select出已经ready的文件描述符(fileDescriptor)

ready的标准是已有数据到达内核(kernel)、已准备好写入数据

对于上一步已经ready的fd，redis会分别对每个fd上已ready的事件进行处理，处理完相同fd上的所有事件后，再处理下一个ready的fd。有3中事件类型

acceptTcpHandler：连接请求事件

readQueryFromClient：客户端的请求命令事件

sendReplyToClient：将暂存的执行结果写回客户端

对来自客户端的命令执行结束后，接下来处理定时任务(TimeEvent)

aeApiPoll的等待时间取决于定时任务处理(TimeEvent)逻辑

本次主循环完毕，进入下一次主循环的beforeSleep逻辑，后者负责处理数据过期、增量持久化的文件写入等任务

redis的持久化机制

redis主要提供了两种持久化机制：RDB和AOF；

RDB

默认开启，会按照配置的指定时间将内存中的数据快照到磁盘中，创建一个dump.rdb文件，redis启动时再恢复到内存中。

redis会单独创建fork()一个子进程，将当前父进程的数据库数据复制到子进程的内存中，然后由子进程写入到临时文件中，持久化的过程结束了，再用这个临时文件替换上次的快照文件，然后子进程退出，内存释放。

需要注意的是，每次快照持久化都会将主进程的数据库数据复制一遍，导致内存开销加倍，若此时内存不足，则会阻塞服务器运行，直到复制结束释放内存；都会将内存数据完整写入磁盘一次，所以如果数据量大的话，而且写操作频繁，必然会引起大量的磁盘I/O操作，严重影响性能，并且最后一次持久化后的数据可能会丢失；

AOF

以日志的形式记录每个写操作(读操作不记录)，只需追加文件但不可以改写文件，redis启动时会根据日志从头到尾全部执行一遍以完成数据的恢复工作。包括flushDB也会执行。

主要有两种方式触发：有写操作就写、每秒定时写(也会丢数据)。

因为AOF采用追加的方式，所以文件会越来越大，针对这个问题，新增了重写机制，就是当日志文件大到一定程度的时候，会fork出一条新进程来遍历进程内存中的数据，每条记录对应一条set语句，写到临时文件中，然后再替换到旧的日志文件(类似rdb的操作方式)。默认触发是当aof文件大小是上次重写后大小的一倍且文件大于64M时触发；

当两种方式同时开启时，数据恢复redis会优先选择AOF恢复。一般情况下，只要使用默认开启的RDB即可，因为相对于AOF，RDB便于进行数据库备份，并且恢复数据集的速度也要快很多。

开启持久化缓存机制，对性能会有一定的影响，特别是当设置的内存满了的时候，更是下降到几百reqs/s。所以如果只是用来做缓存的话，可以关掉持久化。

redis内存分析的设计思路

主要有3种方式可以实现

keys命令：获取到所有的key，再根据key获取所有的内容。缺点是如果key数量特别多，则会导致redis卡住影响业务

aof：通过aof文件获取到所有数据。缺点是有一些redis实例写入频繁，不适合开启aof，并且文件可能特别大，传输、解析效率差

rdb：使用bgsave获取rdb文件，然后解析。缺点是bgsave在fork子进程时有可能会卡住主进程。当对于其他两种，在低峰期在从节点做bgsave获取rdb文件，相对安全可靠。

设计思路：

在访问低峰期时根据redis获取rdb文件

解析rdb文件

根据相对应的数据结构及内容，估算内容消耗等

统计并生成报表

开源框架：https://github.com/xueqiu/rdr

redis内存估算

基础的数据类型：sds、dict、intset、zipmap、adlist、quicklist、skiplist

举例：以key为hello，value为world，类型是string，它的内存使用：

一个dictEntry的消耗(有2个指针，一个int64的内存消耗)，RedisDB就是一个大dict，每对kv都是其中的一个entry；

一个robj的消耗(有1指针，一个int，以及几个使用位域的字段共消耗4字节)，robj是为了在同一个dict内能够存储不同类型的value，而使用的一个通用的数据结构，全名是RedisObject；

存储key的sds消耗(存储header以及字符串长度+1的空间，header长度根据字符串长度不同也会有所不同)，sds是Redis中存储字符串使用的数据结构；

存储过期时间消耗(也是存储为一个dictEntry，时间戳为int64)；

存储value的sds消耗，根据数据结构不同而不同；

前四项基本是存储任何一个key都需要消耗的，最后一项根据value的数据结构不同而不同；

redis集群(redis cluster)

redis3以后，节点之间提供了完整的sharding(分片)、replication(主备感知能力)、failover(故障转移)的特性

配置一致性：每个节点(Node)内部都保存了集群的配置信息，存储在clusterState中，通过引入自增的epoch变量来使得集群配置在各个节点间保持一致

sharding数据分片

将所有数据划分为16384个分片(slot)，每个节点会对应一部分slot，每个key都会根据分布算法映射到16384个slot中的一个，分布算法为slotId=crc16(key)%16384

当一个client访问的key不在对应节点的slots中，redis会返回给client一个moved命令，告知其正确的路由信息从而重新发起请求。client会根据每次请求来缓存本地的路由缓存信息，以便下次请求直接能够路由到正确的节点

分片迁移：分片迁移的触发和过程控制由外部系统完成，redis只提供迁移过程中需要的原语支持。主要包含两种：一种是节点迁移状态设置，即迁移钱标记源、目标节点；另一种是key迁移的原子化命令

failover故障转移

故障发现：节点间两两通过TCP保持连接，周期性进行PING、PONG交互，若对方的PONG相应超时未收到，则将其置为PFAIL状态，并传播给其他节点

故障确认：当集群中有一半以上的节点对某一个PFAIL状态进行了确认，则将起改为FAIL状态，确认其故障

slave选举：当有一个master挂掉了，则其slave重新竞选出一个新的master。主要根据各个slave最后一次同步master信息的时间，越新表示slave的数据越新，竞选的优先级越高，就更有可能选中。竞选成功之后将消息传播给其他节点。

集群不可用的情况：

集群中任意master挂掉，且当前master没有slave。

集群中超过半数以上master挂掉。

普通哈希算法和一致性哈希算法对比

普通哈希：也称硬哈希，采用简单取模的方式，将机器进行散列，这在cache环境不变的情况下能取得让人满意的结果，但是当cache环境动态变化时，这种静态取模的方式显然就不满足单调性的要求(当增加或减少一台机子时，几乎所有的存储内容都要被重新散列到别的缓冲区中)。

一致性哈希：将机器节点和key值都按照一样的hash算法映射到一个0~2^32的圆环上。当有一个写入缓存的请求到来时，计算Key值k对应的哈希值Hash(k)，如果该值正好对应之前某个机器节点的Hash值，则直接写入该机器节点，如果没有对应的机器节点，则顺时针查找下一个节点，进行写入，如果超过2^32还没找到对应节点，则从0开始查找(因为是环状结构)。为了更可能的满足平衡性，可以引入虚拟节点，即一个实体节点映射到多个虚拟节点。

缓存雪崩，缓存穿透，缓存并发，缓存预热，缓存算法

缓存雪崩：可能是因为数据未加载到缓存中，或者缓存同一时间大面积的失效，从而导致所有请求都去查数据库，导致数据库CPU和内存负载过高，甚至宕机。解决思路：

加锁计数(即限制并发的数量，可以用semphore)或者起一定数量的队列来避免缓存失效时大量请求并发到数据库。但这种方式会降低吞吐量。

分析用户行为，然后失效时间均匀分布。或者在失效时间的基础上再加1~5分钟的随机数。

如果是某台缓存服务器宕机，则考虑做主备。

缓存穿透：指用户查询数据，在数据库没有，自然在缓存中也不会有。这样就导致用户查询的时候，在缓存中找不到，每次都要去数据库中查询。解决思路：

如果查询数据库也为空，直接设置一个默认值存放到缓存，这样第二次到缓冲中获取就有值了，而不会继续访问数据库。设置一个过期时间或者当有值的时候将缓存中的值替换掉即可。

可以给key设置一些格式规则，然后查询之前先过滤掉不符合规则的Key。

缓存并发：如果网站并发访问高，一个缓存如果失效，可能出现多个进程同时查询DB，同时设置缓存的情况，如果并发确实很大，这也可能造成DB压力过大，还有缓存频繁更新的问题。解决思路：

对缓存查询加锁，如果KEY不存在，就加锁，然后查DB入缓存，然后解锁；其他进程如果发现有锁就等待，然后等解锁后返回数据或者进入DB查询。

缓存预热：目的就是在系统上线前，将数据加载到缓存中。解决思路：

数据量不大的话，在系统启动的时候直接加载。