接到一个Golang后端工程师的面试邀请，对方是做IM消息相关的业务，在之前的工作项目里有消息队列中有相关经验，也整理了一些资料，重新回顾一下消息推送的整理架构方案，温故而知新。当时我的技术实现方案是`swoole + websocket` 设计和实践的，接下来我分别梳理有关的知识点，生产环境实际用户360w+ , 活跃PV 30w+ ，峰值集中在每晚20-24点之间，运行消息队列的服务器4c8g的云服务实例。

### 一、数据表设计

设计两个数据表，消息表（user\_message\_status）、用户消息状态表(user\_message\_status)，为每个用户维护一个 **已读系统消息的最大 ID**，当用户上线或刷新时，根据该 ID 从数据库拉取所有未读的系统消息，也可以用来统计用户的未读消息数。

下面是消息表和消息用户消息状态表的数据表结构表：

```sql
CREATE TABLE `system_message` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '消息ID',
  `content` text NOT NULL COMMENT '消息内容',
  `type` tinyint(4) NOT NULL COMMENT '消息类型：1-系统公告，2-用户',
  `status` tinyint(4) NOT NULL DEFAULT '1' COMMENT '状态：1-有效，0-已删除',
  `create_time` datetime NOT NULL COMMENT '创建时间',
  `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
  PRIMARY KEY (`id`),
  KEY `idx_status_create_time` (`status`, `create_time`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='系统消息表';
​
CREATE TABLE `user_message_status` (
  `user_id` bigint(20) NOT NULL COMMENT '用户ID',
  `last_read_sys_msg_id` bigint(20) NOT NULL DEFAULT '0' COMMENT '已读的最大系统消息ID',
  `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
  PRIMARY KEY (`user_id`),
  KEY `idx_last_read_id` (`last_read_sys_msg_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户消息状态表';
```

**为什么这样设计？**

*   `system_message` 只存一份，节省大量存储空间，也避免修改内容时需要更新所有副本的难题。
*   `user_message_status` 只存**有状态变更**的记录。如果一条新消息发出，10万用户全是未读，那就不需要立即插入10万条“未读”记录，这是优化性能的关键。

### 二、消息模型

![消息模型.png](https://developer.qcloudimg.com/http-save/yehe-10334881/cd74eac462404bf6be89d7881e0863d3.png)

**1、生产者-消费者模型（图1-上）**

针对用户的个人提示，比较简单和易于实现，在用户的评论、作者动态、评论等操作下使用触发埋点任务，通过Swoole提供的Http部分，把消息存储在Redis的消息队列中，队列的数据结构保证了排列有序，在用WebSocket 推送给已经建立链接的用户，用户界面上有小红点提示，表示有更新。

还有一部分用户离线或者是断开的情况，断开的时候，用户主动重试进行数据拉取，读取未读的消息，以确保消息被成功接收。

**设计特点：**

*   在实际的工作中尽量使用最简单的架构实现方案，来实现业务要求，解决业务问题，降低后期维护成本。
*   服务都部署在云服务中，实现了局域网网络通信，以保证高性能、简单和安全，和Rpc通信比较类似。
*   这种业务场景对消息队列的实时性不高，做到性能和功能的平衡。

**2、发布 - 订阅模型（图1-下）**

在站内信类型中有一种特殊的业务场景，站内消息，发送一个站内消息，需要将一份消息数据分发给多个消费者，要求每个消费者都能收到全量的消息，我们不能把同一个消息发送300w次，既浪费了资源也造成了难以维护。

每当用户进行WebSocket进行连接成功时， WebSocket 连接池中的所有在线用户存储在Redis的有序集合（ZSET）中，这个有序集合（ZSET）就属于消息的**订阅者**，有序集合的特点在于数据结构中每个元素带一个 score（通常为时间戳），支持按分数范围操作，适用于需要按时间顺序处理、批量删除或分页扫描的场景，可维护性、扩展性都非常友好和便捷。

在Task任务中新增系统消息时，发送方就自然转换成**发布者**角色，这里面的通信过程就是消息的 **发布 - 订阅模型**，多用户这种场景。

### 三、推拉策略

**1、分批执行**

当时使用的是 Crontab 来实现和执行定时脚本处理 消息队列中的数据，设计方案为快慢2条双队列结构，快队列主要处理当前最新的消息，如果用户超过1天不上线，放入延迟队列执行，用户超过超过15天未登录，消息释放。

WebSocket的心跳时间是300s,所以 Crontab 4min,执行一次，延迟队列6分钟执行一次，我们的redis使用的是链接池单节点特点，整个服务都在依赖，所以这样设计的方案，为了尽可能的节省资源，把时间窗口内的时间区域里对用户进行分组，避免相同消息进行重复推送。

**2、实时推送 + 离线兜底**

为了更好的优化性能，增强体验，在程序设计上线上实时推送给WebSocket 连接池中的所有在线用户，推荐采用 **“推送 + 拉取”** 模式：WebSocket 只推送一个轻量级的 `{"event":"system_msg", "msg_id":123}`，客户端收到后自行请求 `/api/messages/unread` 获取完整内容。这样推送的负载极小，能轻松应对全量在线用户。

在用户打开App时，会主动连接WebSocket服务，进行未读消息拉取，已达到性能和功能的平衡。

### 四、可靠交付

![方案设计.png](https://developer.qcloudimg.com/http-save/yehe-10334881/1d211f5f6e482f9626e6ca0b1070552b.png)

随着业务场景的升级和多样性，在我开发的消息系统里还有这样一个场景，一个是消息体形式丰富、一个是客服IM对话，需要保证服务数据的实时性和完整性，主要解决的数据包的可靠准确的传递，让我在Tcp协议上得到了启示，tcp的可靠交付主要有以下3点：

**1.解决不丢包问题：Ack + 重试**

网络丢包是一定会出现的，对上层应用来说，只有一个办法就是不停的重发，服务器每次收到一个包，就要对客户端进行确认，反馈给客户端已经收到了数据包，如果客户端在超时时间内没有收到Ack，则重发数据。

在确认的时候，Ack每个数据包都要一一确认，效率太低了，客户端对发送的每个数据包编一个号，编号由小到大单调递增，基于编号就能进行确认。

**2.解决不重的问题**

因为只要超过了约定时间，客户端还没有收到服务器的确定，客户端就会重发，顺序Ack，服务器给客户端回复Ack=6，意思是所有小于等于6的数据包都收到了，之后凡在收到这个范围的数据包，则判定为重复的包，服务器收到后丢弃即可。

**3.解决时序错乱的问题**

假设服务器收到了数据包1,2,3，回复客户端(Ack=3),之后接收到5，6，7，而数据包4迟迟没有收到，这个时候怎么办呢？

服务器会把数据包5，6，7暂时存放，直到数据包4的到来，再给客户端回复Ack=7，如果数据包不来，服务器的Ack进度会一直停在那(保持Ack=3)，等客户端超时，会把数据包4，5，6，7，全部重新发送，这样服务器收到了数据包4，回复ack=7，同时数据包5，6，7重复了，通过上面说的判重的办法，丢弃到上面的5，6，7。

![deepseek_mermaid_20260321_4aefba.png](https://developer.qcloudimg.com/http-save/yehe-10334881/e0a1ea5b6d4f0af9e84102e44e2dc6b2.png)

设计思路和实践：

*   **唯一请求 ID序列号**：客户端为每个请求生成唯一 ID，服务端记录已处理的 ID，实现**幂等性**，防止重复处理。
*   **同步 ACK 响应**：服务端处理成功后，必须返回一个明确的确认信息（如 `{ "status": "ok", "requestId": "xxx", "resourceId": 123 }`）。客户端收到此 ACK 后，才认为数据已可靠送达。
*   **超时重试**：客户端在超时或收到非确认响应时，使用相同的请求 ID 重试，直到收到 ACK 或达到最大重试次数。
*   **持久化存储**：服务端在确认数据已安全存储（数据库、消息队列等）后才返回 ACK，确保数据不因服务重启而丢失。

### 五、紧急处理

一般在新服务上线后都需要磨合期，尤其是采用新技术后多注意观察，在服务上线半个小时后，因为推送把主站的Mysql干挂了，最主要是没有进行Redis缓存，在高并发的场景下，没有缓存等于裸奔，根本扛不住，我当时觉得Swoole具有异步、协程这种高级特性是可以顶住的，后果就是很严重，现在想想也特别感谢伙伴们对我的包容，让我有了飞速的成长。

**1、并发锁** 相同用户在同一时间有3s的锁定状态，用来防止关系错乱，在客户端发来请求时优先获取缓存，近少可能的访问数据库，提高服务的稳定性和性能。

```php
//设置分布式锁,3s之内只能请求一次
$lock = RedisPool::invoke(function (Redis $redis) use ($toUid) {
    return $redis->get(Category::$openLock . $toUid);
}, self::REDIS_CONN_NAME);

if ($lock) {
    $msgErrorRet['code'] = 416;
    $msgErrorRet['msg'] = 'Please try again';
    return $this->response()->setMessage(json_encode($msgErrorRet));
}

//查询是否存在链接关系
$imUserRelation = RedisPool::invoke(function (Redis $redis) use ($toUid) {
    $redis->setEx(Category::$openLockPrefix . $toUid, 3, $toUid);
    return $redis->get(Category::$imUserRelationName . $toUid);
}, self::REDIS_CONN_NAME);
```

**2、网络异常处理，回收服务**：针对App崩溃、网络异常断开的链接，主动监听断开的fd，进行关系处理，对所有断开链接的websocket，进行回收，清除关系。

```php
static function onClose(\swoole_server $server, int $fd, int $reactorId)
{
    $info = $server->getClientInfo($fd);
    $fd = intval($fd);
    if ($info && $info['websocket_status'] === WEBSOCKET_STATUS_FRAME) {
        TaskManager::getInstance()->async(function () use ($fd) {
            RedisPool::invoke(function (Redis $redis) use ($fd) {
                //回收用户
                $uid = $redis->hGet('PUSH_MSG_SOCKET_FD', $fd);
                if (isset($uid) && !empty($uid) && is_numeric($uid)) {
                    $redis->zRem('PUSH_MSG_USER_LOGIN', $fd);
                    //检测是否有客服关系未断开
                    $redis->del(Category::$imUserRelationName . $uid);
                    $redis->hDel('PUSH_MSG_SOCKET_FD', $fd);
                }
                //回收客服管理用户
                $cUid = $redis->hGet('PUSH_CUSTOMER_MSG_SOCKET_FD', $fd);
                if (isset($cUid) && !empty($cUid)) {
                    $redis->zRem('PUSH_CUSTOMER_MSG_USER_LOGIN', $fd);
                    $redis->hDel('PUSH_CUSTOMER_MSG_SOCKET_FD', $fd);
                }
            }, 'redis');
        });
    }
}
```

**3、发散缓存，防止雪崩**：为了防止缓存雪崩(雪崩就是指缓存同一时间到期)，用户访问峰值是晚间21-24点这个时间段，峰值大概100w/请求，持续4个小时左右，但因为用户中心的缓存时间为7300s，在7300s的时间里分散释放缓存。

```php
$uid = $redis->get($token);
$expireTime = 3650 + rand(1, 3000);
            
$uid = OAuth::getUserInfo($token);
if (!empty($uid) && intval($uid) > 0) {
    //存入缓存时间，过期时间小于 7300s
    $redis->setEx($token, $expireTime, $uid);
}
if($uid && $uid > 0){
    $key = 'token_'.$uid;
    $redis->setEx($key, $expireTime, $token);
}
```

### 六、压力测试

编程的内核是数学，而测试的本质是计算，专业名词叫容量预估，而测试的大体就是用程序模拟程序，检测程序的正确性，有两个点需要注意，QPS最佳值和系统接收最大值，根据测试数据的反馈，针对测试的现象和反映进行优化。

**1、Jmeter Thread Group 线程组设置**

jmeter自带的thread group非常简单， 一个thread 代表一个vuser，那么我们如果需要多少用户并发，设置多少线程数即可。ramp-up period， 是多少时间从0个 vuser 上升到您指定的vusers数。从这些参数可以看，非常简单。但不能设置测试的时间，这一点不是特别善解人意。不过还好我们有jmeter plugins, 带的thread group 添加了这个功能。

**2、数据准备**

随机读取用户表里1000个用户，进行压力测试，构造测试需要的数据(10w条为例)，查询最大链接数，检测服务器Mysql链接状态，主要的思考点在于用户访问具有随机性，模拟数据时尽量做到接近真实场景，代码如下：

```php
$str = '62210,45783,36209,146502,24599,168338,166511,1917...';
$uidTestArr = explode(',',$str);
foreach ($uidTestArr as $uid){
    if(isset($uid) && intval($uid) > 0){
        $json = file_get_contents('http://open.stark.com/login/gettoken?uid='. $uid);
        $json = json_decode($json,true);
        $temp[] =   [ 'uid' => $uid , 'token' => $json['token']  ];
    }
}
$index = rand(0,count($temp) - 1);
$randData =  $temp[$index];

//随机执行结果
/**
Array
(
    [uid] => 166511
    [token] => f46540f11a40afeb9998cbe76661ec8234a87054
)
*/
```

Crontab的测试代码Demo，先灌入测试数据，考虑的是Crontab的实际吞吐能力，优化计划任务的执行间隔，使用Curl和shell\_exec实现,执行结果，返回数据 `{"code":200,"result":[],"msg":"OK"}`

```php
$str = "62210,45783,36209,146502,24599,168338,166511,1917,135799,8326...";
//去掉可能存在的换行和空格
$str = str_replace(array(PHP_EOL, ' ' ,'',$str));
$testUsers = explode(',',$str);
for ($i=0;$i<10000;$i++){
    $index = rand(0,99);
    $uid = $testUsers[$index];
    $msg = '{
      "rid": 225,
      "uid": "",
      "top_rid": 225,
      "module": "novel_chapter",
      "module_name": "1022 last dance 第13章",
      "module_id": 1019712,
      "module_nid": 163961,
      "comment_uid": 268,
      "comment_nickname": "测试小宝贝",
      "content": "你好呀",
      "gift_id": 0,
      "gift_name": "",
      "gift_number": 0
    }';
    $url = 'http://msgdev.stark.com/api/comment/message';
    $json = shell_exec( "curl -d 'uid={$uid}&msg={$msg}' {$url} " );
    echo   'i:'.$i.',json:'.$json.PHP_EOL;
}
```

特殊说明有一点事特别需要强调的，不用被所谓的100w或者1000w流量的标题吓倒，比如1000w/h的访问量,Qps就变成了27777/s，每个用户请求的热门接口30个，这才是测试的真相，关键地方使用内存数据库进行加速，障碍就迎刃而解了：

```bash
10000000 / 60 / 60 / 30  = 925/s
```

### 成果

上线2年的时间里，进行了5次升级和优化，活跃用户10w+，最高峰值6w/s,130w/h访问量，是一个非常成功的实践结果。

用最简单的技术实现方式，节省企业成本，减少系统开发和维护成本，提高办公效率才是技术人应该做的事儿，做解决实际复杂业务解决方案并落地的技术人，En。

*   并发链接和并发查询：并发链接只是多消耗一点内存，并发查询才是CPU的杀手。
*   对系统的流量提前进行容量评估，归根结底为计算问题，不管多大的流量最后的解决办法都采用分而治之的策略。
*   手动的效率太低，用程序测试程序。
*   减少不必要的日志写入，以减少磁盘I/O的传输。
*   缓存和Mysql是一种平衡，需要去计算。


接到一个Golang后端工程师的面试邀请，对方是做IM消息相关的业务，在之前的工作项目里有消息队列中有相关经验，也整理了一些资料，重新回顾一下消息推送的整理架构方案，温故而知新。当时我的技术实现方案是swoole + websocket 设计和实践的，接下来我分别梳理有关的知识点，生产环境实际用户360w+ , 活跃PV 30w+ ，峰值集中在每晚20-24点之间，运行消息队列的服务器4c8g的云服务实例。

Golang后端面试复盘：从Swoole到IM架构，如何支撑360w用户的实时消息推送？

收到Golang面试邀请后，我重新整理了之前设计的IM消息系统。核心场景，展示了从数据模型到应用架构（Swoole协程+WebSocket+Redis）的全链路设计。核心内容包括：如何利用“推拉结合”应对高峰期流量（快慢队列+离线兜底）、如何基于有序集合实现全量用户的发布订阅、以及借鉴TCP协议解决消息的丢包和重复问题。

后端高级工程师

架构设计

Golang后端工程师分享IM消息系统架构设计经验，采用Swoole+WebSocket实现360万用户30万PV的消息推送系统。详解消息表与状态表分离设计、生产者-消费者与发布-订阅模型、推拉结合策略、TCP可靠交付机制及压力测试方案，有效支撑6万/秒的高并发场景。

消息队列

数据结构

压力测试

数据库

服务器

Redis

OAuth

腾讯云 IM，全球通信，1折起


4核4G3M云服务器 新用户低至38元/年！

2026新春采购季

message-queue-catalog

tencentdb-catalog

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Golang后端面试复盘：从Swoole到IM架构，如何支撑360w用户的实时消息推送？-腾讯云开发者社区-腾讯云

Golang后端面试复盘：从Swoole到IM架构，如何支撑360w用户的实时消息推送？

Golang后端面试复盘：从Swoole到IM架构，如何支撑360w用户的实时消息推送？

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐