干货分享!redis原理总结

5、如果前面注册为观察模式的key中有一个货多个,在EXEC之前被修改过。

概述

总结一下redis的原理,适合大家以后装逼!

redis单点吞吐量

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

redis的5种存储类型

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

redis的string类型

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

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

redis的list类型

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

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

3、ziplist的内部结构

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

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

redis的map类型

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

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

3、hashtable内部结构

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

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

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

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

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

4、ziplist内部结构

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

redis的set类型

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

2、intset的内部结构

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

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

redis的sorted-set类型

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

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

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

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

2、执行只读操作

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

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

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

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

redis的持久化机制

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

1、RDB

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

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

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

2、AOF

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

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

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

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

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

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

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

3、sharding数据分片

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

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

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

4、failover故障转移

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

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

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

5、集群不可用的情况:

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

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

上面很多内容毫无意义,平时不会怎么用到,也记不住,但是却是大家需要了解的...

说句实在,还是值得收藏的!

后期会分享更多运维DBA和devops内容,感兴趣的朋友可以关注下!

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20181019A0Z3HA00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券