这里特别说一下消息存储的选型。这条路上我走了三次弯路：第一版用 MySQL 存消息，数据量上来后Zuo了分库分表，但 IM 消息的高频写入hen快把 MySQL 打到瓶颈；第二版迁移到 HBase，写入性Neng上去了但 IM 的查询模式和 HBase 的 scan 模型并不匹配——HBase 擅长基于 rowkey 的精确查找，而 IM 消息geng多是范围查询和分页查询。

日常开发中，同时管理 MySQL、MongoDB、Redis、ES 四种数据源的连接和调试是家常便饭。PBP 分屏模式下左半屏写代码，右半屏开数据库客户端查kan数据，不用 Alt+Tab 切来切去，效率高hen多。需要对比两端数据时PIP 画中画也hen方便——主屏写代码，小窗监控 Redis 状态。

我是蝎子莱莱爱打怪，全网同名，欢迎关注我的公众号。

这样既保证了消息及时性，又避免了大量离线消息瞬间涌入导致客户端压力过大。

我的方案采用的是读扩散模式。消息只存一份到 MongoDB，客户端拉取群聊历史时根据 chatId+ 时间范围分页查询。这样写入效率Zui高，而且 MongoDB 分片集群的范围查询Neng力足以支撑读侧的压力。

class ChatSessionManager {  final XZLLIMClient _imClient;  final String _chatId;  bool _isClosed = false;  ChatSessionManager._      : _imClient = imClient, _chatId = chatId {    _imClient.setCurrentOpenChatId;  // 打开聊天时自动设置  }  void close {    if  return;    _isClosed = true;    _imClient.setCurrentOpenChatId;  // 关闭时清空  }}

客户端使用方式hen简单：

后端：Spring Boot . + Spring Cloud . + JDK 通信：Netty WebSocket + Protobuf + gRPC存储：MySQL + MongoDB+ Redis + Elasticsearch + MinIO消息队列：RocketMQ客户端：Flutter  + GetX + 自研 IM SDK配置中心：Nacos

为了支撑这套系统，我自建了 ESXi 服务器，跑了 个虚拟机来模拟生产环境。基础设施全自建，从数据库到消息队列到配置中心，全部自己搭建和维护。

群聊消息和单聊的Zui大区别在于：一条消息需要推送给群内所有在线成员。

所有消息进来后先由 HandlerDispatcher Zuo分发。它利用 Spring 的 ApplicationContext 自动发现所有 ProtoMsgHandlerStrategy 实现，按 MsgType 注册到 Map 中：

迁移到 MongoDB 后利用其灵活的 Schema 和丰富的查询Neng力，消息存储和查询dou顺畅了hen多。目前 MongoDB 部署为分片集群架构，配合智Neng查询路由，Ke以根据查询条件自动选择Zui优的分片和索引，避免全分片扫描。

final Map<String, int> _messageCache = {};static const int _maxCacheSize = ;static const int _messageCacheTtlMs =  *  * ;  //  分钟bool _isDuplicateMessage {    _evictExpiredMessageCacheEntries;    if ) return true;    if ) return true;    return false;}

这是 SDK 中一个比较巧妙的设计。ChatSessionManager 追踪当前打开的聊天会话，SDK 自动对当前聊天发送Yi读 ACK——用户完全无感知：

fixed64 msgId = ;    //  字节fixed64 from = ;     //  字节fixed64 to = ;       //  字节

为什么百度不收录我的文章？😂

"为什么百度不收录"这个问题,说实话,我也碰到过。害,你懂的,咱就是说,网上答案一大堆,但真正有用的没几个。

"内容质量要高"这话谁dou知道,但怎么才算高质量？说实话,这本身就是个玄学问题。你kan那些爆火的文章,有时候咱也不清楚它凭啥火,就觉得"嗯,这玩意儿确实Neng吸引人"。但有时候你绞尽脑汁写的东西,就是没人搭理——这就有点尴尬了。

"原创"这点毋庸置疑得坚持,但光原创还不够——你得让搜索引擎觉得你的内容值得被检索。说白了,就是要解决用户的痛点,或者提供有价值的信息。我个人觉得,Ke以从这几个角度入手:

"痛点"这个东西其实挺好找的,就kan你Neng不Neng站在用户的角度想问题。比如你Zuo技术类文章,那你的读者肯定是在技术上遇到了瓶颈,你就得帮他们突破这个瓶颈。

"关键词优化"这事儿吧,有点老生常谈了,但确实有效。你得研究清楚哪些词是用户经常搜的,然后合理地把这些词嵌入到你的标题和正文里。当然,不Neng为了优化而优化,该自然还是得自然一些。

"结构化数据"这个玩意儿现在越来越重要了。你kan那些带"问答"结构的页面,在搜索结果里显示得就hen漂亮,直接把答案展示出来了。咱就是说,Ru果Neng把自己的内容Zuo成这种结构化的数据,被收录的概率是不是就大一点？

"持续geng新hen重要",这一点百度官方其实也说了。你要是长时间不geng新,那搜索引擎自然会认为你的站点活跃度不高,从而降低抓取频率。所以哪怕你Zuo不到天天geng新,也尽量保持个规律,比如周geng或者月geng——总之得让搜索引擎觉得你还在持续产出有价值的内容。

gRPC 服务间通信与字段存储优化

service MessageService { 
rpc ResponseServerAck2Client returns ; 
rpc ResponseClientAck2Client returns ; 
rpc SendWithdrawMsg2Client returns ; 
rpc PushFriendRequest2Client returns ; 
rpc PushFriendResponse2Client returns ; 
rpc TransferC2CMsg returns ;  
// 跨节点转发
}

gRPC 服务定义了一系列 RPC 方法,其中Zui核心的是 TransferC2CMsg,用于跨节点转发单聊消息。当发送者和接收者连接在不同 im-connect,节点时,通过这个方法实现消息转发,保证系统的高可用性和可 性。这种设计使得每个节点Ke以独立处理本地连接的消息,同时通过 gRPC 实现全局消息路由,避免单点故障。

**gRPC 服务定义** 不同 `im-connect` 节点之间通过 gRPC 转发消息,定义了多个 RPC 方法,其中Zui核心的是 `TransferC2CMsg`,专门用于跨节点转发单聊消息。当发送者和接收者连接在不同的节点上时,这个 RPC 调用确保消息Neng够跨节点传递。 proto service MessageService { rpc ResponseServerAck2Client returns ; rpc ResponseClientAck2Client returns ; rpc SendWithdrawMsg2Client returns ; rpc PushFriendRequest2Client returns ; rpc PushFriendResponse2Client returns ; rpc TransferC2CMsg returns ; // Zui核心的跨节点转发方法 }

**Protobuf 存储优化** Protobuf 作为二进制协议,在效率上远超 JSON。为了进一步压缩数据,我Zuo了三个关键字段的存储优化:

雪花 ID 用 fixed64 存储

原本用 string 存储雪花 ID 会占用geng多空间。

用 fixed64 直接存储数字本身,只占固定8字节,相比字符串表示Neng省不少空间。

proto fixed64 msgId = 1; // 消息ID,8字节 fixed64 from = 2; // 发送者ID,8字节 fixed64 to = 3; // 接收者ID,8字节

每条消息里dou有这些 ID 字段,一加起来还是Neng省不少带宽的。

UUID 用 bytes 存储原始字节

UUID 默认是字符串表示,比如 "550e8400-e29b-41d4-a716-446655440000"。

用 bytes 存储 UUID 的原始二进制数据,只需要16字节,而不是36字节的字符串形式。

proto bytes clientMsgId = 1; // UUID原始字节,16字节

chatId 服务端动态计算,不传输

会话 IDKe以通过发送者和接收者的 ID 按规则计算出来,比如 "c2c-${smallerUserId}-${largerUserId}"。

不需要在每条消息里重复传这个字段,直接省掉了20多个字节。

**三端协议一致性** 另一个我选择 Protobuf 的重要原因是它天然支持多端协议一致性。IM 系统涉及 Java 后端、Flutter SDK 和 Flutter Client 三个端,用同一个 `.proto` 文件定义协议Ke以确保三端接口完全一致。改动协议时编译器直接报错,不像 JSON 靠文档约束那么容易出错。 proto // ImProtoRequest.proto message ImProtoRequest { MsgType type = 1; bytes payload = 2; } // C2CSendReq.proto message C2CSendReq { bytes clientMsgId = 1; fixed64 msgId = 2; fixed64 from = 3; fixed64 to =4 ; // ... } 这种强类型约束让跨语言协作变得非常顺畅。 整体来kan,gRPC + Protobuf 的组合不仅带来了性Neng提升,还大幅简化了多端协作成本,是 IM 系统里非常关键的技术栈。 Flutter 开发与设备调试体验 Zui终选择 Flutter 作为客户端技术栈有几个原因:

跨平台 Flutter Ke以一套代码同时支持 Android 和 iOS,不需要像原生开发那样维护两套代码。