1、git删除分支实现步骤【转载】cid:link_62、git branch如何delete方式【转载】cid:link_73、 input的accept属性让文件上传安全高效【转载】cid:link_04、HTML5的<input>标签的`type`属性值详解和代码示例【转载】cid:link_15、 python爬虫脚本HTTP 403 Forbidden错误怎么办？【转载】cid:link_26、Python实现将.py代码转换为带语法高亮的Word和PDF【转载】cid:link_87、Python多进程中避免死锁问题的六种策略【转载】cid:link_98、 Python实现将PDF转DOCX的超简单教程(附源码)【转载】cid:link_39、Python基于OpenPyxl实现Excel转PDF并精准控制分页【转载】cid:link_1010、Python获取Docker容器实时资源占用(CPU、内存、IO等)5种实现方式【转载】cid:link_1111、 Python flash URL访问参数配置【转载】cid:link_1212、 Python利用PyMobileDevice3控制iOS设备的完整教程【转载】cid:link_413、 Python基本语法总结大全(含java、js对比)【转载】cid:link_514、 Python自动化提取多个Word文档的文本【转载】cid:link_1315、mybatis-plus分表实现案例(附示例代码)【转载】https://bbs.huaweicloud.com/forum/thread-02126200655519113076-1-1.html

在现代分布式系统中，消息通信是实现服务解耦、异步处理和事件驱动架构的核心。Redis 不仅是一个高性能的键值存储系统，还内置了轻量级的发布/订阅（Publish/Subscribe） 模型，为开发者提供了一种简单高效的消息传递机制。一、什么是发布/订阅模式？发布/订阅（Pub/Sub）是一种消息通信模式，其核心思想是：发布者（Publisher）：不直接将消息发送给特定的接收者，而是将消息“发布”到一个“频道”。订阅者（Subscriber）：事先“订阅”感兴趣的频道，一旦有消息发布到该频道，就会收到通知。解耦：发布者和订阅者之间无需知道对方的存在，实现松耦合。这种模式非常适合用于广播通知、事件监听、日志处理等场景。二、Redis 发布/订阅的基本概念Redis 的 Pub/Sub 模型包含以下核心元素：频道（Channel）：消息的逻辑通道，订阅者通过频道接收消息。模式（Pattern）：支持通配符订阅多个频道，如 news.*。消息（Message）：发布者发送的数据内容，通常为字符串。三、核心命令与使用示例1. 订阅频道：SUBSCRIBE订阅一个或多个频道。# 订阅名为 "news.sports" 的频道SUBSCRIBE news.sports执行后，客户端进入“订阅状态”，只能接收消息或执行少数管理命令（如 UNSUBSCRIBE）。返回示例：Reading messages... (press Ctrl-C to quit)1) "subscribe"2) "news.sports"3) (integer) 1表示已成功订阅第1个频道。2. 发布消息：PUBLISH向指定频道发布消息。# 向 "news.sports" 频道发布一条消息PUBLISH news.sports "C罗再进一球！"返回值： 接收到该消息的订阅者数量。3. 模式订阅：PSUBSCRIBE使用通配符订阅多个频道。# 订阅所有以 "news." 开头的频道PSUBSCRIBE news.*支持的通配符：*：匹配任意数量的字符（除.外）。?：匹配单个字符。4. 取消订阅：UNSUBSCRIBE 和 PUNSUBSCRIBE# 取消所有或指定频道的订阅UNSUBSCRIBE news.sports# 取消模式订阅PUNSUBSCRIBE news.*5. 查看订阅状态：PUBSUB用于查询当前的订阅情况。# 查看活跃频道PUBSUB CHANNELS# 查看订阅了某个模式的客户端数量PUBSUB NUMSUB news.sports# 查看模式订阅数量PUBSUB NUMPAT四、工作流程示例假设我们构建一个简单的新闻推送系统：步骤1：启动两个订阅者终端1（订阅体育新闻）：redis-cliSUBSCRIBE news.sports终端2（订阅财经新闻）：redis-cliSUBSCRIBE news.finance步骤2：发布消息终端3（发布者）：redis-cliPUBLISH news.sports "湖人队夺得总冠军！"PUBLISH news.finance "美股三大指数集体上涨"结果：终端1 收到："湖人队夺得总冠军！"终端2 收到："美股三大指数集体上涨"五、使用模式订阅实现广播使用 PSUBSCRIBE 可以让一个订阅者接收多个频道的消息。# 订阅所有新闻类频道PSUBSCRIBE news.*# 发布消息PUBLISH news.tech "AI技术取得新突破"# 订阅者将收到：1) "pmessage"2) "news.*" # 匹配的模式3) "news.tech" # 实际频道4) "AI技术取得新突破" # 消息内容六、应用场景1. 实时通知系统用户登录提醒系统告警通知订单状态变更推送2. 日志聚合与监控多个服务将日志发布到特定频道，由统一的监控服务订阅处理。3. 聊天室/即时通讯每个聊天室对应一个频道，用户加入即订阅，发言即发布。4. 事件驱动架构服务A完成任务后发布“任务完成”事件，服务B订阅并触发后续处理。5. 配置热更新配置中心修改配置后，通过频道通知所有相关服务重新加载。七、优缺点分析 优点简单易用：无需额外消息中间件（如Kafka、RabbitMQ）。低延迟：基于内存，消息传递极快。解耦：发布者与订阅者完全独立。支持模式匹配：灵活的订阅机制。缺点无持久化：如果订阅者离线，会丢失消息（Redis 不保存历史消息）。无确认机制：无法保证消息被成功处理。不支持消息回溯：只能接收订阅之后的消息。不适合高吞吐场景：相比专业消息队列，功能较为基础。⚠️ 注意：如果需要消息持久化、ACK确认、重试机制等高级功能，建议使用 Redis Streams（Redis 5.0+）或专业消息队列。八、编程语言示例（Python）使用 redis-py 库实现发布订阅：import redisimport threading# 连接Redisr = redis.Redis(host='localhost', port=6379, db=0)# 订阅者线程def subscriber(): pubsub = r.pubsub() pubsub.subscribe('news.sports') print("等待消息...") for message in pubsub.listen(): if message['type'] == 'message': print(f"收到消息: {message['data'].decode('utf-8')}")# 启动订阅者thread = threading.Thread(target=subscriber)thread.start()# 发布消息r.publish('news.sports', '勇士队逆转取胜！')thread.join()现在就动手尝试一个简单的发布订阅示例，体验 Redis 的实时通信魅力吧！

Redis（Remote Dictionary Server）是一个开源的、基于内存的键值对存储数据库，以其高性能、丰富的数据结构和灵活的应用场景而广受欢迎。它不仅可以用作缓存系统，还能作为数据库、消息队列等多种用途。本文将带你快速入门Redis的基础使用。一、Redis简介Redis由Salvatore Sanfilippo开发，采用ANSI C语言编写，支持多种操作系统（如Linux、macOS、Windows等）。其核心特点包括：基于内存存储：读写速度极快，适合高并发场景。持久化支持：支持RDB（快照）和AOF（日志）两种持久化机制，确保数据安全。丰富的数据类型：支持字符串（String）、哈希（Hash）、列表（List）、集合（Set）、有序集合（Sorted Set）等。原子性操作：所有操作都是原子的，保证线程安全。主从复制与高可用：支持主从架构、哨兵模式和集群部署。二、安装与启动1. 安装Redis（以Linux为例）# Ubuntu/Debiansudo apt updatesudo apt install redis-server# CentOS/RHELsudo yum install epel-releasesudo yum install redis2. 启动Redis服务# 启动服务sudo systemctl start redis-server# 设置开机自启sudo systemctl enable redis-server# 检查状态sudo systemctl status redis-server3. 连接Redis# 使用Redis自带的命令行客户端redis-cli连接成功后，可输入 ping 测试：127.0.0.1:6379> pingPONG三、基本数据类型与操作1. 字符串（String）最简单的键值对，值可以是字符串或数字。# 设置键值SET name "Alice"# 获取值GET name# 输出: "Alice"# 自增INCR counter # 若counter不存在，则设为0再+1INCRBY counter 5# 设置过期时间（秒）EXPIRE name 602. 哈希（Hash）适合存储对象，如用户信息。# 设置哈希字段HSET user:1001 name "Bob" age 25 email "bob@example.com"# 获取单个字段HGET user:1001 name# 输出: "Bob"# 获取所有字段HGETALL user:10013. 列表（List）有序的字符串列表，支持在头部或尾部插入。# 向列表左侧插入LPUSH tasks "task1" "task2"# 向右侧插入RPUSH tasks "task3"# 查看列表内容LRANGE tasks 0 -1# 输出: ["task2", "task1", "task3"]# 弹出左侧元素LPOP tasks4. 集合（Set）无序且唯一的字符串集合。# 添加元素SADD tags "redis" "database" "cache"# 查看所有元素SMEMBERS tags# 判断是否包含SISMEMBER tags "redis"# 输出: 1（存在）5. 有序集合（Sorted Set）带权重的集合，按分数排序。# 添加成员（分数在前）ZADD leaderboard 100 "Alice" 90 "Bob" 85 "Charlie"# 获取排名（从高到低）ZREVRANGE leaderboard 0 -1 WITHSCORES# 输出: Alice, 100, Bob, 90, Charlie, 85

核心结论：Redis Cluster 的 CAP 权衡Redis Cluster 优先保障 CP，即在网络分区（Partition）发生时，它会优先保障一致性（C） 和分区容错性（P），而牺牲可用性（A）。这意味着，当发生脑裂（网络分区）时，Redis Cluster 会确保在多数派（Master）主节点所在的分区继续提供服务，而少数派分区中的节点会拒绝写入（甚至部分读取），从而避免数据不一致。这期间，连接到少数派分区的客户端可能会收到错误，从而体验到服务不可用。1. 数据分片机制与 CAP 保障Redis Cluster 采用分片（Sharding） 的方式来管理数据，具体是通过哈希槽（Hash Slot）实现的。机制：整个集群有 16384 个哈希槽。每个键通过 CRC16 校验后，对 16384 取模，被分配到一个唯一的槽中。集群将这些槽分配给各个主节点（Master）。每个主节点负责一部分槽位。客户端可以请求任意节点，如果该键不在当前节点，节点会返回 MOVED 错误并告知正确节点，由客户端进行重定向。体现的 CAP 特性：一致性 (C)：数据分片机制是保障强一致性的基础。它通过将数据分散，使得每个主节点只需要维护自己负责的那部分数据的一致性。在数据读写时，操作被限定在特定的主节点及其副本上，这为实现强一致性协议（如 Redis Cluster 的异步复制）创造了条件。分区容错性 (P)：分片本身就是分区容错性的体现。数据被分布到多个节点上，单个节点或部分节点的故障不会导致整个集群数据的完全丢失。系统被设计为即使在部分节点不可用时，其他节点仍然可以继续服务。可用性 (A)：分片本身提升了整体的可用性，因为一个分片的故障不影响其他分片。但是，在 CAP 的语境下，当发生网络分区时，分片机制会与故障转移机制协同工作，最终做出牺牲部分分片可用性以保障一致性的选择。小结：数据分片机制主要服务于 P（将数据分散以容忍部分故障）和 C（为局部一致性管理打下基础）。2. 故障转移机制与 CAP 保障故障转移是 Redis Cluster 在面临节点故障或网络分区时，维持 CP 特性的核心。机制：心跳与故障探测：所有节点通过 Gossip 协议互相通信。每个主节点会定期向其他主节点发送 PING 消息。如果一个主节点在超过 cluster-node-timeout 时间内未收到另一个主节点的 PONG 回复，它会将其标记为“疑似下线”（PFAIL）。如果集群中大多数主节点都认为某个主节点下线，则将其标记为“已下线”（FAIL），并广播这一消息。从节点晋升：当一个主节点被确认为 FAIL 状态后，其下的一个从节点会发起竞选。这个从节点必须能够连接到集群中的大多数主节点，才能获得投票并晋升为新的主节点。配置纪元（Configuration Epoch）：这是一个单调递增的版本号，用于在出现多个冲突的决策（比如脑裂后恢复时出现两个主节点）时，判定哪个决策是最新的，从而解决冲突，保证集群最终只有一个配置胜出。体现的 CAP 特性：一致性 (C)：这是最关键的部分。故障转移机制通过 “大多数（Majority）”原则 来保障一致性。一个从节点必须得到大多数主节点的同意才能成为新的主节点。这意味着，在网络分区中，只有拥有大多数主节点的那个分区（多数派分区）才能成功完成故障转移。少数派分区中的节点，因为无法连接到大多数主节点，其从节点无法成功晋升。因此，少数派分区中的原主节点（即使它还在运行）会被集群其他部分视为已下线，它自己也会因为无法完成写入确认而进入错误状态。这就防止了在少数派分区中出现“脏写”，从而避免了脑裂导致的数据不一致。分区容错性 (P)：整个故障转移流程就是为了应对节点故障（这是分区的一种极端形式）而设计的。它允许集群在失去部分节点后，通过副本晋升来恢复完整的服务能力，体现了对分区情况的容错。可用性 (A)：在这里，可用性被明确地牺牲了。在故障转移期间，原主节点和其从节点负责的哈希槽会有一小段时间不可用（从节点竞选和晋升的时间）。更重要的是，在网络分区发生时，少数派分区中的所有主节点都会变得不可用。因为它们无法与大多数节点取得联系，为了保证不产生不一致的数据，它们会拒绝所有的写操作和（可能配置为强一致性的）读操作。对于连接到这些节点的客户端来说，服务就是“不可用”的。小结：故障转移机制是 Redis Cluster 选择 CP 的集中体现。它通过依赖“大多数”原则，在发生分区时，宁可让少数派分区的服务停止，也绝不冒险接受可能导致数据不一致的写入。总结与对比  特性/机制数据分片 (Sharding)故障转移 (Failover)综合 CAP 权衡一致性 (C)为局部一致性管理打下基础优先保障：通过“大多数”原则防止脑裂和不一致优先保障 (CP)可用性 (A)提升整体可用性（故障隔离）主动牺牲：故障转移期间及少数派分区服务不可用在网络分区时被牺牲分区容错性 (P)核心设计目标：数据分布以容忍部分故障核心设计目标：在节点故障/分区后自动恢复必须保障 (CP)与 AP 系统（如 Cassandra）的对比：Redis Cluster (CP)： 当网络断开，导致主节点和它的从节点被隔离在少数派分区时，这个主节点会停止服务。你的应用会收到错误。数据是安全的，不会出现冲突。Cassandra (AP)： 在同样的情况下，被隔离的节点仍然会接受写入。当网络恢复时，Cassandra 会使用诸如“最后写入获胜”等机制来解决冲突，但这可能导致数据丢失。它优先保证服务始终可用，但可能牺牲强一致性。因此，在选择 Redis Cluster 时，你需要明确你的业务场景：是否能接受在网络抖动或节点故障时，部分数据的短暂不可用，以换取数据的强一致性？ 如果能，那么 Redis Cluster 的 CP 模型是合适的。如果不能，需要追求高可用，并且可以接受最终一致性，那么可能需要考虑其他方案。

Redisson里面的锁是怎么来防止误删的？

Redis中的hash和Java中的HashMap有啥区别

Redis的ZipList、SkipList和ListPack之间有什么区别？

Redis中的ListPack是如何解决级联更新问题的？

ZSet为什么在数据量少的时候用ZipList，而在数据量大的时候转成SkipList？

Redis中的setnx和setex有啥区别？

Redis8.0的新特性有哪些？

Redis中hash结构比string的好处有哪些？

Redis事务和MySQL事务有什么区别？

Redis能完全保证数据不丢失吗？

RDB和AOF的写回策略分别是什么？