http://webisbeauty.appspot.com/2010/08/20/webim-message-arch.html

1. ASSFM:Acess and Storage Service for
Frequent Message
Guang Feng
August 20, 2010
Powered by LTEX
A
1 Goals
方案提供在线即时通讯服务所需的消息可用存取和持久化存储的系统设
计。
在线即时通讯服务 (以下简称 WEBIM) 产生的短消息具有以下特征:
• 频繁发生
• 时序上下文关联
• 多维标识 (消息流水, 聊天双方等)
• 有限长度文本
2 Solutions
ASSFM 逻辑上由存取和持久存储两部分构成。
根据实际的使用场景,WEBIM 具有“多写少读“和“短写长读”的特点, 因
此系统按照存取总线架构设计。
1

2. 2 SOLUTIONS 2
2.1 消息写总线
ASSFM 写总线涉及到的物理单元:
• Chat Server, 需要接入的 WEBIM.
• Message Unit(消息单元), 部署在 Chat Server 端.
• Message Stream Server(消息流服务).
• Context Intergradation Cache(上下文聚集堆).
• Persistence Layer(持久化存储层).
消息写流程图
Message Unit 被设计成采用 UDP 协议的异步通讯客户端.[可选] 消息文
本可以被编译成二进制格式, 已节省传输带宽, 参考 Google Protocol
Buffer.

3. 2 SOLUTIONS 3
Message Stream Server 将包含一个 Stream UDP Server. 其采用流式服
务器设计, 可以高速的将消息交给后续流程, 而不被阻塞; 另一个重要
的部分是 Dispatch 服务器, 它将流服务器传递的消息文本 (若为二进
制形式, 则在此处还原成文本), 传输至上下文聚集堆.
Context Intergradation Cache 接受 Dispatch 传递的消息文本, 根据
其中的上下文流水号, 压入相应的会话消息缓存栈栈顶; 伴随着预定
义的栈生命周期结束或者显式的会话结束信号, 将整个会话栈的内容
(context) 传输至持久化层.
Persistence Layer 接收前述 context, 并根据 context 的内容和属性, 构
建查询索引 (会话流水, 发起人, 接受人...). 随后完成 context 实体存
储.
由于大量 context 的频繁写硬盘, 可以预见磁盘 IOPS 将成为瓶颈. 针对
context 的结构类型不同看法, 该层可以通过以下几种方式实现:
• 关系 数 据 库:context 在 粗 粒 度 上 具 有 结 构 化 特 征. 因 此 可 以 采 用
MySQL Archive 引擎, 相对于 MyISAM 等引擎, 其大幅减少物理存
储开销, 也提供了高效的读写效率, 并满足''Read Consistency''.
• 文档数据库: 采用 JSON,XML 或者 YAML 组织文档类型的半结构化数
据库. 参考 BaseX,MongoDB.
• 分布式文件系统
2.2 消息读总线
ASSFM 读总线涉及到的物理单元
• Context Cache, 分为 Index 和 Context 两部分.
• Persistence Storage
消息读流程图
当浏览器请求具体的历史消息数据时, 逻辑层会首先在 Context Index
Cache 中寻找. 命中即返回 Context Cache 中相应的数据; 反之, 在持久
化存储中查找, 并更新内容缓存和索引缓存.
根据实际业务,Context Cache 的更新策略需要满足 Results Consistency.

4. 2 SOLUTIONS 4