压缩列表Ziplist2.

数据类型可以存储的值操作应用场景STRING字符串、整数或者浮点数对整个字符串或者字符串的其中一部分执行操作

对整数和浮点数执行自增或者自减操作LIST列表从两端压入或者弹出元素

对单个或者多个元素进行修剪

只保留一个范围内的元素实现消息队列、任务队列、聊天记录等SET无序集合添加、获取、移除单个元素

计算交集、并集、差集

从集合里面随机获取元素存储不重复的元素集合如用户关注列表、标签集合等HASH包含键值对的无序散列表添加、获取、移除单个键值对

获取所有键值对

检查某个键是否存在存储对象的多个属性如用户信息用户名、密码、邮箱等ZSET有序集合添加、获取、删除元素

根据分值范围或者成员来获取元素

计算一个键的排名实现排行榜、优先级队列、时间线等Bitmap位图一种基于字符串的二进制数据结构通过位操作实现高效的存储和查询用户在线状态、用户签到、统计用户行为、布隆过滤器等HyperLogLog超日志用于统计基数集合中不重复元素的数量的近似算法占用空间小精度高统计独立访客数量、不重复的用户行为、广告点击去重Streams流日志结构的数据类型支持消息的持久化、消费组和消息确认等特性实现分布式消息队列、事件溯源、日志存储等Geo借助zset存储和操作地理空间数据的类型实现“附近的人”或“附近的餐厅”功能。

地理围栏和实时位置追踪

SetZSet底层实现主要依赖两种数据结构压缩列表Ziplist

跳跃列表SkipList。

具体使用哪种结构取决于有序集合的大小和元素的特性。

压缩列表Ziplist

每个集合元素使用两个紧挨在一起的压缩列表节点来保存第一个节点保存元素的成员第二个节点保存元素的分值。

并且压缩列表内的集合元素按分值从小到大的顺序进行排列小的放置在靠近表头的位置大的放置在靠近表尾的位置。

使用压缩列表作为底层实现

以上两个条件也可以通过Redis配置文件zset-max-ziplist-entries

选项和

压缩列表是一种内存高效的数据结构通过紧凑的内存布局存储元素和分数。

每个元素的成员和分数分别存储在相邻的节点中。

跳跃列表SkipList

使用跳跃列表作为底层实现。

跳跃列表是一种基于链表的多级索引结构通过随机化的方式构建多级索引从而实现快速查找、插入和删除操作。

O(log

O(N)。

双向指针每一层不仅有向前指针还有向后指针便于快速回溯。

随机化级别生成随机函数在插入新节点时被用来决定节点是否升级到更高层级以平衡空间开销和访问速度。

字典的键保存元素的值字典的值则保存元素的分值用于快速查找成员对应的分数时间复杂度为

object

相对于链表结构的跳跃表B树在每个节点上存储的数据量更多所以通常会占用更多的存储空间。

如果查询效率是首要考虑的因素并且可以承担更高的空间占用可以选择B树

动态转换机制

当有序集合的元素数量或成员长度超出压缩列表的限制时自动转换为跳跃列表。

这种机制确保了在不同场景下都能高效地存储和操作有序集合。

二、应用场景

数据丢失风险由于是定期快照最后一次快照之后的数据可能会丢失。

fork

操作开销在数据量较大时fork

适用于对数据一致性要求不高但对恢复速度和磁盘空间占用敏感的场景。

AOF

可以保证最后一次写操作之前的数据不会丢失。

细粒度恢复支持更细粒度的数据恢复适合需要高可靠性的场景。

可读性强AOF

文件较大AOF

持久化需要设置同步选项从而确保写命令同步到磁盘文件上的时机。

这是因为对文件进行写入并不会马上将内容同步到磁盘上而是先存储到缓冲区然后由操作系统决定什么时候同步到磁盘。

有以下同步选项

选项同步频率always每个写命令都同步everysec每秒同步一次no让操作系统来决定何时同步

always

选项并不能给服务器性能带来多大的提升而且也会增加系统崩溃时数据丢失的数量。

yes就可以打开AOF功能。

如果有写操作如SET等redis就会被追加到AOF文件的末尾。

默认的AOF持久化策略是每秒钟fsync一次fsync是指把缓存中的写指令记录到磁盘中因为在这种情况下redis仍然可以保持很好的处理性能即使redis故障也只会丢失最近1秒钟的数据。

如果在追加日志时恰好遇到磁盘空间满、inode满或断电等情况导致日志写入不完整也没有关系redis提供了redis-check-aof工具可以用来进行日志修复。

因为采用了追加方式如果不做任何处理的话AOF文件会变得越来越大为此redis提供了AOF文件重写rewrite机制即当AOF文件的大小超过所设定的阈值时redis就会启动AOF文件的内容压缩只保留可以恢复数据的最小指令集。

举个例子或许更形象假如我们调用了100次INCR指令在AOF文件中就要存储100条指令但这明显是很低效的完全可以把这100条指令合并成一条SET指令这就是重写机制的原理。

在进行AOF重写时仍然是采用先写临时文件全部完成后再替换的流程所以断电、磁盘满等问题都不会影响AOF文件的可用性

直接执行BGREWRITEAOF命令那么redis会生成一个全新的AOF文件其中便包括了可以恢复现有数据的最少的命令集。

。

混合持久化RDB

两种方式可以同时使用在这种情况下如果redis重启的话则会优先采用AOF方式来进行数据恢复这是因为AOF方式的数据恢复完整度更高。

快速启动由于开头为

的删除策略主要分为过期键的删除策略和内存淘汰策略。

以下是详细说明

Redis

原理在设置键的过期时间时创建一个定时事件。

当时间到达时自动执行删除操作。

优点对内存友好过期键会尽快被删除释放内存。

缺点对

CPU

原理不主动删除过期键仅在访问键时检查是否过期如果过期则删除。

优点对

CPU

友好只有在访问时才会检查和删除过期键。

缺点对内存不友好过期键可能长时间占用内存。

1.3

原理每隔一段时间随机检查一定数量的键删除其中的过期键。

默认每秒检查

次100ms

第一种是情性删除在设置该key过期时间后我们不去管它当需要该key时我们在检查其是否过期如果过期我们就删掉它反之返回该key。

第二种是定期删除就是说每隔一段时间我们就对一些key进行检查删除里面过期的key

定期删除

策略描述volatile-lru从已设置过期时间的数据集中挑选最近最少使用的数据淘汰volatile-lfu从已设置过期时间的数据集中淘汰访问频率最低的键Redis

4.0volatile-ttl从已设置过期时间的数据集中挑选将要过期的数据淘汰volatile-random从已设置过期时间的数据集中任意选择数据淘汰allkeys-lru从所有数据集中挑选最近最少使用的数据淘汰allkeys-lfu从所有键中淘汰访问频率最低的键

Redis

4.0allkeys-random从所有数据集中任意选择数据进行淘汰noeviction禁止驱逐数据

Redis

Replication功能。

在旧版本中从节点重新连接主节点时需要重新同步整个数据集而

Redis

volatile-lfu。

这些策略通过记录键的访问频率来决定哪些键应该被优先淘汰。

非阻塞删除命令

的支持允许在这些环境下更好地运行。

性能优化对现有缓存淘汰策略进行了优化使其更高效、更准确。

八、事务

的事务功能允许将一组命令打包并一次性顺序执行确保这些命令在执行过程中不会被其他客户端的命令打断。

以下是

Redis

MULTI开始一个事务将后续命令放入事务队列。

EXEC执行事务中的所有命令并返回结果。

DISCARD放弃事务队列中的所有命令。

WATCH监控一个或多个键如果这些键在事务执行前被修改则事务会自动取消。

Redis

事务保证了事务中的所有命令都能被顺序执行而不会被其他客户端的命令打断。

这意味着事务中的命令要么全部执行要么全部不执行确保了操作的原子性。

九、主从

的主从架构是一种常见的部署方式用于实现数据的冗余备份、读写分离以及高可用性。

在主从架构中从服务器通常被设置为只读模式这样可以避免从服务器的数据被误修改。

但是从服务器仍然可以接受CONFIG等指令所以还是不应该将从服务器直接暴露到不安全的网络环境中。

如果必须如此那可以考虑给重要指令进行重命名来避免命令被外人误执行。

主服务器创建快照文件发送给从服务器并在发送期间使用缓冲区记录执行的写命令。

快照文件发送完毕之后开始向从服务器发送存储在缓冲区中的写命令从服务器丢弃所有旧数据载入主服务器发来的快照文件之后从服务器开始接受主服务器发来的写命令主服务器每执行一次写命令就向从服务器发送相同的写命令。

1、核心概念

等以及读操作。

主节点会将数据同步到从节点。

从节点Slave从节点是主节点的副本用于读操作也可以作为数据备份。

从节点可以配置为只读模式以防止数据被意外修改。

从节点通过与主节点建立连接实时复制主节点的数据。

如果主节点发生故障从节点可以接管主节点的角色需要结合

Redis

命令请求成为主节点的从节点然后发出SYNC指当主服务器接到此命令后就会调用BGSAVE指令来创建一个子进程专门进行数据持久化工作也就是将主服务器的数据写入RDB文件中。

在数据持久化期间主服务器将执行的写指令都缓存在内存中。

在BGSAVE指令执行完成后主服务器会将持久化好的RDB文件发送给从服务器从服务器接到此文件后会将其存储到磁盘上然后再将其读取到内存中。

这个动作完成后主服务器会将这段时间缓存的写指令再以redis协议的格式发送给从服务器。

另外要说的一点是即使有多个从服务器同时发来SYNC指令主服务器也只会执行一次BGSAVE然后把持久化好的RDB文件发给多个下游。

在redis2.8版本之前如果从服务器与主服务器因某些原因断开连接的话都会进行一次主从之间的全量的数据同步而在2.8版本之后redis支持了效率更高的增量同步策略这大大降低了连接断开的恢复成本。

主服务器会在内存中维护一个缓冲区缓冲区中存储着将要发给从服务器的内容。

从服务器在与主服务器出现网络瞬断之后从服务器会尝试再次与主服务器连接一旦连接成功从服务器就会把“希望同步的主服务器ID”和“希望请求的数据的偏移位置replication

offset”发送出去。

主服务器接收到这样的同步请求后首先会验证主服务器ID是否和自己的ID匹配其次会检查“请求的偏移位置”是否存在于自己的缓冲区中如果两者都满足的话主服务器就会向从服务器发送增量内容。

增量同步功能需要服务器端支持全新的PSYNC指令。

这个指令只有在redis-2.8之后才具有。

3、故障转移

提供了哨兵Sentinel和集群Cluster两种机制来实现自动故障转移

哨兵Sentinel监控主从架构当主节点故障时自动将其中一个从节点提升为主节点。

集群Cluster支持自动故障转移和数据分片适用于大规模分布式环境。

3.1

(哨兵模式)是Redis官方推荐的高可用性(HA)解决方案当用Redis做Master-slave的高可用方案时假如master宕机了Redis本身(包括它的很多客户端)都没有实现自动进行主备切换而Redis-sentinel本身也是一个独立运行的进程它能监控多个master-slave集群发现master宕机后能进行自懂切换。

3.2

3.0版本正式推出的有效解决了Redis分布式方面的需求。

当遇到单机内存、并发、流量等瓶颈时可以采用Cluster架构达到负载均衡的目的。

3.3

分片是将数据划分为多个部分的方法可以将数据存储到多台机器里面这种方法在解决某些问题时可以获得线性级别的性能提升。

假设有

中等等。

但是这样需要维护一张映射范围表维护操作代价很高。

还有一种方式是哈希分片使用

CRC32

哈希函数将键转换为一个数字再对实例数量求模就能知道应该存储的实例。

客户端分片客户端使用一致性哈希等算法决定键应当分布到哪个节点。

代理分片将客户端请求发送到代理上由代理转发请求到正确的节点上。

服务器分片Redis

十、相关问答

缓存穿透查询一个不存在的数据mysql查询不到数据也不会直接写入缓存就会导致每次请求都查数据库

解决方案一缓存空数据查询返回的数据为空仍把这个空结果进行缓存。

{key:1,

value:null}

缓存击穿给某一个key设置了过期时间当key过期的时候恰好这时间点对这个key有大量的并发请求过来这些并发的请求可能会瞬间把DB压垮

解决方案一互斥锁

缓存雪崩是指在同一时段大量的缓存key同时失效或者Redis服务宕机导致大量请求到达数据库带来巨大压力。

解决方案

给不同的Key的TTL添加随机值利用Redis集群提高服务的可用性

nginx或spring

缓存和数据库时由于网络延迟、并发操作或异常情况导致两者数据不一致的情况。

这种不一致可能引发脏读、幻读等问题影响系统的正确性和用户体验。

写数据库后忘记更新缓存导致后续读请求从缓存中获取旧数据。

删除缓存后数据库更新失败缓存长时间处于空缺状态加重数据库压力。

并发环境下读写操作交错执行可能导致缓存与数据库数据不一致。

主从复制延迟与缓存失效时间窗口冲突从库未同步完成时缓存重新加载旧数据。

解决方案

秒再次删除缓存。

延时时间需根据读操作耗时调整。

优点简单易实现。

缺点延时期间可能出现脏数据且第二次删除缓存可能失败。

2.2

流程在更新数据库前获取分布式锁删除缓存提交数据库事务最后释放锁。

优点强一致性适用于对一致性要求高的场景。

缺点性能较低分布式锁实现复杂。

2.3

binlog异步通知缓存更新。

优点对业务代码侵入性低适合高并发场景。

缺点存在消息丢失或延迟的风险。

2.4

流程在数据库中增加版本号字段每次更新数据时版本号加一缓存中也存储版本号仅在版本号匹配时更新。

优点能有效解决并发更新问题。

缺点需要维护版本号实现复杂。

2.5

流程使用读写锁控制缓存和数据库的读写操作确保同一时间只有一个线程可以写入。

优点强一致性适合读多写少的场景。

缺点写操作时会阻塞其他线程。

强一致性要求优先选择分布式锁或读写锁。

允许最终一致性延时双删或异步通知是较好的选择。

高并发场景异步通知或

Canal

采用单线程模型避免了多线程环境下的线程切换和锁竞争开销。

虽然单线程模型在高并发写入时可能会成为瓶颈但

Redis

引入了多线程支持主要用于处理一些耗时的操作例如异步删除和异步清空数据库。

在Redis6.0中新增了多线程的功能来提高IO的读写性能它的主要实现思路是将主线程的IO读写任务拆分给一组独立的线程去执行这样就可以使用多个socket的读写并行化了但Redis的命令依旧是主线程串行执行的。

但是注意Redis6.0是默认禁用多线程的但可以通过配置文件redis.conf中的io-threads-do-reads

true

来开启。

但是还不够除此之外我们还需要设置线程的数量才能正确地开启多线程的功能同样是修改Redis的配置例如设置

io-threads

支持命令管道化允许客户端将多个命令打包在一起发送给服务器从而减少网络往返次数。

这种方法可以显著提高性能尤其是在高延迟网络环境下。

例如

普通模式每个命令都需要一次网络往返。

管道化模式多个命令一起发送减少网络延迟的影响。

3.4

使用事件驱动模型通过回调函数处理网络事件避免了阻塞操作。

非阻塞

I/ORedis

MongoDB和Redis都是NoSQL采用结构型数据存储。

二者在使用场景中存在一定的区别这也主要由于二者在内存映射的处理过程持久化的处理方法不同。

MongoDB建议集群部署更多的考虑到集群方案Redis更偏重于进程顺序写入虽然支持集群也仅限于主-从模式。

指标MongoDB(v2.4.9)Redis(v2.4.17)比较说明实现语言CC/C-协议BSON、自定义二进制类Telnet-性能依赖内存TPS较高依赖内存TPS非常高Redis优于MongoDB可操作性丰富的数据表达、索引最类似于关系数据库支持丰富的查询语言数据丰富较少的IOMongoDB优于Redis内存及存储适合大数据量存储依赖系统虚拟内存管理采用镜像文件存储内存占有率比较高官方建议独立部署在64位系统32位有最大2.5G文件限制64位没有改限制Redis2.0后增加虚拟内存特性突破物理内存限制数据可以设置时效性类似于memcache不同的应用角度看各有优势可用性支持master-slave,replicaset内部采用paxos选举算法自动故障恢复,auto

sharding机制对客户端屏蔽了故障转移和切分机制依赖客户端来实现分布式读写主从复制时每次从节点重新连接主节点都要依赖整个快照,无增量复制不支持自动sharding,需要依赖程序设定一致hash机制MongoDB优于Redis单点问题上MongoDB应用简单相对用户透明Redis比较复杂需要客户端主动解决。

MongoDB

一般会使用replica

sets侧重高可用性及高可靠性而sharding侧重于性能、易扩展可靠性从1.8版本后采用binlog方式MySQL同样采用该方式支持持久化增加可靠性依赖快照进行持久化AOF增强可靠性增强可靠性的同时影响访问性能MongoDB优于Redis一致性不支持事物靠客户端自身保证支持事物比较弱仅能保证事物中的操作按顺序执行Redis优于MongoDB数据分析内置数据分析功能mapreduce不支持MongoDB优于Redis应用场景海量数据的访问效率提升较小数据量的性能及运算MongoDB优于Redis

十二、配置

默认情况下redis并不是以daemon形式来运行的。

通过daemonize配置项可以控制redis的运行形式如果改为yes那么redis就会以daemon形式运行

daemonize

no当以daemon形式运行时redis会生成一个pid文件默认会生成在/var/run/redis.pid。

当然你可以通过pidfile来指定pid文件生成的位置比如

pidfile

/path/to/redis.pid默认情况下redis会响应本机所有可用网卡的连接请求。

当然redis允许你通过bind配置项来指定要绑定的IP比如

bind

10.8.4.2redis的默认服务端口是6379你可以通过port配置项来修改。

如果端口设置为0的话redis便不会监听端口了。

port

6379“如果redis不监听端口还怎么与外界通信呢”其实redis还支持通过unix

socket方式来接收请求。

可以通过unixsocket配置项来指定unix

socket文件的路径并通过unixsocketperm来指定文件的权限。

unixsocket

755当一个redis-client一直没有请求发向server端那么server端有权主动关闭这个连接可以通过timeout来设置“空闲超时时限”0表示永不关闭。

timeout

0TCP连接保活策略可以通过tcp-keepalive配置项来进行设置单位为秒假如设置为60秒则server端会每60秒向连接空闲的客户端发起一次ACK请求以检查客户端是否已经挂掉对于无响应的客户端则会关闭其连接。

所以关闭一个连接最长需要120秒的时间。

如果设置为0则不会进行保活检测。

tcp-keepalive

0redis支持通过loglevel配置项设置日志等级共分四级即debug、verbose、notice、warning。

loglevel

noticeredis也支持通过logfile配置项来设置日志文件的生成位置。

如果设置为空字符串则redis会将日志输出到标准输出。

假如你在daemon情况下将日志设置为输出到标准输出则日志会被写到/dev/null中。

logfile

如果希望日志打印到syslog中也很容易通过syslog-enabled来控制。

另外syslog-ident还可以让你指定syslog里的日志标志比如

syslog-ident

redis而且还支持指定syslog设备值可以是USER或LOCAL0-LOCAL7。

具体可以参考syslog服务本身的用法。

syslog-facility

local0对于redis来说可以设置其数据库的总数量假如你希望一个redis包含16个数据库那么设置如下

databases

16这16个数据库的编号将是0到15。

默认的数据库是编号为0的数据库。

用户可以使用select

save

//表示每5分钟且至少有10个key改变就触发一次持久化如果你想禁用RDB持久化的策略只要不设置任何save指令就可以或者给save传入一个空字符串参数也可以达到相同效果就像这样

save

如果用户开启了RDB快照功能那么在redis持久化数据到磁盘时如果出现失败默认情况下redis会停止接受所有的写请求。

这样做的好处在于可以让用户很明确的知道内存中的数据和磁盘上的数据已经存在不一致了。

如果redis不顾这种不一致一意孤行的继续接收写请求就可能会引起一些灾难性的后果。

当然如果你不在乎这种数据不一致或者有其他的手段发现和控制这种不一致的话你完全可以关闭这个功能以便在快照写入失败时也能确保redis继续接受新的写请求。

配置项如下

yes对于存储到磁盘中的快照可以设置是否进行压缩存储。

如果是的话redis会采用LZF算法进行压缩。

如果你不想消耗CPU来进行压缩的话可以设置为关闭此功能但是存储在磁盘上的快照会比较大。

rdbcompression

yes在存储快照后我们还可以让redis使用CRC64算法来进行数据校验但是这样做会增加大约10%的性能消耗如果你希望获取到最大的性能提升可以关闭此功能。

rdbchecksum

dump.rdb最后你还可以设置这个快照文件存放的路径。

比如默认设置就是当前文件夹

dir

通过slaveof配置项可以控制某一个redis作为另一个redis的从服务器通过指定IP和端口来定位到主redis的位置。

一般情况下我们会建议用户为从redis设置一个不同频率的快照持久化的周期或者为从redis配置一个不同的服务端口等等。

slaveof

masterport如果主redis设置了验证密码的话使用requirepass来设置则在从redis的配置中要使用masterauth来设置校验密码否则的话主redis会拒绝从redis的访问请求。

masterauth

master-password当从redis失去了与主redis的连接或者主从同步正在进行中时redis该如何处理外部发来的访问请求呢这里从redis可以有两种选择

第一种选择如果slave-serve-stale-data设置为yes默认则从redis仍会继续响应客户端的读写请求。

第二种选择如果slave-serve-stale-data设置为no则从redis会对客户端的请求返回“SYNC

with

progress”当然也有例外当客户端发来INFO请求和SLAVEOF请求从redis还是会进行处理。

你可以控制一个从redis是否可以接受写请求。

将数据直接写入从redis一般只适用于那些生命周期非常短的数据因为在主从同步时这些临时数据就会被清理掉。

自从redis2.6版本之后默认从redis为只读。

slave-read-only

yes只读的从redis并不适合直接暴露给不可信的客户端。

为了尽量降低风险可以使用rename-command指令来将一些可能有破坏力的命令重命名避免外部直接调用。

比如

rename-command

b840fc02d524045429941cc15f59e41cb7be6c52从redis会周期性的向redis发出PING包。

你可以通过repl_ping_slave_period指令来控制其周期。

默认是10秒。

10部分参考链接https://cloud.tencent.com/developer/article/2436822

如有错误千万指出感谢