工控机做网站服务器,服务器类网站建设,网站建设流程html,自己做应用的网站小林coding - 图解redis的学习笔记 文章目录 Rediswindwos安装docker安装redis启动redis使用RDM访问虚拟机中的redispython连接redis缓存穿透、击穿、雪崩基本数据类型高级数据类型高并发指标布隆过滤器分布式锁Redis 的有序集合底层为什么要用跳表#xff0c;而不用平衡…小林coding - 图解redis的学习笔记 文章目录 Rediswindwos安装docker安装redis启动redis使用RDM访问虚拟机中的redispython连接redis缓存穿透、击穿、雪崩基本数据类型高级数据类型高并发指标布隆过滤器分布式锁Redis 的有序集合底层为什么要用跳表而不用平衡树、红黑树或者 B树跳表 Bitmap的使用Redis线程模型Reactor 网络模型四种常见的IO模型BIO、NIO、AIOselect/epoll Redis内存管理RDB和AOFRedis持久化Redis集群Redis为什么要给key设置过期时间设置key过期时间的策略Redis过期删除与内存淘汰Redis缓存设计Redis实现延迟队列Redis的大key如何处理Redis 管道有什么用Redis 事务支持回滚吗如何用 Redis 实现分布式锁的Redis 如何解决集群情况下分布式锁的可靠性Redis lua脚本示例Redis 大 Key 对持久化有什么影响主从复制是怎么实现的repl_backlog_buffer和replication buffer的区别repl_backlog_bufferreplication buffer区别总结 哨兵机制数据库和缓存如何保证一致性Redis解决可能出现的并发问题Redis的扩容机制 Redis
windwos安装
参考[csdn]
docker安装redis
参考[csdn] [zhihu]
启动redis
sudo docker run -p 6379:6379 --name redis --restartalways -v /home/mkid/software/redis/data:/data -v /home/mkid/software/redis/redis2.conf:/etc/redis/redis.conf -d redis redis-server /etc/redis/redis.confvm.overcommit_memory 1
#任何ip可以访问
bind 0.0.0.0
#守护进程
#daemonize yes
daemonize yes
#不启用保护模式
protected-mode no
#指定redis运行的端口
port 6379
tcp-backlog 511
timeout 0
#持久化⽂件名称
dbfilename xdclass.rdb
#持久化⽂件存储路径
dir /data/
#持久化策略, 10秒内有个1个key改动执⾏快照
save 10 1
######之前配置######
#导出rdb数据库⽂件压缩字符串和对象,默认是yes会浪费CPU但是节省空间
rdbcompression yes
# 导⼊时是否检查
rdbchecksum yes
#aof持久化配置
#appendonly yes
#appendfilename appendonly.aof
#appendfsync everysec
# aof重写期间是否同步
no-appendfsync-on-rewrite no
# 重写触发配置
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
# 加载aof时如果有错如何处理
# yes表示如果aof尾部⽂件出问题写log记录并继续执⾏。
# no表示提示写⼊等待修复后写⼊
aof-load-truncated yesWARNING Memory overcommit must be enabled! Without it, a background save or replication may fail under low memory condition. Being disabled, it can also cause failures without low memory condition, see https://github.com/jemalloc/jemalloc/issues/1328. To fix this issue add vm.overcommit_memory 1 to /etc/sysctl.conf and then reboot or run the command sysctl vm.overcommit_memory1 for this to take effect.
这个警告是关于系统内存过度分配的设置。在 Redis 中如果系统的内存过度分配未启用可能会在低内存条件下导致后台保存或复制失败。即使没有低内存条件也可能导致一些问题。
要解决这个问题您需要将系统的内存过度分配设置为启用。您可以按照警告中提到的步骤执行 添加下面这行到 /etc/sysctl.conf 文件中 vm.overcommit_memory 1您可以使用文本编辑器如 nano 或 vim以管理员权限打开该文件并添加这一行到文件的底部。 重新加载 sysctl 配置以使更改生效 sudo sysctl -p这将重新加载 sysctl.conf 文件中的配置并且使 vm.overcommit_memory 设置生效。
请注意在生产环境中特别是在修改系统级配置之前请确保了解这些更改的含义并确保它们不会对系统的稳定性和安全性产生不利影响。
使用RDM访问虚拟机中的redis
RDF连接虚拟机里的Redishttps://blog.csdn.net/qq_39535807/article/details/106449156
python连接redis
redis_client redis.StrictRedis(hostlocalhost,port6379,db2,decode_responsesTrue
)缓存穿透、击穿、雪崩
参考[zhihu]
穿透恶意绕过缓存和数据库中都没有的数据。黑名单、缓存空值、布隆过滤器
击穿热点key失效访问热点的大量请求直接打到数据库上。互斥锁、异步更新缓存、不设置过期时间
雪崩大量缓存key失效大量请求直接达到数据库上。大量数据同时过期均匀设置过期时间、客户端访问互斥锁、后台更新缓存2种、缓存预热。Redis宕机熔断和限流、集群
基本数据类型
Redis 支持的基本数据类型主要有五种分别是 字符串(String): Redis 的字符串是二进制安全的这意味着它们可以包含任何数据比如 jpg 图片或者序列化的对象。一个字符串类型的值最多可以是 512MB。 哈希(Hash): Redis 哈希是键值对集合。Redis 哈希是字符串字段和字符串值之间的映射因此它们是适合用来表示对象的理想选择。 列表(List): Redis 列表是简单的字符串列表按照插入顺序排序。你可以添加一个元素到列表的头部左边或者尾部右边。 集合(Set): Redis 集合是字符串类型的无序集合。它是通过哈希表实现的所以添加、删除、查找的复杂度都是 O(1)。 有序集合(Sorted Set): Redis 有序集合和集合一样也是字符串类型的集合不同的是每个元素都会关联一个浮点数类型的分数。Redis 正是通过分数来为集合中的成员进行从小到大的排序。由于是通过分数进行排序所以即使是在有相同分数的情况下成员也会根据二进制顺序进行排序。不过由于存在分数你可以非常快速地获取一个分数范围内的成员这个操作的复杂度是 O(log(N))。 Sorted Set的使用[]
这些数据类型为 Redis 的使用提供了极大的灵活性使其不仅仅能够被用作简单的键值存储还可以用来实现复杂的数据结构服务器方案。
高级数据类型
除了前面提到的五种基本数据类型之外Redis 还支持以下几种数据类型和特殊的数据结构 HyperLogLog: 主要用于高效的基数统计其核心优势在于在使用极小的内存空间时能够处理大量数据的基数估计问题。HyperLogLog 提供了一种不精确的去重计数方案适用于大规模数据的去重计数如统计网站访问量中的独立访客数。 基数统计介绍[csdn] 地理位置(Geospatial): Redis 的地理位置类型允许你将用户定义的经纬度信息存储到 Redis 中并可以进行地理位置相关的操作比如计算两点之间的距离、查找某个半径内的点等。这是通过 Redis 的 Sorted Set 数据类型实现的但提供了专门的命令来处理地理空间信息。 流(Streams): 引入于 Redis 5.0流是 Redis 的一个更加复杂的数据类型设计用来存储一系列的消息。流可以被认为是一个日志类型的数据结构可用于存储一系列的事件或消息。流使得 Redis 能够更好地用于消息队列的应用场景支持多播、持久化、消息确认等特性。
这些数据类型和结构提供了更多的使用场景和可能性让 Redis 不仅仅是一个简单的键值存储系统而是一个多功能的数据结构服务器能够支持各种各样的应用场景。
高并发指标
参考[zhihu] 布隆过滤器
参考[csdn]
分布式锁
Redis 的有序集合底层为什么要用跳表而不用平衡树、红黑树或者 B树
跳表
参考[csdn]
Bitmap的使用
java guide 统计活跃用户
这段 Redis 命令使用了 SETBIT 操作它是一个位操作命令用于设置字符串值的指定位(bit)的值。这个命令通常用于实现位数组可以高效地存储和操作大量的布尔值比如标记、开关状态等。命令的格式如下
SETBIT key offset valuekey 是你想要操作的键。offset 是位的位置从 0 开始计数。value 只能是 1 或 0代表你想要设置的位的值。
对于你给出的命令
SETBIT 20210308 1 1在键 20210308 上将位于位置 1 的位设置为 1。SETBIT 20210308 2 1在键 20210308 上将位于位置 2 的位设置为 1。SETBIT 20210309 1 1在键 20210309 上将位于位置 1 的位设置为 1。
每个命令的返回值 (integer) 0 表示在执行操作之前指定的位的原始值是 0。如果原始值已经是 1则命令会返回 1。这里所有命令的返回值都是 0说明在这些操作执行之前所有指定的位都是 0。
这种类型的操作非常适合于记录和查询标记或者状态例如记录用户的登录天数或者标记某个特定的功能是否对用户可见。它能够以非常紧凑和高效的方式处理大量的布尔值。
这两个 Redis 命令使用了 BITOP 和 BITCOUNT 操作分别用于对位进行逻辑运算和统计设置为 1 的位的数量。下面是对这两个命令的解释
BITOP
BITOP operation destkey key [key ...]operation 是要执行的位操作可以是 AND、OR、XOR、NOT。destkey 是存储操作结果的键。key 是参与操作的一个或多个键。
在你的例子中
BITOP and desk1 20210308 20210309这个命令执行了一个 AND 位操作将键 20210308 和 20210309 的值进行按位与操作并将结果存储在 desk1 中。返回值 (integer) 1 表示结果键 desk1 现在有 1 个字节的长度。
BITCOUNT
BITCOUNT key [start end]key 是要计算的键。start 和 end 参数可选定义了要统计的字节范围。
对于你的第二个命令
BITCOUNT desk1这个命令统计了 desk1 中设置为 1 的位的数量。返回值 (integer) 1 表示在 desk1 的值中有 1 个位被设置为了 1。
结合你之前的 SETBIT 命令我们可以推断出 20210308 和 20210309 在至少一个相同的位置上都设置了位为 1因此 AND 操作后desk1 中也至少有一个位是 1。BITCOUNT 命令的结果进一步确认了这一点只有一个位被设置为 1。
这种操作通常用于处理和分析大量的布尔数据例如统计多个事件共同发生的次数或者进行集合的交集操作。
Redis线程模型
单线程模型。
为什么引入多线程提高网络IO的并行度
后台线程lazyfree 线程、unlink key / flushdb async / flushall async
unlink异步删除大key。 在linux系统中所有服务都是文件。在图片的最上方客户端的每个连接都是一个socket连接socket文件epoll系统调用的作用是多路监听文件标识符发生变化所以当某个客户端的socket连接文件发生变化时epoll_wait会检测到触发事件分发器执行后续的任务。
Reactor 网络模型
参考[掘金]
IO多路复用select/epoll和事件驱动异步IO的回调函数。
IO读写涉及到用户态和内核态的转变。
单线程模型。建立连接、数据读写都是一个线程
多线程模型。连接建立、IO事件读写、事件分发是一个线程数据读写完之后提交业务到线程池中处理
主从线程模型。主Reactor负责建立新连接、从Reactor负责IO读写事件-线程池/事件分发
四种常见的IO模型BIO、NIO、AIO
参考[csdn]
同步阻塞IOBIO、同步非阻塞IONIO、IO多路复用、异步IOAIO。
select/epoll
select 和 epoll 都是用于处理多个文件描述符的输入/输出准备就绪的I/O多路复用机制。它们使得单个进程/线程可以监视多个文件描述符以便知道是否有I/O操作可以执行这对于实现高性能的网络服务尤其重要。
select
select是最早的I/O多路复用接口之一它允许程序监视多个文件描述符等待一个或多个文件描述符成为“就绪”状态也就是说数据可读、可写或出现异常。它的基本原理是
当你有多个文件描述符比如套接字需要同时监视时你可以使用select函数。你需要提供三个集合读集合、写集合和异常集合以及一个最大等待时间。select会阻塞当前线程直到以下几种情况之一发生 至少有一个文件描述符就绪对应的操作可以无阻塞地进行。发生一个信号中断。超出了指定的最大等待时间。
select的缺点是它支持的文件描述符数量有限通常受限于1024并且随着监视的文件描述符数量增加性能会线性下降。
epoll
epoll是在Linux 2.6及其以后版本中引入的作为select和poll的现代替代品。epoll解决了select的一些主要限制尤其是在处理大量文件描述符时的性能问题。它的特点包括
支持的文件描述符数量远大于1024。使用一种更高效的机制来通知哪些文件描述符就绪这意味着不需要像select那样在每次调用时重新指定整个文件描述符集合。支持“边缘触发”和“水平触发”两种工作模式使其更加灵活。
epoll通过创建一个epoll实例然后向这个实例中添加或删除文件描述符来工作。当调用epoll_wait时它会返回自上次调用以来变为就绪状态的文件描述符这种方式比select的轮询效率更高。
总结而言epoll相对于select在处理大量并发连接时具有更高的效率和更好的可扩展性因此成为了高性能网络服务器编程的首选技术之一。
Redis内存管理
RDB和AOF
参考[zhihu]
Redis持久化
AOF刷盘和RDB快照。
aof的重写。后台子进程bgrewriteaof
rdb的save个bgsave。
Redis集群
redis的三种集群方式脑裂导致的数据丢失。
Redis为什么要给key设置过期时间
在Redis中设置键key的过期时间是一项非常重要的功能主要基于以下几个理由 内存管理Redis是一个基于内存的存储系统尽管它可以将数据持久化到磁盘上但其主要操作都是在内存中进行的。内存资源有限因此有效地管理内存非常关键。通过为键设置过期时间可以自动删除不再需要的数据从而释放宝贵的内存资源。这是一种自动的内存清理机制有助于避免内存被无限期地消耗。 数据有效性在很多应用场景中数据都有其有效期。例如缓存数据可能只在很短的时间内是有效的之后就变得陈旧了会话session数据在用户退出或会话超时后不再需要。为这些数据设置过期时间可以确保数据的新鲜度和相关性当数据过期后Redis会自动将其删除。 减少维护成本如果没有自动的过期机制应用开发者需要自己实现数据清理逻辑这不仅增加了开发的复杂性还可能会导致程序效率降低因为应用层面的数据清理通常不如Redis内部机制来得高效和可靠。 优化性能通过删除过期的键来释放内存空间可以保持Redis数据库的高性能。过多的冗余数据会降低数据操作的效率尤其是在进行键的查找、数据的读写等操作时。保持数据集的紧凑可以提高操作效率减少延迟。 支持特定应用逻辑有些应用场景本身就需要基于时间的自动逻辑处理比如临时访问令牌的过期处理、限时活动的数据管理等。Redis的过期时间功能天然支持这类需求使得开发这类功能时更加简便和高效。
综上所述设置键的过期时间是Redis管理内存、保证数据有效性、优化性能以及支持复杂应用逻辑的一个重要功能。这不仅减轻了开发者的负担还提升了应用的整体性能和用户体验。
设置key过期时间的策略
在Redis中设置键(key)的过期时间主要有以下几种策略 设置固定过期时间 EXPIRE key seconds为键设置过期时间时间单位为秒。PEXPIRE key milliseconds为键设置过期时间时间单位为毫秒。 这两个命令都是在设置键的过期时间时指定一个具体的时间长度键会在指定的时间后自动被删除。 设置具体过期的时间点 EXPIREAT key timestamp将键的过期时间设置为UNIX时间戳表示的某一具体时间点单位为秒。PEXPIREAT key millisecondsTimestamp将键的过期时间设置为UNIX时间戳表示的某一具体时间点单位为毫秒。 使用这两个命令可以设置键在某个具体的时间点过期而不是从当前时间开始计算的一个时间段。 设置键在不活动idle状态下的过期时间 Redis默认不支持基于不活动时间的自动过期策略。不过可以通过自定义脚本或应用逻辑来模拟这种行为比如定期检查键的最后访问时间并删除那些超过特定不活动时间阈值的键。 Redis本身不直接支持根据键的不活动时间自动设置过期时间但你可以通过一些额外的逻辑来模拟这种行为。这里给出一个简单的例子演示如何利用Redis的现有命令和一些外部逻辑来实现基于不活动时间的键过期策略 基本思路 对于每个键使用一个额外的键来记录最后一次访问时间。定期运行一个脚本或任务检查每个键的不活动时间。如果某个键的不活动时间超过了预设的阈值就删除该键。 实现步骤 假设你有一个键user:session:1234你想要在这个键30分钟内未被访问时自动删除它。 步骤 1设置最后访问时间键 每次访问user:session:1234时同时设置或更新一个与之关联的键来记录访问时间。例如可以用user:session:1234:last_access作为记录最后访问时间的键。 SET user:session:1234 some data
SET user:session:1234:last_access current unix timestamp步骤 2定期检查不活动时间 编写一个脚本或在应用中实现逻辑定期执行以下步骤 获取当前时间的UNIX时间戳。对于每个会话键获取其last_access键的值。计算当前时间与最后访问时间的差值。如果差值超过了预设的不活动阈值例如1800秒表示30分钟则删除该会话键及其last_access键。 示例脚本逻辑伪代码 current_time get_current_unix_timestamp()
keys get_all_session_keys() # 获取所有会话键for key in keys:last_access_key key :last_accesslast_access_time get_value(last_access_key) # 获取最后访问时间if current_time - last_access_time 1800: # 30分钟不活动delete_key(key) # 删除会话键delete_key(last_access_key) # 删除最后访问时间键步骤 3自动化执行检查任务 你可以使用cron作业Linux、计划任务Windows或者Redis自身的定时功能如果通过Lua脚本实现来定期执行上述检查脚本。 这个方法虽然不能直接通过Redis命令实现不活动过期但通过外部逻辑的辅助可以满足需求。需要注意的是这种方法可能会增加服务器负载并且在高并发场景下需要谨慎处理并发访问和更新last_access键的情况。 使用TTL命令查询剩余过期时间 TTL key查询键的剩余过期时间秒。PTTL key查询键的剩余过期时间毫秒。 这不是设置过期时间的策略但与管理键的过期时间密切相关可以帮助你了解键的当前过期状态。 移除过期时间 PERSIST key移除键的过期时间使其变成一个永久键。 如果之前为键设置了过期时间但后来决定让该键持久存储可以使用这个命令移除其过期时间。 设置键值与过期时间 在设置键值的同时设置过期时间这可以通过SET命令的选项来完成如SET key value EX seconds 或 SET key value PX milliseconds这可以减少命令的发送次数提高效率。
选择合适的过期时间策略取决于你的具体需求和场景。例如对于缓存数据通常会使用固定的过期时间而对于需要在特定时间点过期的数据比如临时活动信息则会设置具体过期的时间点。
Redis过期删除与内存淘汰 过期键的删除过期字典。惰性删除定时删除定期删除。
持久化时对过期的键如何处理RDB阶段、AOF阶段。
主从模式的过期键处理。
内存淘汰策略不进行数据淘汰、进行数据淘汰。
进行数据淘汰设置了过期时间的淘汰、没设置过期时间淘汰。 Redis缓存设计
雪崩、击穿、穿透。
动态缓存热点。zsetzadd, zrange
常见的缓存更新策略。旁路缓存、读穿/写穿缓存、写回策略-不用
Redis实现延迟队列
zset。
Redis的大key如何处理
String 类型的值大于 10 KB
Hash、List、Set、ZSet 类型的元素的个数超过 5000个
1、redis-cli --bigkeys 查找大key
2、使用 SCAN 命令查找大 key
3、使用 RdbTools 工具查找大 key
删除
分批次删除 异步删除Redis 4.0版本以上小林coding
Redis 管道有什么用
Redis 事务支持回滚吗
支持。只支持命令的回滚不保证事务的原子性。
如何用 Redis 实现分布式锁的
setnx 过期时间。
优缺点。
Redis 如何解决集群情况下分布式锁的可靠性
Redlock红锁。
Redis lua脚本示例
Redis 支持使用 Lua 脚本来执行复杂的操作这允许你在 Redis 服务器端执行一系列命令而无需往返于客户端和服务器之间从而提高效率。下面是一个使用 Lua 脚本操作 Redis 集合Set的示例。
假设我们要编写一个 Lua 脚本这个脚本的目标是
向一个集合中添加一些值。从另一个集合中移除一些值。返回第一个集合的所有成员。
在 Redis 中我们可以使用 SADD 命令来添加元素到集合中使用 SREM 命令来从集合中移除元素使用 SMEMBERS 命令来获取集合的所有成员。
Lua 脚本示例
-- 定义要操作的集合的键和要添加或移除的值
local addSetKey KEYS[1]
local removeSetKey KEYS[2]
local addValues ARGV[1]
local removeValues ARGV[2]-- 向 addSetKey 集合中添加元素
for value in string.gmatch(addValues, %S) doredis.call(SADD, addSetKey, value)
end-- 从 removeSetKey 集合中移除元素
for value in string.gmatch(removeValues, %S) doredis.call(SREM, removeSetKey, value)
end-- 返回 addSetKey 集合的所有成员
return redis.call(SMEMBERS, addSetKey)在这个脚本中KEYS[1] 和 KEYS[2] 是 Redis 键名参数ARGV[1] 和 ARGV[2] 是传递给脚本的值参数。string.gmatch 函数用于迭代参数中的每个值假设值由空格分隔。
使用该脚本的命令可能如下示例
redis-cli --eval script.lua mySet1 mySet2 , value1 value2 value3 value4 value5在这个命令中mySet1 和 mySet2 是操作的集合键value1 value2 value3 是要添加到 mySet1 的值value4 value5 是要从 mySet2 移除的值。请注意逗号后面是 ARGV 参数的开始。
请记住你需要将 script.lua 替换为你的 Lua 脚本文件的实际路径或者你可以直接在命令行中使用 EVAL 命令并直接传递 Lua 脚本的内容而不是文件路径。
Redis 大 Key 对持久化有什么影响
从aof和rdb两个方面说明。
主从复制是怎么实现的
确定主服务器和从服务器。
第一次同步三个阶段全量复制。从 psync- 主主 FULLRESYNC- 从主rdb - 从主写入缓存 - 从。
命令传播TCP长连接。
从服务器经理服务器。
增量复制。repl_backlog_buffer replication offset
repl_backlog_buffer和replication buffer的区别
这两个都在主服务器上。 repl_backlog_buffer和replication buffer是Redis复制机制中的两个重要组件它们在Redis的数据复制过程中扮演着关键的角色。尽管这两个组件在功能上有所重叠它们的主要目的和使用场景有所不同。以下是它们各自的概述和区别
repl_backlog_buffer
目的repl_backlog_buffer主要用于支持部分复制功能。它是一个固定大小的缓冲区用于保存最近的写命令。当一个从服务器与主服务器失去连接并稍后重新连接时它可以请求这个缓冲区中保存的命令来更新它丢失的数据而不是进行全量复制。特点这个缓冲区是环形的意味着当它满了以后新的写命令会覆盖最老的命令。缓冲区的大小可以配置从而影响Redis可以支持的网络分区恢复时间和从服务器断开时间。使用场景适用于网络不稳定或从服务器频繁断开连接的场景在这些情况下可以有效地减少数据同步的负担。
replication buffer
目的replication buffer用于存储正在复制到一个或多个从服务器的数据。当从服务器连接到主服务器请求数据时主服务器会使用这个缓冲区来暂存要发送的数据。特点与repl_backlog_buffer不同replication buffer的生命周期与复制会话相关联。它的大小根据需要动态调整以适应当前的复制负载。当复制完成或取消时相关的复制缓冲区将被清空。使用场景适用于全量复制的场景比如当一个新的从服务器被添加到Redis集群中或者一个从服务器因为故障或其它原因需要重新同步全部数据时。
区别总结
用途差异repl_backlog_buffer用于支持部分复制以减少因为网络问题或从服务器故障导致的数据重新同步需求而replication buffer用于在全量复制过程中暂存数据。生命周期repl_backlog_buffer是长期存在的用于记录最近的写操作其大小固定而replication buffer的生命周期与复制会话相关大小根据复制需求动态调整。配置和管理两者的配置和管理也有所不同反映了它们在Redis复制机制中的不同角色。
理解这两个组件及其区别有助于更好地管理和优化Redis的复制和数据同步机制。
哨兵机制
判断主节点故障。哨兵ping - 主/从
主观下线quorum法定人数- 客观下线。
哨兵leader。
主从故障转移。三个过程
主从节点切换。四个步骤
哨兵集群是如何组成的通过主节点的__sentinel__:hello频道
数据库和缓存如何保证一致性
先更新数据库还是先更新缓存都会出现数据不一致的情况
先更新数据库还是先删除缓存先更新数据库再删除缓存可以保证一致性
更新数据库和删除缓存两个分开进行后者操作失败怎么办重试机制-消息队列、mysql binlog
先删除缓存再更新数据库数据不一致。延迟双删
Redis解决可能出现的并发问题
Redis和Lua脚本结合可以有效地解决一些并发问题尤其是在多个客户端同时访问Redis数据库时。下面是一个简单的示例演示如何使用Redis和Lua脚本来解决并发问题
假设我们有一个需求多个客户端需要同时对某个计数器进行操作但是我们希望保证在任何时刻计数器的值都是正确的而不会出现竞态条件。
首先我们可以使用Redis的INCR和DECR命令来实现计数器的自增和自减操作。但是如果多个客户端同时尝试修改计数器的值就会出现竞态条件导致结果不确定。
为了解决这个问题我们可以使用Lua脚本来将自增和自减操作原子化。以下是一个简单的Lua脚本示例
local counter_key KEYS[1]
local action ARGV[1]if action increment thenreturn redis.call(INCR, counter_key)
elseif action decrement thenreturn redis.call(DECR, counter_key)
elsereturn nil
end然后我们可以将这个Lua脚本保存到Redis中并通过调用EVAL命令来执行它。在调用EVAL命令时我们需要传递计数器的键名和要执行的操作作为参数。
以下是一个示例的Python代码演示了如何使用Redis-py库在Python中调用Lua脚本
import redis# 连接到Redis服务器
r redis.Redis(hostlocalhost, port6379, db0)# 保存Lua脚本
lua_script
local counter_key KEYS[1]
local action ARGV[1]if action increment thenreturn redis.call(INCR, counter_key)
elseif action decrement thenreturn redis.call(DECR, counter_key)
elsereturn nil
end
# 执行Lua脚本
def execute_lua_script(counter_key, action):return r.eval(lua_script, 1, counter_key, action)# 使用示例
counter_key my_counter
print(Incrementing counter:, execute_lua_script(counter_key, increment))
print(Decrementing counter:, execute_lua_script(counter_key, decrement))这样无论多少个客户端同时尝试修改计数器的值都可以保证操作的原子性从而避免了竞态条件的发生。
Redis的扩容机制
Redis的扩容机制主要涉及增加更多的内存资源和提升处理能力以应对数据增长和访问压力。这种扩容通常通过增加更多的Redis节点来实现分为两种基本模式分片Sharding和复制Replication。在更复杂的场景下Redis Cluster提供了一种综合使用分片和复制的解决方案来实现扩容和高可用。
分片Sharding
分片是通过分散数据到多个Redis服务器来减轻单个服务器的负担每个分片处理数据集的一部分。这样每个Redis实例只需存储总数据集的一部分从而可以水平扩展数据库的存储能力和处理能力。客户端库通常负责确定数据应该存储在哪个分片上这通常是通过一致性哈希或其他哈希机制来实现的。
优点
水平扩展可以通过添加更多的Redis服务器来增加总体的存储容量和处理能力。负载均衡均匀分布数据和请求可以防止任何单个节点成为瓶颈。
缺点
数据管理复杂性增加需要确保数据均匀分布避免某些节点过载。跨节点操作受限例如对于需要同时处理多个键的操作如果这些键分布在不同的节点上将难以实现。
复制Replication
复制是指将数据从一个Redis服务器复制到一个或多个Redis服务器的过程通常用于提高数据的可用性和读取性能。复制允许在主节点上进行写操作而从节点提供读服务。在出现故障时可以从从节点进行故障转移。
优点
高可用性如果主节点失败从节点可以接管成为新的主节点保证服务的可用性。读扩展可以通过增加更多的从节点来扩展读取能力。
缺点
写操作不扩展所有写操作都必须在主节点上执行因此写能力的扩展受到限制。数据延迟从节点复制数据可能会有延迟。
Redis Cluster
Redis Cluster是一个提供自动分片和数据复制的Redis部署方案旨在提供高性能、线性扩展性和高可用性。它通过自动将数据分散到多个节点每个节点存储数据集的一部分并在这些节点之间进行复制来实现这一点。
特点
自动分片数据自动分布在多个节点上简化了分片管理。高可用性通过数据复制和故障转移机制确保服务即使在节点故障时也能继续运行。读写扩展支持通过增加更多节点来扩展读写能力。
实施扩容
在实施Redis扩容时应考虑以下因素
数据迁移当添加新的节点时可能需要重新分配现有数据这可能会暂时影响性能。客户端支持确保客户端库支持所选择的扩容方案如自动分片支持或Redis Cluster。监控和调整扩容后需要监控系统性能并根据实际情况进行调整以确保系统达到预期的性能和稳定性目标。
Redis的扩容机制提供了灵活的方案来应对不断增长的数据和请求负载但实施时需要综
。复制允许在主节点上进行写操作而从节点提供读服务。在出现故障时可以从从节点进行故障转移。
优点
高可用性如果主节点失败从节点可以接管成为新的主节点保证服务的可用性。读扩展可以通过增加更多的从节点来扩展读取能力。
缺点
写操作不扩展所有写操作都必须在主节点上执行因此写能力的扩展受到限制。数据延迟从节点复制数据可能会有延迟。
Redis Cluster
Redis Cluster是一个提供自动分片和数据复制的Redis部署方案旨在提供高性能、线性扩展性和高可用性。它通过自动将数据分散到多个节点每个节点存储数据集的一部分并在这些节点之间进行复制来实现这一点。
特点
自动分片数据自动分布在多个节点上简化了分片管理。高可用性通过数据复制和故障转移机制确保服务即使在节点故障时也能继续运行。读写扩展支持通过增加更多节点来扩展读写能力。
实施扩容
在实施Redis扩容时应考虑以下因素
数据迁移当添加新的节点时可能需要重新分配现有数据这可能会暂时影响性能。客户端支持确保客户端库支持所选择的扩容方案如自动分片支持或Redis Cluster。监控和调整扩容后需要监控系统性能并根据实际情况进行调整以确保系统达到预期的性能和稳定性目标。
Redis的扩容机制提供了灵活的方案来应对不断增长的数据和请求负载但实施时需要综
