各位观众，晚上好！欢迎来到今晚的“Redis骚操作”讲座。今天咱们要聊的是Redis Set集合，这玩意儿可不是简单的存几个字符串就完事儿的，它能玩出很多花样，特别是跟用户标签、共同好友这些场景结合起来，简直是如虎添翼。 一、Redis Set：集合的本质和特性 首先，咱们得搞清楚Set是个什么玩意儿。你可以把它想象成一个袋子，这个袋子里装了很多东西（也就是字符串），但是有个规矩： 唯一性： 袋子里不能有重复的东西，放进去重复的会自动忽略。 无序性： 袋子里的东西没有特定的顺序，你想按照什么顺序拿出来，那是你的事儿。 Redis Set 提供了以下常用命令： 命令 描述 示例 SADD key member [member …] 向集合 key 中添加一个或多个成员。 SADD user:1:tags “geek” “developer” SMEMBERS key 返回集合 key 中的所有成员。 SMEMBERS user:1:tags SISMEMBER key member 判断 member 元素是否是集合 key 的成员。 SISMEMBER user:1:tags “g …
Redis `Bitmaps` 位图：用户在线状态与活跃度统计
各位观众，各位朋友，程序员们，大家好！今天我们来聊聊 Redis 的 Bitmaps，这玩意儿听起来好像很高大上，其实用起来相当接地气。咱们今天就把它扒个精光，看看它怎么帮我们搞定用户在线状态和活跃度统计这种常见需求。 开场白：为啥要用 Bitmaps？ 在互联网的世界里，用户就是上帝。但是上帝太多了，动不动就几百万、几千万，甚至上亿。要实时追踪每个用户的在线状态，或者统计他们的活跃度，那可不是件容易事。 最简单粗暴的方法，莫过于给每个用户建个 boolean 类型的字段，比如 is_online。用户在线就设为 true，离线就设为 false。看起来挺合理，但问题是：数量级一大，内存消耗就爆炸了！ 假设我们有 1 亿用户，每个 boolean 类型占 1 个字节，那光是存储在线状态就要 100MB。这还没算上其他数据呢！而且，要统计有多少用户在线，还得遍历一遍所有用户，效率低到令人发指。 这时候，Bitmaps 就该闪亮登场了。Bitmaps 是一种基于位的存储结构，说白了，就是把每个用户的状态映射到一个 bit 上。一个 bit 只有两种状态：0 和 1，分别表示用户离线和在线。 …
Redis `Pub/Sub` 发布订阅模式：消息广播与事件通知
各位观众，各位朋友，大家好！今天咱们来聊聊Redis的Pub/Sub，也就是发布订阅模式。这玩意儿啊，就像一个大喇叭，你对着它喊一嗓子，所有订阅了这个喇叭的人都能听到。听起来挺简单的，但用好了，能解决不少实际问题。 啥是Pub/Sub？为啥要用它？ 首先，咱们得明白啥是Pub/Sub。简单来说，就是一种消息通信模式，它把消息的发送者（Publisher）和接收者（Subscriber）解耦了。 Publisher负责发布消息， Subscriber负责订阅感兴趣的消息。两者之间不需要知道对方的存在，通过一个中间的“频道”（Channel）或者“模式”（Pattern）进行通信。 那为啥要用它呢？好处多多啊！ 解耦: Publisher和Subscriber之间没有直接依赖关系，修改一方不会影响另一方。 异步: Publisher发布消息后，不用等待Subscriber处理完成，可以继续做自己的事情，提高了系统的响应速度。 扩展性: 可以方便地增加或减少Subscriber，而无需修改Publisher的代码。 实时性: 消息可以实时地推送到Subscriber，适用于实时通知、聊天室等 …
Redis 延迟队列：基于 ZSet 或 Stream 的实现
好的，咱们今天来聊聊Redis的延迟队列，这玩意儿在异步任务处理中可是个宝贝。别害怕，咱们不搞那些高深的理论，就用大白话和实际代码，把基于ZSet和Stream两种方式的实现给它扒个精光。 啥是延迟队列？为啥要用Redis？ 想象一下，你搞了个电商网站，用户下单后不是立马就要发货，可能要等个30分钟，让用户有机会取消订单。或者说，你有个定时任务，需要在每天凌晨3点跑一下。这些场景，都需要用到延迟队列。 延迟队列，说白了，就是把要执行的任务先“藏”起来，等到预定的时间点再拿出来执行。 那为啥要用Redis来实现呢？原因很简单： 速度快： Redis是基于内存的，读写速度嗖嗖的。 简单易用： Redis的数据结构非常适合实现延迟队列。 持久化： Redis支持持久化，不怕数据丢了。 成熟稳定： Redis经过了大量的实践检验，稳定性没得说。 第一种方法：ZSet（Sorted Set）实现延迟队列 ZSet，有序集合，是Redis里面一个非常有用的数据结构。它里面的每个元素都有一个score，可以根据score进行排序。这简直就是为延迟队列量身定做的啊！ 原理： 把要延迟执行的任务作为ZS …
Redis `Sorted Set` 排行榜：实时更新与区间查询优化
各位技术同仁，大家好！今天我们要聊聊 Redis Sorted Set 在排行榜应用中的骚操作，保证让你听完之后，下次再碰到排行榜需求，嘴角能不自觉地微微上扬。 一、排行榜：一个老生常谈的问题，但依旧很性感 排行榜，这玩意儿听起来好像很古老，但实际上在各种 App、游戏、活动中都扮演着重要角色。你想想，哪个游戏没有个战力榜？哪个 App 没有个活跃用户榜？哪个活动没有个积分榜？ 排行榜的核心需求其实很简单： 实时更新： 用户行为发生变化，排名要立刻刷新。 区间查询： 快速获取指定范围内的排名数据（比如 Top 10、我的排名附近的人）。 看似简单，但如果数据量一大，传统的数据库方案（比如 MySQL）就容易捉襟见肘，性能瓶颈分分钟教你做人。而 Redis Sorted Set，作为排行榜的黄金搭档，凭借其独特的魅力，能优雅地解决这些问题。 二、Redis Sorted Set：排行榜的瑞士军刀 Sorted Set，顾名思义，是一个有序的集合。它的特点是： 每个元素都有一个分数（score）： 这个分数决定了元素在集合中的排序位置。 元素是唯一的： 集合中的元素不能重复。 有序性： 元 …
Redis 全文搜索 (RediSearch)：索引构建与复杂查询
大家好，欢迎来到今天的RediSearch全文搜索讲座。今天我们要聊的是RediSearch中最核心的部分：索引构建和复杂查询。准备好了吗？让我们开始吧！ RediSearch：不只是个缓存，还是个搜索高手 Redis，我们都知道，是个速度飞快的键值存储。但RediSearch呢？它给Redis装上了一个强大的全文搜索引擎，让Redis不仅仅能存东西，还能高效地搜索！想象一下，你有一个庞大的商品数据库，以前搜东西慢得像蜗牛，现在用RediSearch，嗖的一下就出来了，是不是很爽？ 索引：搜索的基石 要让RediSearch搜索得快，首先得建立索引。索引就像书的目录，没它，你只能一页一页地翻，有了它，直接定位到你想看的那页。 1. 创建索引：FT.CREATE 命令 创建索引的核心命令是 FT.CREATE。这个命令有很多参数，我们一点点来看。 FT.CREATE {index_name} [ON {HASH | JSON}] [PREFIX {count} {prefix} …] [FILTER {expression}] SCHEMA {field} [TEXT | NUMER …
Redis `Distributed Queue` 分布式队列：消息可靠性与消费模型
各位朋友，大家好！今天咱们聊聊 Redis 的分布式队列，一个既实用又有点小复杂的家伙。保证消息可靠性，选择合适的消费模型，那可是构建稳定系统的关键。准备好了吗？咱们开始！ 一、Redis 队列：简单却不简单 首先，让我们回顾一下 Redis 队列的基本概念。Redis 提供了 List 数据结构，天然适合作为队列使用。LPUSH 从左边推入元素，RPOP 从右边弹出元素，或者反过来，RPUSH 和 LPOP 也行。 import redis # 连接 Redis (确保 Redis 已经启动) r = redis.Redis(host=’localhost’, port=6379, db=0) # 生产者：往队列里塞消息 r.lpush(‘my_queue’, ‘Task 1’) r.lpush(‘my_queue’, ‘Task 2’) r.lpush(‘my_queue’, ‘Task 3’) # 消费者：从队列里取消息 task = r.rpop(‘my_queue’) print(f”处理任务: {task.decode(‘utf-8’) if task else None} …
Redis `Rate Limiting` 限流器：漏桶与令牌桶算法实现
各位观众老爷，大家好！ 今天咱们来聊聊一个在互联网世界里非常重要的东西——限流。想象一下，你开了一家网红奶茶店，突然有一天，全城的人都跑来排队买你的奶茶，店里瞬间挤爆，服务器直接宕机！这就是没有限流的后果。 限流，简单来说，就是控制住涌入系统的流量，避免系统被瞬间的高流量冲垮。就像给水管装个阀门，控制水流的速度，保证水龙头不会突然爆掉。 在众多限流算法中，漏桶算法和令牌桶算法是两个非常经典且常用的。今天咱们就来深入剖析一下这哥俩，并用Redis来实现它们。 一、漏桶算法：稳如老狗，细水长流 漏桶算法，顾名思义，就像一个漏水的桶。请求就像水，不断地往桶里灌，桶以恒定的速度往外漏水（处理请求）。如果水流速度超过了漏水速度，桶就会溢出（请求被丢弃）。 漏桶算法的特点： 恒定速率流出： 保证了请求以固定的速度被处理，平滑了突发流量。 可能丢弃请求： 当请求速度超过漏水速度，桶会溢出，导致请求被丢弃，也就是限流。 流量整形： 将不稳定的流量整形为稳定的流量。 漏桶算法的应用场景： 消息队列： 保证消息以恒定的速度被消费，避免下游系统被压垮。 API接口限流： 防止恶意攻击或者突发流量导致API接 …
Redis Bloom Filter (布隆过滤器)：海量数据判重的空间优化
好的，没问题。 咳咳，各位观众，各位朋友，大家好！欢迎来到“Redis Bloom Filter：海量数据判重的空间优化”讲座现场。我是今天的讲师，江湖人称“代码段子手”。 今天咱们不聊虚的，就聊聊怎么用Bloom Filter这个小东西，在海量数据里玩转判重，而且还省空间！ 开场白：人生苦短，何必纠结于Set？ 话说在编程界，判重是个老生常谈的问题。想当年，我们还是懵懂少年时，用Set集合就能轻松搞定。比如你想判断一个用户ID是否已经存在，直接往Set里塞，存在就拒绝，不存在就加入。简单粗暴，效果拔群！ 但是，各位有没有想过，当用户数量达到百万、千万，甚至亿级的时候，Set就有点力不从心了。它需要把所有的数据都存储在内存里，这得多大的空间啊！你的老板可能会心疼地说：“少年，你的内存条要涨价了！” 所以，我们需要一种更节省空间，更高效的判重方案。这时候，Bloom Filter就闪亮登场了！ Bloom Filter：概率的艺术 Bloom Filter，中文名“布隆过滤器”，听起来高大上，其实原理非常简单。它是一种概率型数据结构，用于判断一个元素是否存在于集合中。注意，是概率型！也就 …
Redis `Redlock` 分布式锁：实现原理、优缺点与替代方案
各位朋友，大家好！今天咱们来聊聊一个听起来高大上，但其实也挺有趣的玩意儿——Redis Redlock 分布式锁。 想象一下，你是一个指挥交通的交警，面对十字路口四面八方的车辆，你的职责就是确保同一时刻只有一个方向的车能通行，避免发生惨烈的车祸。在分布式系统中，Redlock 就扮演着类似交警的角色，它确保在多个节点同时访问共享资源时，只有一个节点能获得访问权，避免数据混乱或冲突。 Redlock 的实现原理：少数服从多数的“选举” Redlock 的核心思想是“少数服从多数”。 它不依赖于单个 Redis 节点，而是使用多个独立的 Redis 节点（通常是 5 个，官方推荐），通过一种类似“选举”的方式来决定谁获得锁。 具体流程如下： 请求加锁： 客户端向所有 Redis 节点发送加锁请求（SET 命令，带 NX 和 PX 参数）。NX 表示 "Not eXists"，只有当 key 不存在时才设置成功；PX 表示过期时间，防止死锁。 import redis import time import uuid class Redlock: def __init__( …