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

引言 上个月联调一个新模块，团队里发生了经典的一幕：后端小哥在终端里敲 grpcurl 敲得飞起，测试同学凑过来问"Postman 里怎么没有这个接口？"——一句话暴露了两个事实：一是我们的接口早就不是"清一色 REST"了（gRPC 做内部服务、WebSocket 做实时推送、MQTT 做设备接入、Kafka 做事件总线），二是调试工具的口味还停留在 HTTP 时代。 拿 Postman 硬调这些协议，结果都是"能用但别扭"：gRPC 要手写一坨 proto 导入流程；WebSocket 能连但历史消息和定时发送都缺；MQTT 和 Kafka 更是基本无能为力。这五个协议各自有专门的调试工具，用对了效率翻倍： 工具协议形态一句话定位 grpcurlgRPC命令行gRPC 界的 curl，CI 脚本和快速验证都靠它 BloomRPCgRPCGUI像 Postman 一样点点点调 gRPC WebSocket KingWebSocket浏览器插件浏览器里直接连 WS 收发消息 MQTT ExplorerMQTT桌面客户端主题树可视化，一眼看清设备上报了什么 Kafka UIKaf....

我们做一个实时行情推送系统，WebSocket 长连接撑到 65535 条的时候突然全断。新连接报 Too many open files，老连接陆续被操作系统干掉，连 SSH 都登不上去了。 运维以为是 DDoS，查了半天发现攻击源是自己的业务流量——推送服务每一条 WebSocket 连接占用一个文件描述符（fd），65535 条连接刚好打满一台机器默认的 fd 上限。 Linux 里一切皆文件——Socket 是文件，管道是文件，连 tail -f 也要一个 fd。WebSocket 每维持一条连接就吃掉一个 fd。 单机理论上限 65535，但系统进程还要用（SSH、日志、数据库连接），实际留给业务的大概 60000 个连接就到头了。 这意味着什么？单机 WebSocket 能承载的用户数，被文件描述符硬编码了。 不调系统参数，加到 60000 个连接就等着挂。 一、先调系统级：把 fd 上限打开 # 系统级硬上限 echo "fs.file-max = 2000000" >> /etc/sysctl.conf sysctl -p # 进程级软硬限制 echo "....

公司的在线客服系统用的是 WebSocket。每次发版滚动更新，旧 Pod 一停，挂在上面的几千个 WebSocket 连接全断。前端虽然做了自动重连，但重连期间用户发了一条消息，没收到回复，以为客服不理他，直接给了差评。更糟糕的是，客服正在输入的内容也丢了——WebSocket 断了，会话状态没了。 WebSocket 跟 HTTP 不一样。HTTP 是无状态的，请求断了重试一次就好。WebSocket 是长连接，一旦断了，连接上的状态全丢。发版又是必然事件——你不能为了 WebSocket 永远不发版。 今天聊聊怎么让 WebSocket 在服务发版时平滑过渡，不让用户感知到断线。 WebSocket 发版的三个痛点 滚动更新时，K8s 或者运维平台会给旧 Pod 发 SIGTERM 信号，然后等一段时间（默认 30 秒）后 SIGKILL。WebSocket 没有 HTTP 那样的负载均衡重试机制，Pod 一死连接直接断。 三个痛点： 连接断开——旧 Pod 停了，上面的 WebSocket 连接瞬间全断。用户端要么看到连接断开提示，要么消息发不出去。 状态丢失——客服正在输入....

做过实时消息推送的同学肯定都遇到过这个问题：当有大量用户在线时，频繁的小消息广播会导致带宽急剧上升，甚至引发广播风暴。特别是在直播弹幕、实时通知、多人协作等场景，这个问题尤为突出。 我之前就遇到过这样一个案例：一个直播平台在搞活动时，同时在线人数突破了 10 万。运营人员发了一条弹幕抽奖消息，结果瞬间产生了 10 万条 WebSocket 消息推送，导致服务器带宽直接跑满，部分用户出现消息延迟甚至断线重连。 今天我们就来聊聊 WebSocket 广播风暴的抑制方案，让您的系统轻松应对万人在线的消息推送场景。 广播风暴的根本原因 1. 小消息频繁发送 这是最常见的情况： 场景：10 万在线用户 + 每秒 10 条小消息 每条消息大小：100 bytes 每秒发送量：10 万 × 10 = 100 万条 每秒带宽消耗：100 万 × 100 bytes = 100MB/s ≈ 800Mbps 如果每条消息有 50 字节的协议开销： 实际带宽消耗：100 万 × 150 bytes = 150MB/s ≈ 1.2Gbps 2. TCP 小包问题 TCP 小包的问题： ┌──────────....

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

相信很多做过实时通信应用的小伙伴都遇到过这样的问题：用户在使用 App 时，切到后台再切回来，WebSocket 连接就断了；或者在地铁、电梯等弱网环境下，连接经常断开，导致消息丢失。这些问题严重影响了用户体验，特别是在需要实时通信的场景下。 在即时通讯、在线游戏、金融交易等场景中，WebSocket 连接的稳定性至关重要。一旦连接断开，不仅会导致消息丢失，还可能影响业务逻辑的正确性。那么，如何在弱网环境下保持 WebSocket 连接的稳定性，实现断线重连和消息补发呢？今天我就跟大家分享一套基于 SpringBoot 的 WebSocket 弱网保活方案。 为什么需要 WebSocket 弱网保活机制？ 先来说说我们面临的挑战。在移动应用中，WebSocket 连接经常会遇到以下问题： App 切后台：App 进入后台后，系统会限制网络连接，导致 WebSocket 连接断开 弱网环境：在地铁、电梯、地下室等信号不好的地方，网络不稳定，连接容易断开 网络切换：用户从 Wi-Fi 切换到 4G/5G，或者从 4G 切换到 5G，可能导致连接断开 心跳超时：网络延迟导致心跳包超时，服务....

引言 在现代Web应用中，WebSocket作为一种全双工通信协议，被广泛应用于实时消息推送、在线协作、即时通讯等场景。然而，在生产环境中，WebSocket连接管理往往面临着严峻的挑战：用户直接关闭浏览器标签页而非点击退出按钮、 网络不稳定导致的连接中断、用户长时间不操作但连接依然保持……这些情况都会导致"僵尸连接"的产生，即服务器认为连接仍然存活，但实际上客户端已经不再使用。 本文将深入探讨WebSocket连接泄漏的问题，分析其成因，并详细介绍如何在Spring Boot应用中实现连接泄漏的监控和僵尸连接的自动清理机制，确保WebSocket服务的高可用性。 问题背景 什么是WebSocket连接泄漏 WebSocket连接泄漏是指WebSocket连接在客户端已经不再使用的情况下，服务器端依然保持该连接，导致以下问题： 连接资源浪费：每个WebSocket连接都会占用服务器的文件描述符和内存资源 服务器负载增加：大量僵尸连接会消耗服务器资源，影响正常用户的使用 Session信息泄漏：如果使用Session存储用户信息，僵尸连接会导致Session无法及时释放 消息推送无效：....

前言 在现代 Web 应用中，WebSocket 已成为实现实时通信的重要技术。它允许服务器主动向客户端推送数据，实现了真正的双向通信。然而，随着用户量的增长，WebSocket 连接的管理变得越来越重要。如果不进行有效的连接数限制，可能会导致服务器资源耗尽，影响服务的稳定性。 想象一下这样的场景：你的应用支持实时聊天功能，每个用户可以建立多个 WebSocket 连接。如果某个用户恶意或误操作建立了大量连接，可能会占用服务器的大量资源，影响其他用户的正常使用。更严重的是，如果多个用户都这样做，服务器可能会因为资源耗尽而崩溃。 WebSocket 连接数限流和防资源耗尽是解决这个问题的有效方案。通过限制单个用户的最大连接数，以及采取其他防资源耗尽的措施，可以保障服务的稳定性。本文将详细介绍如何在 SpringBoot 项目中实现 WebSocket 连接数限流和防资源耗尽功能。 一、WebSocket 连接数限流的核心概念 1.1 什么是 WebSocket 连接数限流 WebSocket 连接数限流是指限制单个用户或单个 IP 地址可以建立的 WebSocket 连接数量，以防止资源....

引言：消息丢失的噩梦 公司的订单系统因为网络抖动导致大量关键通知丢失。用户下单后没有收到支付提醒，商家也没有收到新订单通知，最终导致订单超时取消，用户投诉，GMV 损失惨重。 实时消息推送是现代 Web 应用的核心功能，但面临着诸多挑战： 网络不稳定：用户网络波动导致连接断开 客户端离线：用户关闭浏览器或 APP 离线 消息堆积：高峰期消息量过大导致推送延迟 消息丢失：关键通知丢失导致业务异常 QoS（Quality of Service，服务质量） 是解决这些问题的关键。本文将带你深入理解 WebSocket 消息 QoS 机制，并使用 Spring Boot 实现一套完整的消息推送方案。 一、WebSocket 消息 QoS：概念与重要性 1.1 什么是消息 QoS？ QoS（Quality of Service） 是指消息传输的服务质量等级，用于保证消息的可靠传输。 类比生活中的例子： QoS 0（最多一次）：普通信件，可能丢失 QoS 1（至少一次）：挂号信，保证送达但可能重复 QoS 2（恰好一次）：快递签收，保证送达且不重复 1.2 MQTT 协议中的 QoS 等....

前言 公司系统有一个数据导出功能，用户导出大数据量时需要等待10多分钟。当时我们采用轮询方式让用户检查任务状态，用户体验极差，用户经常重复点击导致系统压力增大。 我们花了几天时间，基于SpringBoot开发了一套异步任务结果回调和WebSocket通知系统，实现了长时间任务完成实时告知用户。现在用户提交任务后可以做其他事情，任务完成时会实时收到通知，大大提升了用户体验。 今天就把这套方案分享给大家。 问题背景 在业务系统中，经常需要处理一些耗时较长的任务，比如： 报表生成：生成包含大量数据的报表 数据导出：导出百万级数据到Excel 数据分析：复杂的计算和分析任务 文件处理：大文件的上传、转换、压缩 批量操作：批量数据处理和更新 这些任务如果采用同步方式处理，会导致： 用户等待时间过长 浏览器连接超时 服务器资源占用高 用户体验极差 系统吞吐量下降 传统的解决方案是轮询检查任务状态，但这种方式存在： 频繁请求增加服务器压力 实时性差，用户感知延迟 资源浪费，空轮询多 用户体验不佳 传统方案 vs 优化方案 传统方案：轮询检查 // 传统轮询方案 public class ....

前言 最近在做一个即时通讯项目，上线后用户反馈最多的就是"消息收不到"、"连接经常断"。排查日志发现，移动端在弱网环境下WebSocket连接频繁断开，导致消息推送失败。 这个问题困扰了我好几天，尝试过各种方案，最终通过心跳机制+断线重连的组合拳，让连接稳定性提升了90%以上。今天就把这套方案分享给大家。 问题背景 WebSocket作为实时通信的首选方案，在移动端应用中广泛使用。但实际生产环境中，我们经常遇到这些问题： 网络抖动导致连接断开：用户在电梯、地铁等信号不稳定区域，WebSocket连接很容易断开 长时间无交互被中间设备断开：NAT设备、防火墙等中间设备会清理长时间无数据传输的连接 应用切后台被系统杀掉：移动端系统为了省电，会限制后台应用的网络连接 服务端无法感知客户端状态：连接断开后服务端还在推送消息，造成资源浪费 这些问题在弱网环境下尤为明显，严重影响用户体验。 问题分析 为什么WebSocket连接会断开？ WebSocket连接断开的原因有很多，但主要可以归纳为以下几类： 网络层面： 网络质量差，TCP连接超时 NAT设备超时清理空闲连接 防火墙规则限制长连接....

传统IM系统的挑战 在我们的日常开发工作中，经常会遇到这样的需求： 需要实现实时聊天功能，支持一对一和群聊 要有@提醒功能，让用户不错过重要消息 需要消息回执，确保消息已送达 要支持离线消息推送 要有良好的性能和扩展性 如果用传统的HTTP轮询方式，不仅服务器压力大，用户体验也不好。今天我们就用WebSocket + STOMP技术来解决这些问题。 解决方案思路 今天我们要解决的，就是如何用SpringBoot + WebSocket + STOMP构建一个功能完整的企业IM系统。 核心思路是： WebSocket连接：建立持久化的双向通信通道 STOMP协议：在WebSocket之上构建消息传递框架 消息路由：实现精确的消息推送和路由 状态管理：管理用户在线状态和消息状态 技术选型 SpringBoot：快速搭建应用 WebSocket：实时双向通信 STOMP：消息传递协议 Redis：消息存储和用户状态管理 Spring Security：连接认证 核心实现思路 1. WebSocket配置 首先配置WebSocket和STOMP： @Configuration @E....

用户量一上来，WebSocket连接数暴涨，服务器直接崩了？或者需要实现一对多的消息推送，但WebSocket实现起来复杂又容易出问题？再或者要支持离线消息、消息持久化，发现WebSocket根本搞不定？ 这就是传统WebSocket在即时通讯场景下的局限性。今天我们就来聊聊MQTT协议，看看它如何解决这些痛点，让你的即时通讯系统更稳定、更高效。

SpringBoot + Redis + WebSocket：实现万人在线实时聊天室，消息不丢、连接不崩！ 你有没有想过那些支持万人同时在线的聊天室是如何实现的？今天我就来分享一个基于SpringBoot + Redis + WebSocket的高并发实时聊天室解决方案，确保消息不丢、连接不崩！ 一、聊天室的技术挑战 在开始具体实现之前，我们先来看看实时聊天室面临的核心技术挑战。 // 聊天室技术挑战分析 public class ChatRoomChallenges { public void analyzeChallenges() { System.out.println("=== 聊天室技术挑战分析 ==="); System.out.println("1. 高并发连接：支持万人同时在线"); System.out.println("2. 消息实时性：毫秒级消息传递"); System.out.println("3. 消息可靠性：确保消息不丢失"); System.out.println("4. 连接稳定性：避免连接中断"); System.out.println("5. 数据一....