Redis

PHP + Redis实现订单超时 针对秒杀场景下的订单超时未支付自动取消，这是一个典型需求。由于秒杀需要快速释放被占用的库存，所以超时机制的设计非常关键。 一、核心思路 订单创建时：记录超时时间（如 30 分钟），将订单 ID 推入 Redis 的 Sorted Set（有序集合），score 为超时时间戳。 定时轮询：启动一个 PHP 常驻进程，每隔 1-2 秒轮询 Sorted Set，取出已超时的订单 ID。 超时处理：更新 MySQL 订单状态为“已取消”，并恢复 Redis 中的秒杀库存（如果业务要求释放库存）。 无需额外组件：纯 Redis + PHP，不依赖 RabbitMQ 的延迟队列或 RocketMQ。 二、详细设计 1. 订单表增加字段 ALTER TABLE orders ADD COLUMN status TINYINT DEFAULT 0 COMMENT '0-待支付 1-已支付 2-已取消 3-已超时'; ALTER TABLE orders ADD COLUMN expire_time DATETIME COMMENT '订单超时时间'; 2. 创建订单时：加入超时监控 在秒杀成功、订单写入 MySQL 后（或写入 Redis 队列时），同时将订单 ID 加入 Redis Sorted Set：...

PHP 实现 Redis 高并发解决方案 使用 PHP 实现 Redis 在缓存加速、分布式锁和队列场景中的应用。 首先确保已安装 PHP Redis 扩展 一、缓存加速实现 1. 基本缓存操作 <?php $redis = new Redis(); $redis->connect('127.0.0.1', 6379); // 设置缓存 function setCache($key, $value, $expire = 3600) { global $redis; $serialized = serialize($value); return $redis->setex($key, $expire, $serialized); } // 获取缓存 function getCache($key) { global $redis; $serialized = $redis->get($key); return $serialized ? unserialize($serialized) : false; } // 删除缓存 function deleteCache($key) { global $redis; return $redis->del($key); } // 示例：用户数据缓存 function getUser($userId) { $cacheKey = "user:{$userId}"; $user = getCache($cacheKey); if ($user === false) { // 模拟数据库查询 $user = [ 'id' => $userId, 'name' => 'User ' ....

PHP + Redis秒杀场景 在电商秒杀等高并发场景中，Redis 凭借其内存操作和原子性特性，成为库存扣减的核心组件。 下面以 PHP + Redis 为例，给出一个企业级秒杀库存设计方案示例，重点解决超卖、热点 Key、重复下单和流量冲击等问题。 一、核心思路 预加载库存：秒杀活动开始前，将商品库存从 MySQL 同步到 Redis（使用 SET 或 HMSET）。 原子扣减：使用 Redis Lua 脚本（或 DECR + 校验）保证扣减与校验的原子性，杜绝超卖。 异步落库：扣减成功后，将用户 ID、商品 ID 推入消息队列（如 Redis Stream / List），后台进程消费并创建订单、扣减数据库库存。 限流 + 防重：通过令牌桶或滑动窗口限制用户访问频率，通过 Redis 记录用户抢购状态防止同一用户重复下单。 二、详细步骤与代码实现 1. 活动开始前：初始化库存 // 假设商品ID=1001，秒杀库存=100 $redis->set('seckill:stock:1001', 100); $redis->set('seckill:closed:1001', 0); // 0-未结束，1-已结束 2. 抢购接口核心：Lua 脚本原子扣减 $lua = <<<LUA local stock_key = KEYS[1] local user_key = KEYS[2] -- 用于记录已抢购用户 local user_id = ARGV[1] local closed_key = KEYS[3] -- 检查活动是否已结束 if redis....

Redis分布式锁 一、 Redis锁基础概念 1. 为什么需要Redis锁 Redis锁是一种基于内存数据库Redis实现的分布式锁机制，主要解决分布式系统中的资源竞争问题。相比数据库锁，Redis锁具有以下优势 高性能：基于内存操作，响应速度快 原子性保证：Redis单线程模型天然支持原子操作 分布式支持：可跨多台服务器使用 丰富的数据结构：支持多种锁实现方式 2. 基本实现原理 最简单的Redis锁实现方式： SET resource_name my_random_value NX PX 30000 NX：仅当key不存在时设置 PX：设置过期时间(毫秒) my_random_value：唯一标识，用于安全释放锁 二、Redis锁的实现方式 1. SETNX实现（基本方式） 实现步骤： 尝试获取锁：SETNX lock_key 1 获取成功则设置过期时间：EXPIRE lock_key 30 执行业务逻辑 释放锁：DEL lock_key 问题： 非原子操作，SETNX和EXPIRE之间可能崩溃导致死锁 2. SET扩展参数实现（推荐） Redis 2.6.12+版本支持扩展参数，可原子性完成设置 SET lock_key unique_value NX PX 30000 PHP实现示例： $redis = new Redis(); $redis->connect('127.0.0.1', 6379); $lockKey = 'order_lock_123'; $uniqueId = uniqid(); $expire = 30000; // 30秒 // 尝试获取锁 $acquired = $redis->set($lockKey, $uniqueId, ['NX', 'PX' => $expire]); if ($acquired) { try { // 执行业务逻辑 processOrder(); } finally { // 使用Lua脚本保证原子性释放 $script = " if redis....

Redis高可用 1. 事务机制和IO多路复用 1.1 事务 1.1.1 事务特点 事务提交前，先检查命令语法是否正确 提交后的命令一定会执行 有命令报错，也会执行完 不能回滚 1.1.2 命令 multi，告诉Redis服务器开启一个事务。只是开启而不是执行。 exec, 告诉Redis开始执行事务 discard，告诉Redis取消事务 watch，监视某一个键值对，它的作用是在事务执行之前如果监视的键值被修改，事务会被取消 1.2 IO多路复用 redis 是单线程，单线程只能在一个CPU内核上执行，假如是4核的，只会占用一个，其它三个不参与。 worker线程串行 read读->计算->write返回 在Redis6.0加入了io-threads， 主线程worker只进行计算，并行读取 io-threads 4 io-threads-do-reads yes 2. 持久化和过期淘汰策略 2.1 持久化 Redis是存储在内存中的， 服务器重启数据会丢失。持久化方案可以保存数据到磁盘文件，可以恢复到内存中。Redis提供的持久化方案有： rdb：生成某一时刻的快照，保存到二进制文件中 优点： 容灾性好，方便备份 性能最大化，fork出一个子进程来操作，对主进程没有影响 数据较多时，相对于aof启动效率更高 缺点： 会造成数据丢失 aof：实时记录每一条写命令，追加到文件中，打开可以看到具体的操作记录 同步策略：appendfsync everysec(默认),每秒同步一次 always，每次操作后都要同步一次 no,由操作系统调度进行同步 重写策略： 手动触发，执行bgrewiteaof命令 自动触发：auto-rewrite-percentage 100, auto-rewrite-min-size 64mb 优点 数据安全，不会造成数据的丢失 缺点 比rdb重启效率低；运行效率比rdb低 混合模式：上面两种方式的结合 触发方式有两种： 手动触发： save命令，会让Redis处于阻塞的状态，直到rdb持久化完成，线上环境谨慎使用 bgsave命令,它会fork出一个子进程（有短暂阻塞），用来执行持久化，主进程继续响应客户端请求 自动触发： 配置文件修改（save n m），在n秒内,有m个key发生变化就会触发，执行命令最总执行的是bgsave 2.2 过期键删除策略 Redis设置key时，都会设置一个过期时间，Redis同时使用了两种过期删除策略，惰性过期和定时过期...

Redis主从复制 一、什么是Redis主从复制 1. 从复制的架构： Redis Replication是一种 master-slave 模式的复制机制，这种机制使得 slave 节点可以成为与 master 节点完全相同的副本，可以采用一主多从或者级联结构。 主从复制的配置要点： 配从库不配主，从库配置：slaveof 主库IP 主库端口 查看redis的配置信息：info replication 2. Redis为什么需要主从复制？ 使用Redis主从复制的原因主要是单台Redis节点存在以下的局限性： Redis虽然读写的速度都很快，单节点的Redis能够支撑QPS大概在5w左右，如果上千万的用户访问，Redis就承载不了，成为了高并发的瓶颈。 单节点的Redis不能保证高可用，当Redis因为某些原因意外宕机时，会导致缓存不可用 CPU的利用率上，单台Redis实例只能利用单个核心，这单个核心在面临海量数据的存取和管理工作时压力会非常大。 3. 主从复制的好处： 数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。 故障恢复：如果master宕掉了，使用哨兵模式，可以提升一个 slave 作为新的 master，进而实现故障转移，实现高可用 负载均衡：可以轻易地实现横向扩展，实现读写分离，一个 master 用于写，多个 slave 用于分摊读的压力，从而实现高并发； 4. 主从复制的缺点： 由于所有的写操作都是先在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave服务器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使这个问题更加严重 二、主从复制的原理 从总体上来说，Redis主从复制的策略就是：当主从服务器刚建立连接的时候，进行全量同步；全量复制结束后，进行增量复制。当然，如果有需要，slave 在任何时候都可以发起全量同步。 1、主从全量复制的流程： Redis全量复制一般发生在Slave初始化阶段，这时Slave需要将Master上的所有数据都复制一份，具体步骤如下： slave服务器连接到master服务器，便开始进行数据同步，发送psync命令（Redis2.8之前是sync命令） master服务器收到psync命令之后，开始执行bgsave命令生成RDB快照文件并使用缓存区记录此后执行的所有写命令 如果master收到了多个slave并发连接请求，它只会进行一次持久化，而不是每个连接都执行一次，然后再把这一份持久化的数据发送给多个并发连接的slave。 如果RDB复制时间超过60秒（repl-timeout），那么slave服务器就会认为复制失败，可以适当调节大这个参数 master服务器bgsave执行完之后，就会向所有Slava服务器发送快照文件，并在发送期间继续在缓冲区内记录被执行的写命令 client-output-buffer-limit slave 256MB 64MB 60，如果在复制期间，内存缓冲区持续消耗超过64MB，或者一次性超过256MB，那么停止复制，复制失败 slave服务器收到RDB快照文件后，会将接收到的数据写入磁盘，然后清空所有旧数据，在从本地磁盘载入收到的快照到内存中，同时基于旧的数据版本对外提供服务。 master服务器发送完RDB快照文件之后，便开始向slave服务器发送缓冲区中的写命令 slave服务器完成对快照的载入，开始接收命令请求，并执行来自主服务器缓冲区的写命令； 如果slave node开启了AOF，那么会立即执行BGREWRITEAOF，重写AOF 2、增量复制： Redis的增量复制是指在初始化的全量复制并开始正常工作之后，master服务器将发生的写操作同步到slave服务器的过程，增量复制的过程主要是master服务器每执行一个写命令就会向slave服务器发送相同的写命令，slave服务器接收并执行收到的写命令。 3、断点续传： 什么是断点续传： 当master-slave网络连接断掉后，slave重新连接master时，会触发全量复制，但是从2.8版本开始，slave与master能够在网络连接断开重连后，只从中断处继续进行复制，而不必重新同步，这就是所谓的断点续传。 断电续传这个新特性使用psync命令，旧的实现中使用sync命令。Redis2.8版本可以检测出它所连接的服务器是否支持PSYNC命令，不支持的话使用SYNC命令。master服务器收到slave发送的psync命令后，会根据自身的情况做出对应的处理，可能是FULLRESYNC runid offset触发全量复制，也可能是CONTINUE触发增量复制 命令格式：psync runid offset 工作原理：...

Redis持久化及过期删除策略 Redis 持久化之RDB和AOF RDB 详解 快照（snapshotting，RDB） RDB 是 Redis 默认的持久化方案。在指定的时间间隔内，执行指定次数的写操作，则会将内存中的数据写入到磁盘中。即在指定目录下生成一个dump.rdb文件。Redis 重启会通过加载dump.rdb文件恢复数据 从配置文件了解RDB 打开 redis.conf 文件，找到 SNAPSHOTTING 对应内容 RDB核心规则配置（重点） save <seconds> <changes> #save "" save 900 1 save 300 10 save 60 10000 说明：save <指定时间间隔> <执行指定次数更新操作>，满足条件就将内存中的数据同步到硬盘中。官方出厂配置默认是 900秒内有1个更改，300秒内有10个更改以及60秒内有10000个更改，则将内存中的数据快照写入磁盘。 若不想用RDB方案，可以把 save “” 的注释打开，下面三个注释。 指定本地数据库文件名，一般采用默认的 dump.rdb dbfilename dump.rdb 指定本地数据库存放目录，一般也用默认配置 dir ./ 默认开启数据压缩 rdbcompression yes 解说：配置存储至本地数据库时是否压缩数据，默认为yes。Redis采用LZF压缩方式，但占用了一点CPU的时间。若关闭该选项，但会导致数据库文件变的巨大。建议开启。 触发RDB快照 在指定的时间间隔内，执行指定次数的写操作 执行save（阻塞， 只管保存快照，其他的等待） 或者是bgsave （异步）命令 执行flushall 命令，清空数据库所有数据，意义不大。 执行shutdown 命令，保证服务器正常关闭且不丢失任何数据，意义…也不大。 注意： save备份过程：save备份是同步的，如果备份的数据量过大的话，服务器会暂停几百毫秒甚至是1秒 bgsave备份过程：bgsave备份会单独创建一个子进程，将备份的数据写入一个临时文件 RDB数据还原 找到备份临时文件的指令是 config get dir 指令执行成功以后将备份临时文件的目录拷贝到Redis的安装目录下 然后重新启动Redis服务就成功还原数据了...

Redis中的Lua 一. Redis中的Lua脚本的作用 Redis中的Lua脚本主要解决复杂操作的原子性和性能优化两大核心问题。它允许你在Redis服务器端直接执行自定义的逻辑，而不是把数据拉到客户端处理后再写回去。 核心作用 1. 保证原子性操作 Redis执行Lua脚本时，脚本中的所有命令会作为一个整体被执行，中间不会被其他命令插入。这完美解决了多命令组合操作时的并发安全问题。 经典场景： 实现分布式锁、库存扣减、限流计数器等。比如秒杀场景下，检查库存、扣减库存、记录订单这三个操作必须原子执行，用Lua脚本就能确保数据一致性。 2. 减少网络开销 将多个Redis命令合并到一个Lua脚本中，原本需要多次网络请求的操作变成一次请求完成。数据在Redis服务器本地处理，避免了大量数据在客户端和服务器之间来回传输。 3.扩展Redis指令集 你可以用Lua实现Redis原生不支持的复杂业务逻辑。比如自定义数据结构操作、复杂条件判断、循环处理等，让Redis变成一个具备计算能力的"小数据库"。 4. 提高代码复用率 脚本可以被缓存到Redis服务器，客户端通过SHA1摘要重复调用，无需每次都发送完整的脚本代码。多个应用可以共享同一套脚本逻辑 总结 Redis Lua脚本让你能把多个操作打包成一个原子性的、在服务器本地执行的任务，既保证了数据一致性，又提升了性能。特别适合秒杀、分布式锁、计数器、复杂条件更新等需要"读-改-写"原子操作的场景。 二、Lua安装 windows下载地址 ：https://luabinaries.sourceforge.net/ 三 、 Lua在Redis中最常用、最经典的几个应用场景 1. 在Redis中操作Lua脚本的常用命令 命令 作用 一句话解释 EVAL 执行给定的Lua脚本 直接把脚本和参数传给Redis运行一次。 SCRIPT LOAD 将脚本缓存到Redis 把脚本存到Redis里，会返回一个SHA1值作为“脚本ID”。 EVALSHA 根据SHA1值执行缓存的脚本 拿着“脚本ID”去执行之前存好的脚本，省流量，效率更高。 SCRIPT EXISTS 检查脚本是否已缓存 看看某个“脚本ID”对应的脚本还在不在Redis里。 SCRIPT KILL 终止正在运行的脚本 如果脚本执行太久卡住了，可以用这个命令尝试杀掉它。 SCRIPT FLUSH 清空所有缓存的脚本 一键清除Redis里缓存的所有脚本，操作要小心\-1。 2. 五大经典应用场景 分布式锁 这是Lua脚本在Redis中最经典的应用。获取锁和释放锁的多个步骤必须是一个原子操作，否则会出现并发问题。 获取锁：使用 SET NX PX 命令，一步到位地尝试设置一个带过期时间的键，保证只有一个客户端能拿到锁-8。 释放锁：释放锁时，需要先检查当前持有锁的客户端是否就是自己（通过一个唯一值比如UUID判断），然后再删除锁。这两个动作必须通过Lua脚本一起执行，才能避免误删别人的锁-2-8。 -- 安全的释放锁脚本 -- KEYS[1]: 锁的名称 -- ARGV[1]: 客户端的唯一标识 if redis....

Redis分布式 一、 Redis分布式概述 1. 什么是Redis分布式 Redis分布式是指将Redis数据分布到多个Redis节点上，通过集群方式提供更高性能、更大容量和更好可用性的解决方案。 1.2 为什么需要Redis分布式 数据量增长：单机内存容量有限 高并发需求：单机性能瓶颈 高可用性：避免单点故障 可扩展性：支持业务动态扩容 1.3 Redis分布式方案对比 方案 优点 缺点 使用场景 主从复制 部署简单，读写分离 写操作单点，故障需手动切换 读多写少，数据备份 Redis Sentinel 自动故障转移，高可用 配置复杂，扩容不便 生产环境高可用 Redis Cluster 数据分片，自动故障转移 客户端兼容性要求，迁移复杂 大数据量，高并发 二、 Redis分布式方案搭建 2.1 主从复制搭建 配置文件示例 主节点 (master.conf): port 6379 daemonize yes pidfile /var/run/redis_6379.pid logfile "/var/log/redis_6379.log" 从节点 (slave.conf): port 6380 daemonize yes pidfile /var/run/redis_6380.pid logfile "/var/log/redis_6380.log" slaveof 127.0.0.1 6379 启动命令 # 启动主节点 redis-server master.conf # 启动从节点 redis-server slave.conf 2.2 Redis Sentinel搭建 Sentinel配置文件...

Redis的一些常见题 redis数据类型及应用场景 见 Redis的五种数据类型及使用场景 redis持久化及过期策略 见 Redis持久化及过期删除策略 redis 常见问题及解决方案 缓存雪崩：同一时间大量缓存失效，导致请求直接查询数据库，数据库内存和CPU压力增加甚至宕机 解决： 热点数据永不过期或者分布到不同实例，降低单机故障问题 缓存时间添加随机数，防止大量缓存同时失效 做二级缓存或者双缓存，A为原始缓存 短时效，B为备份缓存 ，长期有效。更新时候双写缓存 缓存穿透：缓存和数据库都没有数据，大量请求下，所有请求直接击穿到数据库，导致宕机。 解决： 布隆过滤器:长度为m的位向量或者位列表组成（仅包含0或1位值的列表） 使用多个不用的hash函数，产生多个索引值，填充对应多个位置的值为1 布隆过滤器可以检查值是 “可能在集合中” 还是 “绝对不在集合中” 可能误判但是基础过滤效率高 极端情况，当布隆过滤器没有空闲位置的时候每次查询返回true 空缓存（短时效） 业务层参数过滤 缓存击穿：数据库中有数据，但是缓存突然失效之后发生大量请求导致数据库压力增加甚至打垮宕机 解决： 热点数据永不过期 互斥锁：获取锁之后不管成功还是失败都要释放锁 Redis主从复制原理 Redis 在复制时底层采用的是 psync 命令完成的数据主从同步，同步主要分为：全量复制和增量复制两种 全量复制：顾名思义也就是一次性把主节点数据全部发送给从节点，所以这种情况下，当数据量比较大时，会对主节点和网络造成很大的开销。 部分复制：用于处理主从复制时因网络中断等原因造成数据丢失的场景。当从节点再次和主节点连接时，主节点会补发丢失的数据。因为是补发，所以在发送的数据量一定是小于全量的数据。 详细见 Redis的一些常见题 Redis缓存和数据库数据一致性问题： 读数据 尝试查询缓存，存在缓存则直接返回数据 缓存不存在时则查询数据库，并保存到缓存（合适设置过期时间），返回数据 写数据 先更新缓存再更新数据库 或者 先删除缓存再更新数据库 先更新数据库再更新缓存 或者 先更新数据库再删除缓存 使用删除还是更新？ 这里无非是删除还是更新Redis，直接删除的方式比较简单，在下一次查询时会生成缓存（更推荐）；更新缓存则相较复杂 先操作Redis还是先操作数据库？ 先操作数据库 （推荐） 流程:先更新数据库，再删除缓存 问题：比如线程1执行写操作（修改数据库->删除缓存），线程2执行读操作（查询缓存->旧数据），就会出现旧数据返回，或者删除缓存失败也会返回旧数据 先操作缓存 流程：修改操作先删除缓存再修改数据库 问题： 比如线程1去执行写操作： （删除缓存->更新数据库）同时有线程2执行读操作（查询缓存（未查到缓存）->查数据库->保存到缓存）因为数据库更新有可能网络延迟等问题，这里保存到缓存的数据就是旧的数据，只有再过期之后才会读到新数据 解决方案： （延迟双删）在数据库更新之后再进行一次缓存删除（加适当延迟，比如延迟500ms），这时再有查询过来也会查询到数据库并保存到缓存。但是线程2在这个删除缓存500ms内请求仍然可能会出现一次获取到旧数据 （推荐方式）