服务端开发博客 | 后端架构 · 高并发 · 性能优化 · 微服务实战 👋🏼

在高并发场景下，消息发送的性能直接影响系统的整体吞吐量。传统单条消息发送模式存在以下问题： 每次发送都需要网络往返，RT（响应时间）高 broker 压力增大， TPS 上不去 服务器资源利用率低 RocketMQ 的批量发送和异步处理机制可以有效解决这些问题。本文将详细介绍如何在 SpringBoot 中实现 RocketMQ 异步批量发送优化，让生产端吞吐提升 5 倍，RT 降低 80%。 为什么需要批量发送？ 先看一下单条发送和批量发送的对比： 单条发送模式： ┌─────────────────────────────────────────────────────────────┐ │ Msg1 ──→ Broker ──→ ACK │ │ ↓ │ │ Msg2 ──→ Broker ──→ ACK │ │ ↓ │ │ Msg3 ──→ Broker ──→ ACK │ │ │ │ 3次网络往返，3次broker处理，RT = N × RTT │ └─────────────────────────────────────────────────────────────┘....

做过 IM 聊天、在线游戏、实时推送这类应用的都知道，WebSocket 连接稳定性是个大难题： 用户坐地铁过隧道，信号时断时续 App 切到后台，系统会杀掉 WebSocket 连接 公司网络需要认证，一断开就再也连不上 用户 Dormant 模式网络切换，IP 都变了 更头疼的是消息丢失问题： 用户发了一条消息，服务器还没收到就断线了 服务器推送的消息，客户端还没收到就断线了 重连后不知道哪些消息漏收了，只能全部同步 今天我们来聊聊 WebSocket 弱网环境下的保活机制，确保 App 在各种网络环境下都能保持连接，消息不丢失。 为什么 WebSocket 在弱网环境下这么脆弱？ 先来分析一下 WebSocket 连接断线的常见场景： 1. App 切后台 前台运行：WebSocket 保持连接 ←→ 服务器正常通信 ↓ 切到后台：系统可能 kill WebSocket 连接 ↓ 切回前台：需要重新建立连接，但之前的消息已经丢了 2. 网络切换 WiFi 连接：WebSocket 通过 IP1 建立连接 ↓ 切换到 4G：IP 变成 IP2，原有连接直接失效 ↓ 重连成....

在金融交易、支付、证券等场景下，消息顺序至关重要： 用户下单 → 支付 → 发货 → 确认收货，这个顺序绝不能乱 账户余额变更必须按时间顺序处理，否则会出现透支 证券撮合交易对时序要求精确到毫秒 Kafka 虽然通过分区机制保证了分区内的顺序，但在实际生产中，顺序消费往往会遇到各种问题： 多消费者消费同一个分区，消息乱序 扩容缩容时，分区重分配导致消息处理顺序被打乱 消息重试导致的顺序错乱 批量消费时部分失败导致的顺序问题 今天我们来聊一聊如何在 SpringBoot 中实现 Kafka 严格顺序消费，保证金融级交易链路的稳定性。 为什么顺序消费这么难？ 先分析一下 Kafka 顺序消费的难点： 1. 多消费者消费同一个分区 问题： ┌─────────────────────────────────────────────────────────┐ │ Kafka Partition 0 │ │ [Msg1] → [Msg2] → [Msg3] → [Msg4] → [Msg5] → [Msg6] │ └────────────────────────────────────....

做多租户系统的同学肯定都踩过这个坑：某个租户的数据莫名其妙出现在了另一个租户的账号里，或者租户 A 配置的规则被租户 B 给用上了。这些问题听起来像是低级 bug，但背后折射出的是多租户架构中数据隔离和权限控制的复杂性。 特别是在规则引擎场景下，租户会有自己的业务规则，比如优惠券规则、会员等级规则、风控规则等。如果规则引擎没有做好租户隔离，后果可能是： 租户 A 领到了租户 B 的优惠券，造成营销损失 租户 A 的风控规则被租户 B 绕过，导致业务风险 财务规则串号，造成账务错误 今天我们就来聊聊多租户规则沙箱隔离的架构设计，彻底杜绝数据串号和规则越权问题。 为什么多租户隔离这么难？ 先来分析一下多租户隔离的难点在哪里。很多团队会说："我们用了数据库租户字段，做了 WHERE tenant_id = xxx 的查询啊，怎么还会串号？" 实际情况远比这复杂： 1. 规则引擎的上下文污染 规则引擎通常会缓存已加载的规则，如果缓存 key 设计不当，可能会出现： 规则 key 只用了 ruleId，没有包含 tenantId 规则执行时的上下文（Context）被多个租户共享 规则变量....