2. 首页 > Redis教程 > 正文

Redis教程FG044-Redis消息推送系统实战

教程整理：风哥教程  |  更新时间：2026-01-01  |  教程分类：Redis教程  |  文档学习：19

本教程主要介绍Redis在消息推送系统中的应用，包括消息推送的核心功能、Redis的实现方案以及生产环境的最佳实践。风哥教程参考Redis官方文档的Stream数据类型相关内容，结合实际业务场景，提供完整的消息推送系统解决方案。

Part01-基础概念与理论知识

1.1 消息推送系统概念

消息推送系统是一种实时信息传递机制，用于将消息从服务器发送到客户端。常见的应用场景包括：

  • 即时通讯：聊天消息、通知
  • 系统通知：业务提醒、告警信息
  • 内容推送：新闻、活动、广告
  • 实时数据：监控数据、实时更新

消息推送系统的核心需求：

  • 实时性：消息能够及时送达
  • 可靠性：消息不丢失
  • 可扩展性：支持大规模消息推送
  • 灵活性：支持多种推送方式

1.2 Redis Stream数据类型

Redis的Stream是一种用于处理消息流的数据类型，它具有以下特点：

  • 持久化：消息会被持久化到磁盘
  • 有序性：消息按照时间顺序存储
  • 可消费：支持多个消费者组
  • 可回溯：支持从指定位置开始消费
  • 可靠性：支持消息确认机制

1.3 消息推送架构设计

消息推送系统的典型架构设计：

  • 消息生产：业务系统产生消息
  • 消息存储：Redis Stream存储消息
  • 消息消费：消费者处理消息
  • 消息推送：推送服务将消息发送给客户端
  • 监控告警：监控系统运行状态

更多视频教程www.fgedu.net.cn

Part02-生产环境规划与建议

2.1 硬件资源规划

针对消息推送系统的硬件资源规划建议：

  • CPU：4核以上，满足并发需求
  • 内存：16GB以上，根据消息量调整
  • 网络：千兆网卡，保证网络带宽
  • 存储：SSD硬盘，提高持久化性能
  • 服务器：多台服务器集群部署，避免单点故障

2.2 Redis集群配置

Redis集群配置建议：

  • 集群模式：使用Redis Cluster，3主3从配置
  • 内存配置：根据消息量设置合理的maxmemory
  • 持久化：开启RDB和AOF，保证数据安全
  • 连接数：调整maxclients，支持高并发连接
  • 超时设置：合理设置timeout，避免连接占用

2.3 网络与安全配置

网络与安全配置建议：

  • 网络隔离：Redis集群部署在专用网络
  • 防火墙：设置合理的防火墙规则
  • 认证：开启Redis密码认证
  • SSL：使用SSL加密传输
  • 监控：部署监控系统，实时监控集群状态

学习交流加群风哥QQ113257174

Part03-生产环境项目实施方案

3.1 消息推送核心实现

消息推送的核心实现步骤：

3.1.1 创建消息流

# 添加消息到Stream

$ /redis/app/bin/redis-cli -h 192.168.1.100 -p 6379 -a fgedu@2026 xadd stream:fgedu:notification * user_id “1001” type “system” content “系统升级通知” timestamp “2024-01-01 10:00:00”

1704067200000-0

3.1.2 创建消费者组

# 创建消费者组

$ /redis/app/bin/redis-cli -h 192.168.1.100 -p 6379 -a fgedu@2026 xgroup create stream:fgedu:notification consumer_group_1 0

OK

3.1.3 消费消息

# 消费消息

$ /redis/app/bin/redis-cli -h 192.168.1.100 -p 6379 -a fgedu@2026 xreadgroup group consumer_group_1 consumer_1 streams stream:fgedu:notification >


1) “stream:fgedu:notification”
2) 1) 1) “1704067200000-0”
2) 1) “user_id”
2) “1001”
3) “type”
4) “system”
5) “content”
6) “系统升级通知”
7) “timestamp”
8) “2024-01-01 10:00:00”

3.1.4 确认消息

# 确认消息

$ /redis/app/bin/redis-cli -h 192.168.1.100 -p 6379 -a fgedu@2026 xack stream:fgedu:notification consumer_group_1 1704067200000-0

1

3.2 消息管理方案

消息管理的最佳实践：

3.2.1 消息过期策略

# 设置Stream最大长度

$ /redis/app/bin/redis-cli -h 192.168.1.100 -p 6379 -a fgedu@2026 xadd stream:fgedu:notification MAXLEN 1000 * user_id “1002” type “system” content “系统维护通知” timestamp “2024-01-01 10:05:00”

1704067500000-0

3.2.2 消息监控

# 查看Stream信息

$ /redis/app/bin/redis-cli -h 192.168.1.100 -p 6379 -a fgedu@2026 xinfo stream stream:fgedu:notification


1) “length”
2) (integer) 2
3) “radix-tree-keys”
4) (integer) 1
5) “radix-tree-nodes”
6) (integer) 2
7) “last-generated-id”
8) “1704067500000-0”
9) “groups”
10) (integer) 1
11) “first-entry”
12) 1) “1704067200000-0”
2) 1) “user_id”
2) “1001”
3) “type”
4) “system”
5) “content”
6) “系统升级通知”
7) “timestamp”
8) “2024-01-01 10:00:00”
13) “last-entry”
14) 1) “1704067500000-0”
2) 1) “user_id”
2) “1002”
3) “type”
4) “system”
5) “content”
6) “系统维护通知”
7) “timestamp”
8) “2024-01-01 10:05:00”

3.3 消息推送性能优化

消息推送性能优化的建议：

  • 使用Redis Pipeline批量操作
  • 合理设置Stream最大长度
  • 使用消费者组提高并发消费能力
  • 实现消息分片减少单Stream压力
  • 使用Lua脚本减少网络往返

风哥提示：Redis接口限流是保护系统的重要机制，合理的限流策略可以防止系统过载，确保系统的稳定性和可用性。在实际应用中，需要根据具体业务场景和数据特点，选择合适的限流算法和策略。

Part04-生产案例与实战讲解

4.1 消息推送实战案例

以下是一个完整的消息推送实战案例：

4.1.1 系统架构

  • 前端：WebSocket客户端
  • 后端：Spring Boot + Redis + WebSocket
  • 缓存：Redis Cluster 3主3从
  • 消息队列：Redis Stream
  • 负载均衡：Nginx

4.1.2 核心代码实现

# 消息推送核心代码

@Service
public class NotificationService {

@Autowired
private RedisTemplate redisTemplate;

public String sendNotification(String userId, String type, String content) {
Map message = new HashMap<>();
message.put(“user_id”, userId);
message.put(“type”, type);
message.put(“content”, content);
message.put(“timestamp”, LocalDateTime.now().format(DateTimeFormatter.ofPattern(“yyyy-MM-dd HH:mm:ss”)));

String streamKey = “stream:fgedu:notification”;
return redisTemplate.opsForStream().add(streamKey, message);
}

public void consumeNotifications() {
String streamKey = “stream:fgedu:notification”;
String groupName = “consumer_group_1”;
String consumerName = “consumer_1”;

// 检查并创建消费者组
try {
redisTemplate.opsForStream().createGroup(streamKey, groupName, ReadOffset.from(“0”));
} catch (Exception e) {
// 消费者组已存在，忽略异常
}

// 消费消息
while (true) {
List> records = redisTemplate.opsForStream()
.read(Consumer.from(groupName, consumerName),
StreamReadOptions.empty().count(10).block(Duration.ofSeconds(5)),
StreamOffset.create(streamKey, ReadOffset.lastConsumed()));

if (records != null && !records.isEmpty()) {
for (MapRecord record : records) {
// 处理消息
processNotification(record);
// 确认消息
redisTemplate.opsForStream().acknowledge(streamKey, groupName, record.getId());
}
}
}
}

private void processNotification(MapRecord record) {
// 处理消息逻辑，如推送WebSocket消息
String userId = (String) record.getValue().get(“user_id”);
String content = (String) record.getValue().get(“content”);
// 推送消息到客户端
}
}

4.2 性能测试与优化

性能测试与优化建议：

4.2.1 压力测试

# 使用ab进行压力测试

$ ab -n 10000 -c 1000 http://localhost:8080/api/notification/send?userId=1001&type=system&content=test


This is ApacheBench, Version 2.3 <$Revision: 1879490 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking localhost (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Completed 10000 requests
Finished 10000 requests

Server Software: Apache-Coyote/1.1
Server Hostname: localhost
Server Port: 8080

Document Path: /api/notification/send?userId=1001&type=system&content=test
Document Length: 50 bytes

Concurrency Level: 1000
Time taken for tests: 1.892 seconds
Complete requests: 10000
Failed requests: 0
Total transferred: 2450000 bytes
HTML transferred: 500000 bytes
Requests per second: 5285.45 [#/sec] (mean)
Time per request: 189.200 [ms] (mean)
Time per request: 0.189 [ms] (mean, across all concurrent requests)
Transfer rate: 1262.50 [Kbytes/sec] received

Connection Times (ms):
min mean[+/-sd] median max
Connect: 0 1 0.3 1 3
Processing: 1 188 42.5 178 280
Waiting: 1 187 42.4 177 279
Total: 1 189 42.5 179 283

Percentage of the requests served within a certain time (ms):
50% 179
66% 195
75% 205
80% 212
90% 230
95% 245
98% 260
99% 270
100% 283 (longest request)

4.2.2 优化措施

  • 使用Redis Pipeline批量操作
  • 优化Lua脚本减少网络往返
  • 使用本地缓存减少Redis访问
  • 合理设置Stream最大长度
  • 使用消费者组提高并发消费能力

4.3 故障处理与应急预案

故障处理与应急预案：

4.3.1 常见故障

  • Redis集群故障：主节点宕机
  • 网络故障：网络延迟或中断
  • 系统过载：消息量超过系统处理能力
  • 消息丢失：消费者处理失败

4.3.2 应急预案

  • Redis集群故障：自动故障转移，确保高可用
  • 网络故障：使用多可用区部署，避免单点故障
  • 系统过载：启动限流机制，保护核心服务
  • 消息丢失：实现消息重试机制，确保消息送达

更多学习教程公众号风哥教程itpux_com

Part05-风哥经验总结与分享

5.1 消息推送最佳实践

消息推送的最佳实践：

  • 合理设计消息结构
  • 使用Redis Stream存储消息
  • 设置合理的Stream最大长度
  • 使用消费者组提高并发消费能力
  • 实现消息重试机制

5.2 常见问题与解决方案

常见问题与解决方案：

5.2.1 消息堆积

解决方案：增加消费者数量，提高消费能力，设置合理的Stream最大长度。

5.2.2 消息丢失

解决方案：实现消息确认机制，使用消费者组，定期检查未确认的消息。

5.2.3 性能瓶颈

解决方案：使用Pipeline批量操作，优化Lua脚本，实现消息分片。

5.3 性能优化建议

性能优化建议：

  • Redis优化：合理配置内存、使用Pipeline、优化数据结构
  • 网络优化：使用连接池、减少网络往返、优化网络拓扑
  • 应用优化：代码优化、减少GC、使用异步处理
  • 架构优化：服务拆分、读写分离、缓存分层
  • 运维优化：监控告警、自动扩缩容、故障自动恢复

from Redis视频:www.itpux.com

本文由风哥教程整理发布,仅用于学习测试使用,转载注明出处:http://www.fgedu.net.cn/10327.html

相关推荐

联系我们

在线咨询：点击这里给我发消息

微信号：itpux-com

工作日：9:30-18:30，节假日休息