食堂网站建设,营销型网站应用,企业网站优化方式,net网站开发做手工简笔目录 一、基本1、数据结构2、有序集合的编码1. 压缩列表#xff08;Ziplist#xff09;2. 跳跃列表#xff08;SkipList#xff09;3. 动态转换机制 二、应用场景三、持久化1、 RDB 持久化2、 AOF 持久化3、 混合持久化#xff08;RDB AOF#xff09;4、 RDB和AOF的对比… 目录 一、基本1、数据结构2、有序集合的编码1. 压缩列表Ziplist2. 跳跃列表SkipList3. 动态转换机制 二、应用场景三、持久化1、 RDB 持久化2、 AOF 持久化3、 混合持久化RDB AOF4、 RDB和AOF的对比5、 默认持久化方式 五、删除策略1、 过期键的删除策略1.1 定时删除1.2 惰性删除1.3 定期删除 六、淘汰策略1、淘汰策略2、配置方法 七、redis4.01、 模块系统Module System2、 改进的复制机制3、 新的淘汰策略4、 非阻塞删除命令5、 混合持久化格式6、 新命令7、 其他改进 八、事务1、 事务的基本命令2、 事务的原子性 九、主从1、核心概念2、主从复制的过程3、故障转移3.1 哨兵Sentinel3.2 集群Cluster3.3 分片 十、相关问答1、缓存穿透、缓存击穿、缓存雪崩1.1 缓存穿透1.2 缓存击穿1.3 缓存雪崩 2、双写一致2.1 延时双删2.2 分布式锁2.3 异步通知2.4 版本号方案2.5 读写锁总结 3、redis为什么快3.1 基于内存的存储3.2 单线程模型3.3 命令管道化Pipeline3.4 高性能的网络处理 十一、redis和mongdb的比较十二、配置1、 通用2、 快照3、 主从复制 (格式md直接粘贴过来有点乱 有空一定改 需要md的可以留言)
一、基本
1、数据结构
数据类型可以存储的值操作应用场景STRING字符串、整数或者浮点数对整个字符串或者字符串的其中一部分执行操作 对整数和浮点数执行自增或者自减操作LIST列表从两端压入或者弹出元素 对单个或者多个元素进行修剪 只保留一个范围内的元素实现消息队列、任务队列、聊天记录等SET无序集合添加、获取、移除单个元素 检查一个元素是否存在于集合中 计算交集、并集、差集 从集合里面随机获取元素存储不重复的元素集合如用户关注列表、标签集合等HASH包含键值对的无序散列表添加、获取、移除单个键值对 获取所有键值对 检查某个键是否存在存储对象的多个属性如用户信息用户名、密码、邮箱等ZSET有序集合添加、获取、删除元素 根据分值范围或者成员来获取元素 计算一个键的排名实现排行榜、优先级队列、时间线等Bitmap位图一种基于字符串的二进制数据结构通过位操作实现高效的存储和查询用户在线状态、用户签到、统计用户行为、布隆过滤器等HyperLogLog超日志用于统计基数集合中不重复元素的数量的近似算法占用空间小精度高统计独立访客数量、不重复的用户行为、广告点击去重Streams流日志结构的数据类型支持消息的持久化、消费组和消息确认等特性实现分布式消息队列、事件溯源、日志存储等Geo借助zset存储和操作地理空间数据的类型实现“附近的人”或“附近的餐厅”功能。 计算两点之间的距离。 地理围栏和实时位置追踪
2、有序集合的编码
Redis 的有序集合Sorted SetZSet底层实现主要依赖两种数据结构压缩列表Ziplist 和 跳跃列表SkipList。具体使用哪种结构取决于有序集合的大小和元素的特性。
1. 压缩列表Ziplist
每个集合元素使用两个紧挨在一起的压缩列表节点来保存第一个节点保存元素的成员第二个节点保存元素的分值。并且压缩列表内的集合元素按分值从小到大的顺序进行排列小的放置在靠近表头的位置大的放置在靠近表尾的位置。
当有序集合满足以下条件时Redis 使用压缩列表作为底层实现 元素数量不超过 128 个 每个元素的成员长度小于 64 字节。 以上两个条件也可以通过Redis配置文件zset-max-ziplist-entries 选项和 zset-max-ziplist-value 进行修改。 压缩列表是一种内存高效的数据结构通过紧凑的内存布局存储元素和分数。每个元素的成员和分数分别存储在相邻的节点中。
2. 跳跃列表SkipList
当有序集合不满足压缩列表的条件时Redis 使用跳跃列表作为底层实现。跳跃列表是一种基于链表的多级索引结构通过随机化的方式构建多级索引从而实现快速查找、插入和删除操作。 跳跃列表的主要特点包括
多级索引通过多级索引加速查询平均时间复杂度为 O(log N)最坏情况下为 O(N)。双向指针每一层不仅有向前指针还有向后指针便于快速回溯。随机化级别生成随机函数在插入新节点时被用来决定节点是否升级到更高层级以平衡空间开销和访问速度。
跳跃列表的实现包括一个字典和一个跳跃表
字典 字典的键保存元素的值字典的值则保存元素的分值用于快速查找成员对应的分数时间复杂度为 O(1)。跳跃表跳跃表节点的 object 属性保存元素的成员跳跃表节点的 score 属性保存元素的分值用于按分数排序并支持范围操作如 ZRANGE 和 ZREVRANGE。
跳跃表和b树对比
相对于链表结构的跳跃表B树在每个节点上存储的数据量更多所以通常会占用更多的存储空间。如果查询效率是首要考虑的因素并且可以承担更高的空间占用可以选择B树
3. 动态转换机制
Redis 根据有序集合的规模和元素特性动态选择底层数据结构
当有序集合的元素数量或成员长度超出压缩列表的限制时自动转换为跳跃列表。这种机制确保了在不同场景下都能高效地存储和操作有序集合。 二、应用场景
1、分布式锁
2、事件发布/订阅机制
3、缓存
4、实现任务队列或消息传递系统
5、会话管理过期失效 三、持久化
1、 RDB 持久化 原理
RDB 是通过将 Redis 内存中的数据以二进制快照的形式保存到磁盘上的 dump.rdb 文件中。可以通过配置文件设置快照的触发条件例如每 5 分钟内至少有 1000 个键被修改。RDB 支持手动触发SAVE 或 BGSAVE 命令和自动触发。
优点
文件紧凑RDB 文件是经过压缩的二进制格式占用磁盘空间小。恢复速度快加载 RDB 文件恢复数据的速度比 AOF 更快。对性能影响小通过 BGSAVE 命令子进程负责生成快照主进程继续处理客户端请求。
缺点
数据丢失风险由于是定期快照最后一次快照之后的数据可能会丢失。fork 操作开销在数据量较大时fork 子进程可能会导致性能下降。
适用场景
适用于对数据一致性要求不高但对恢复速度和磁盘空间占用敏感的场景。 2、 AOF 持久化
原理
AOF 持久化通过将 Redis 的所有写操作追加到 AOF 文件末尾记录所有修改操作的详细记录。Redis 启动时通过重放 AOF 文件中的命令来恢复数据。
优点
高数据可靠性AOF 可以保证最后一次写操作之前的数据不会丢失。细粒度恢复支持更细粒度的数据恢复适合需要高可靠性的场景。可读性强AOF 文件是文本格式易于阅读和修改。
缺点
文件较大AOF 文件记录所有写操作因此文件大小通常比 RDB 文件大。性能负担每次写操作都需要写入磁盘可能导致较高的 I/O 负载。恢复速度慢从 AOF 文件恢复数据需要逐条执行命令速度较慢。
适用场景
适用于对数据一致性要求高且写操作较少的场景。
AOF配置
使用 AOF 持久化需要设置同步选项从而确保写命令同步到磁盘文件上的时机。这是因为对文件进行写入并不会马上将内容同步到磁盘上而是先存储到缓冲区然后由操作系统决定什么时候同步到磁盘。有以下同步选项
选项同步频率always每个写命令都同步everysec每秒同步一次no让操作系统来决定何时同步
always 选项会严重减低服务器的性能everysec 选项比较合适可以保证系统崩溃时只会丢失一秒左右的数据并且 Redis 每秒执行一次同步对服务器性能几乎没有任何影响no 选项并不能给服务器性能带来多大的提升而且也会增加系统崩溃时数据丢失的数量。
通过配置redis.conf中的appendonly 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文件其中便包括了可以恢复现有数据的最少的命令集。。 3、 混合持久化RDB AOF
原理
Redis 4.0 引入了混合持久化机制结合了 RDB 和 AOF 的优点。在 AOF 重写时将 Redis 的数据以 RDB 格式写入 AOF 文件的开头后续数据以 AOF 格式追加到文件末尾。
两种方式可以同时使用在这种情况下如果redis重启的话则会优先采用AOF方式来进行数据恢复这是因为AOF方式的数据恢复完整度更高。
优点
快速启动由于开头为 RDB 格式Redis 启动速度更快。降低数据丢失风险结合 AOF 的优点减少了大量数据丢失的风险。
缺点
文件格式复杂混合持久化的 AOF 文件可读性较差且不向下兼容。
适用场景
适用于对数据恢复速度和数据完整性都有较高要求的场景。 4、 RDB和AOF的对比 5、 默认持久化方式
Redis 3.x 及以下版本默认不启用任何持久化方式需要手动配置。Redis 4.0 及以上版本默认启用 AOF 持久化混合模式。Redis 6.x 及以上版本默认启用 AOF 持久化混合模式并优化了性能和可靠性。 五、删除策略
Redis 的删除策略主要分为过期键的删除策略和内存淘汰策略。以下是详细说明
1、 过期键的删除策略
Redis 使用以下三种策略来处理过期键
1.1 定时删除
原理在设置键的过期时间时创建一个定时事件。当时间到达时自动执行删除操作。优点对内存友好过期键会尽快被删除释放内存。缺点对 CPU 不友好可能会占用较多 CPU 时间。
1.2 惰性删除
原理不主动删除过期键仅在访问键时检查是否过期如果过期则删除。优点对 CPU 友好只有在访问时才会检查和删除过期键。缺点对内存不友好过期键可能长时间占用内存。
1.3 定期删除
原理每隔一段时间随机检查一定数量的键删除其中的过期键。默认每秒检查 10 次100ms 一次每次检查 20 个键。优点平衡了 CPU 和内存的使用既不会占用过多 CPU也能及时清理过期键。缺点可能无法立即删除所有过期键。
Redis 实际上采用了 惰性删除 定期删除 的组合策略以在 CPU 使用和内存清理之间取得平衡 六、淘汰策略
在redis中提供了两种数据过期删除策略
第一种是情性删除在设置该key过期时间后我们不去管它当需要该key时我们在检查其是否过期如果过期我们就删掉它反之返回该key。第二种是定期删除就是说每隔一段时间我们就对一些key进行检查删除里面过期的key
Redis的过期删除策略惰性删除 定期删除 两种策略进行配合使用。
1、淘汰策略
可以设置内存最大使用量当内存使用量超出时会施行数据淘汰策略。
Redis 具体有 6 种淘汰策略
策略描述volatile-lru从已设置过期时间的数据集中挑选最近最少使用的数据淘汰volatile-lfu从已设置过期时间的数据集中淘汰访问频率最低的键Redis 4.0volatile-ttl从已设置过期时间的数据集中挑选将要过期的数据淘汰volatile-random从已设置过期时间的数据集中任意选择数据淘汰allkeys-lru从所有数据集中挑选最近最少使用的数据淘汰allkeys-lfu从所有键中淘汰访问频率最低的键 Redis 4.0allkeys-random从所有数据集中任意选择数据进行淘汰noeviction禁止驱逐数据
作为内存数据库出于对性能和内存消耗的考虑Redis 的淘汰算法实际实现上并非针对所有 key而是抽样一小部分并且从中选出被淘汰的 key。
Redis 4.0 引入了 volatile-lfu 和 allkeys-lfu 淘汰策略LFU 策略通过统计访问频率将访问频率最少的键值对淘汰。 2、配置方法
配置文件设置在 redis.conf 文件中使用 maxmemory-policy policy 配置淘汰策略。运行时设置使用 CONFIG SET maxmemory-policy policy 动态更改策略。命令行启动通过 redis-server --maxmemory-policy policy 设置 七、redis4.0
Redis 4.0 的首个正式版本4.0.0于 2017 年 7 月 14 日发布
1、 模块系统Module System
Redis 4.0 引入了模块系统允许用户通过编写代码扩展 Redis 的功能。模块系统通过高级 API 实现与 Redis 核心完全分离不会干扰 Redis 的正常运行。例如可以通过 loadmodule 指令在 redis.conf 文件中加载模块。
2、 改进的复制机制
Redis 4.0 对复制机制进行了优化引入了部分复制Partial Replication功能。在旧版本中从节点重新连接主节点时需要重新同步整个数据集而 Redis 4.0 支持在条件允许的情况下使用部分复制从而减少数据传输量。
3、 新的淘汰策略
Redis 4.0 引入了基于最近最少使用LFU的淘汰策略即 allkeys-lfu 和 volatile-lfu。这些策略通过记录键的访问频率来决定哪些键应该被优先淘汰。
4、 非阻塞删除命令
Redis 4.0 引入了 UNLINK 命令这是一个异步版本的 DEL 命令可以在后台线程中删除键避免阻塞主线程。此外FLUSHDB 和 FLUSHALL 命令也支持 ASYNC 选项允许在后台线程中执行数据库清空操作。
5、 混合持久化格式
Redis 4.0 提供了一种新的混合持久化格式结合了 RDB 和 AOF 的优点。启用该功能后AOF 重写文件会包含 RDB 格式的数据和 AOF 格式的增量数据从而实现快速加载和数据完整性。
6、 新命令
Redis 4.0 引入了多个新命令例如 MEMORY 命令用于检查内存使用情况SWAPDB 命令用于交换两个数据库。
7、 其他改进
兼容性增强Redis 4.0 改进了对 NAT 和 Docker 的支持允许在这些环境下更好地运行。性能优化对现有缓存淘汰策略进行了优化使其更高效、更准确。 八、事务
Redis 的事务功能允许将一组命令打包并一次性顺序执行确保这些命令在执行过程中不会被其他客户端的命令打断。以下是 Redis 事务的主要特性及其使用方式
1、 事务的基本命令
Redis 提供了以下命令来控制事务的执行
MULTI开始一个事务将后续命令放入事务队列。EXEC执行事务中的所有命令并返回结果。DISCARD放弃事务队列中的所有命令。WATCH监控一个或多个键如果这些键在事务执行前被修改则事务会自动取消。
2、 事务的原子性
Redis 事务保证了事务中的所有命令都能被顺序执行而不会被其他客户端的命令打断。这意味着事务中的命令要么全部执行要么全部不执行确保了操作的原子性。 九、主从
Redis 的主从架构是一种常见的部署方式用于实现数据的冗余备份、读写分离以及高可用性。
在主从架构中从服务器通常被设置为只读模式这样可以避免从服务器的数据被误修改。但是从服务器仍然可以接受CONFIG等指令所以还是不应该将从服务器直接暴露到不安全的网络环境中。如果必须如此那可以考虑给重要指令进行重命名来避免命令被外人误执行。
一个从服务器只能有一个主服务器并且不支持主主复制。
主服务器创建快照文件发送给从服务器并在发送期间使用缓冲区记录执行的写命令。快照文件发送完毕之后开始向从服务器发送存储在缓冲区中的写命令从服务器丢弃所有旧数据载入主服务器发来的快照文件之后从服务器开始接受主服务器发来的写命令主服务器每执行一次写命令就向从服务器发送相同的写命令。
1、核心概念
在 Redis 的主从架构中
主节点Master主节点是数据的写入点负责处理所有写操作如 SET、HSET 等以及读操作。主节点会将数据同步到从节点。从节点Slave从节点是主节点的副本用于读操作也可以作为数据备份。从节点可以配置为只读模式以防止数据被意外修改。
从节点通过与主节点建立连接实时复制主节点的数据。如果主节点发生故障从节点可以接管主节点的角色需要结合 Redis Sentinel 或 Cluster 实现自动故障转移。
2、主从复制的过程
从节点启动后会向主节点发送 SLAVEOF 命令请求成为主节点的从节点然后发出SYNC指当主服务器接到此命令后就会调用BGSAVE指令来创建一个子进程专门进行数据持久化工作也就是将主服务器的数据写入RDB文件中。在数据持久化期间主服务器将执行的写指令都缓存在内存中。在BGSAVE指令执行完成后主服务器会将持久化好的RDB文件发送给从服务器从服务器接到此文件后会将其存储到磁盘上然后再将其读取到内存中。这个动作完成后主服务器会将这段时间缓存的写指令再以redis协议的格式发送给从服务器。
另外要说的一点是即使有多个从服务器同时发来SYNC指令主服务器也只会执行一次BGSAVE然后把持久化好的RDB文件发给多个下游。在redis2.8版本之前如果从服务器与主服务器因某些原因断开连接的话都会进行一次主从之间的全量的数据同步而在2.8版本之后redis支持了效率更高的增量同步策略这大大降低了连接断开的恢复成本。
主服务器会在内存中维护一个缓冲区缓冲区中存储着将要发给从服务器的内容。从服务器在与主服务器出现网络瞬断之后从服务器会尝试再次与主服务器连接一旦连接成功从服务器就会把“希望同步的主服务器ID”和“希望请求的数据的偏移位置replication offset”发送出去。主服务器接收到这样的同步请求后首先会验证主服务器ID是否和自己的ID匹配其次会检查“请求的偏移位置”是否存在于自己的缓冲区中如果两者都满足的话主服务器就会向从服务器发送增量内容。
增量同步功能需要服务器端支持全新的PSYNC指令。这个指令只有在redis-2.8之后才具有。
3、故障转移
Redis 提供了哨兵Sentinel和集群Cluster两种机制来实现自动故障转移
哨兵Sentinel监控主从架构当主节点故障时自动将其中一个从节点提升为主节点。集群Cluster支持自动故障转移和数据分片适用于大规模分布式环境。
3.1 哨兵Sentinel
Redis-Sentinel [ˈsentɪnl] (哨兵模式)是Redis官方推荐的高可用性(HA)解决方案当用Redis做Master-slave的高可用方案时假如master宕机了Redis本身(包括它的很多客户端)都没有实现自动进行主备切换而Redis-sentinel本身也是一个独立运行的进程它能监控多个master-slave集群发现master宕机后能进行自懂切换。
3.2 集群Cluster
Redis Cluster [ˈklʌstə®] 是Redis的分布式解决方案在Redis 3.0版本正式推出的有效解决了Redis分布式方面的需求。当遇到单机内存、并发、流量等瓶颈时可以采用Cluster架构达到负载均衡的目的。
3.3 分片
分片是将数据划分为多个部分的方法可以将数据存储到多台机器里面这种方法在解决某些问题时可以获得线性级别的性能提升。
假设有 4 个 Redis 实例 R0R1R2R3还有很多表示用户的键 user:1user:2… 有不同的方式来选择一个指定的键存储在哪个实例中。
最简单的方式是范围分片例如用户 id 从 0~1000 的存储到实例 R0 中用户 id 从 1001~2000 的存储到实例 R1 中等等。但是这样需要维护一张映射范围表维护操作代价很高。还有一种方式是哈希分片使用 CRC32 哈希函数将键转换为一个数字再对实例数量求模就能知道应该存储的实例。
根据执行分片的位置可以分为三种分片方式
客户端分片客户端使用一致性哈希等算法决定键应当分布到哪个节点。代理分片将客户端请求发送到代理上由代理转发请求到正确的节点上。服务器分片Redis Cluster。 十、相关问答
1、缓存穿透、缓存击穿、缓存雪崩
1.1 缓存穿透
缓存穿透查询一个不存在的数据mysql查询不到数据也不会直接写入缓存就会导致每次请求都查数据库 解决方案一缓存空数据查询返回的数据为空仍把这个空结果进行缓存。{key:1, value:null}
优点简单缺点消耗内存可能会发生不一致的问题
解决方案二布隆过滤器 优点内存占用较少没有多余key缺点实现复杂存在误判
1.2 缓存击穿
缓存击穿给某一个key设置了过期时间当key过期的时候恰好这时间点对这个key有大量的并发请求过来这些并发的请求可能会瞬间把DB压垮 解决方案一互斥锁 左图线程1没有查完db前其他线程只能查redis不能查db 解决方案二逻辑过期 右图不能保证数据绝对一致
1.3 缓存雪崩
缓存雪崩是指在同一时段大量的缓存key同时失效或者Redis服务宕机导致大量请求到达数据库带来巨大压力。
解决方案
给不同的Key的TTL添加随机值利用Redis集群提高服务的可用性 哨兵模式、集群模式给缓存业务添加降级限流策略 nginx或spring cloud gateway给业务添加多级缓存 Guava或Caffeine 2、双写一致
Redis 与数据库如 MySQL的双写一致性问题是指在同时更新 Redis 缓存和数据库时由于网络延迟、并发操作或异常情况导致两者数据不一致的情况。这种不一致可能引发脏读、幻读等问题影响系统的正确性和用户体验。
双写一致性问题的典型场景
写数据库后忘记更新缓存导致后续读请求从缓存中获取旧数据。删除缓存后数据库更新失败缓存长时间处于空缺状态加重数据库压力。并发环境下读写操作交错执行可能导致缓存与数据库数据不一致。主从复制延迟与缓存失效时间窗口冲突从库未同步完成时缓存重新加载旧数据。 解决方案
2.1 延时双删
流程先删除缓存再更新数据库然后延时一段时间如 1 秒再次删除缓存。延时时间需根据读操作耗时调整。优点简单易实现。缺点延时期间可能出现脏数据且第二次删除缓存可能失败。
2.2 分布式锁
流程在更新数据库前获取分布式锁删除缓存提交数据库事务最后释放锁。优点强一致性适用于对一致性要求高的场景。缺点性能较低分布式锁实现复杂。
2.3 异步通知
流程通过消息队列如 Kafka或 Canal读取 MySQL binlog异步通知缓存更新。优点对业务代码侵入性低适合高并发场景。缺点存在消息丢失或延迟的风险。
2.4 版本号方案
流程在数据库中增加版本号字段每次更新数据时版本号加一缓存中也存储版本号仅在版本号匹配时更新。优点能有效解决并发更新问题。缺点需要维护版本号实现复杂。
2.5 读写锁
流程使用读写锁控制缓存和数据库的读写操作确保同一时间只有一个线程可以写入。优点强一致性适合读多写少的场景。缺点写操作时会阻塞其他线程。
总结
双写一致性问题的解决方案各有优缺点选择时需根据业务需求权衡
强一致性要求优先选择分布式锁或读写锁。允许最终一致性延时双删或异步通知是较好的选择。高并发场景异步通知或 Canal MQ 方案更适合。
3、redis为什么快
3.1 基于内存的存储
Redis 将所有数据存储在内存中而不是磁盘上。内存访问速度比磁盘即使是 SSD快几个数量级这使得 Redis 的读写操作能够以极高的速度执行。例如
内存读写速度内存的读写速度通常在纳秒级别10^-9 秒。磁盘读写速度即使是 SSD读写速度也在毫秒级别10^-3 秒比内存慢得多。
3.2 单线程模型
Redis 采用单线程模型避免了多线程环境下的线程切换和锁竞争开销。虽然单线程模型在高并发写入时可能会成为瓶颈但 Redis 通过优化命令执行效率和网络 I/O确保了在大多数场景下的高性能。例如
命令执行效率Redis 的命令执行非常快通常在微秒级别。网络 I/O 优化Redis 使用非阻塞 I/O 和事件驱动模型能够高效处理大量的并发连接。
Redis 4.0 的核心仍然是单线程处理客户端请求包括网络 I/O、命令解析、执行和响应返回等操作。Redis 4.0 引入了多线程支持主要用于处理一些耗时的操作例如异步删除和异步清空数据库。
在Redis6.0中新增了多线程的功能来提高IO的读写性能它的主要实现思路是将主线程的IO读写任务拆分给一组独立的线程去执行这样就可以使用多个socket的读写并行化了但Redis的命令依旧是主线程串行执行的。
但是注意Redis6.0是默认禁用多线程的但可以通过配置文件redis.conf中的io-threads-do-reads 等于 true 来开启。但是还不够除此之外我们还需要设置线程的数量才能正确地开启多线程的功能同样是修改Redis的配置例如设置 io-threads 4表示开启4个线程。
3.3 命令管道化Pipeline
Redis 支持命令管道化允许客户端将多个命令打包在一起发送给服务器从而减少网络往返次数。这种方法可以显著提高性能尤其是在高延迟网络环境下。例如
普通模式每个命令都需要一次网络往返。管道化模式多个命令一起发送减少网络延迟的影响。
3.4 高性能的网络处理
Redis 使用高效的网络 I/O 模型基于 epoll 或 kqueue能够同时处理大量的并发连接。例如
事件驱动Redis 使用事件驱动模型通过回调函数处理网络事件避免了阻塞操作。非阻塞 I/ORedis 的网络操作是非阻塞的能够快速响应客户端请求。 十一、redis和mongdb的比较
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功能结合replica sets侧重高可用性及高可靠性而sharding侧重于性能、易扩展可靠性从1.8版本后采用binlog方式MySQL同样采用该方式支持持久化增加可靠性依赖快照进行持久化AOF增强可靠性增强可靠性的同时影响访问性能MongoDB优于Redis一致性不支持事物靠客户端自身保证支持事物比较弱仅能保证事物中的操作按顺序执行Redis优于MongoDB数据分析内置数据分析功能mapreduce不支持MongoDB优于Redis应用场景海量数据的访问效率提升较小数据量的性能及运算MongoDB优于Redis 十二、配置
redis配置文件被分成了几大块区域一共100多行它们分别是
1.通用general 2.快照snapshotting 3.复制replication 4.安全security 5.限制limits) 6.追加模式append only mode) 7.LUA脚本lua scripting) 8.慢日志slow log) 9.事件通知event notification
1、 通用
默认情况下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 192.168.1.2 10.8.4.2redis的默认服务端口是6379你可以通过port配置项来修改。如果端口设置为0的话redis便不会监听端口了。
port 6379“如果redis不监听端口还怎么与外界通信呢”其实redis还支持通过unix socket方式来接收请求。可以通过unixsocket配置项来指定unix socket文件的路径并通过unixsocketperm来指定文件的权限。
unixsocket /tmp/redis.sock
unixsocketperm 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 来选择相应的数据库。 2、 快照
主要涉及的是redis的RDB持久化相关的配置
save seconds changes举例来说
save 900 1 //表示每15分钟且至少有1个key改变就触发一次持久化
save 300 10 //表示每5分钟且至少有10个key改变就触发一次持久化如果你想禁用RDB持久化的策略只要不设置任何save指令就可以或者给save传入一个空字符串参数也可以达到相同效果就像这样
save 如果用户开启了RDB快照功能那么在redis持久化数据到磁盘时如果出现失败默认情况下redis会停止接受所有的写请求。这样做的好处在于可以让用户很明确的知道内存中的数据和磁盘上的数据已经存在不一致了。如果redis不顾这种不一致一意孤行的继续接收写请求就可能会引起一些灾难性的后果。
如果下一次RDB持久化成功redis会自动恢复接受写请求。
当然如果你不在乎这种数据不一致或者有其他的手段发现和控制这种不一致的话你完全可以关闭这个功能以便在快照写入失败时也能确保redis继续接受新的写请求。配置项如下
stop-writes-on-bgsave-error yes对于存储到磁盘中的快照可以设置是否进行压缩存储。如果是的话redis会采用LZF算法进行压缩。如果你不想消耗CPU来进行压缩的话可以设置为关闭此功能但是存储在磁盘上的快照会比较大。
rdbcompression yes在存储快照后我们还可以让redis使用CRC64算法来进行数据校验但是这样做会增加大约10%的性能消耗如果你希望获取到最大的性能提升可以关闭此功能。
rdbchecksum yes我们还可以设置快照文件的名称默认是这样配置的
dbfilename dump.rdb最后你还可以设置这个快照文件存放的路径。比如默认设置就是当前文件夹
dir ./3、 主从复制
通过slaveof配置项可以控制某一个redis作为另一个redis的从服务器通过指定IP和端口来定位到主redis的位置。一般情况下我们会建议用户为从redis设置一个不同频率的快照持久化的周期或者为从redis配置一个不同的服务端口等等。
slaveof masterip 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 master in progress”当然也有例外当客户端发来INFO请求和SLAVEOF请求从redis还是会进行处理。
你可以控制一个从redis是否可以接受写请求。将数据直接写入从redis一般只适用于那些生命周期非常短的数据因为在主从同步时这些临时数据就会被清理掉。自从redis2.6版本之后默认从redis为只读。
slave-read-only yes只读的从redis并不适合直接暴露给不可信的客户端。为了尽量降低风险可以使用rename-command指令来将一些可能有破坏力的命令重命名避免外部直接调用。比如
rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52从redis会周期性的向redis发出PING包。你可以通过repl_ping_slave_period指令来控制其周期。默认是10秒。
repl-ping-slave-period 10部分参考链接https://cloud.tencent.com/developer/article/2436822 应该还有很多但是当年没记忘了…
如有错误千万指出感谢
