一个即时通信系统架构实现的讨论

关注

转载最新推荐文章于 2026-04-13 10:30:00 发布 793 阅读 AI 写同款· GEO 优化 ›

超实用！如何用Fiora打造属于你的私密社交网络今天给大家介绍一款免费开源的在线聊天工具——Fiora。它不仅是一款功能强大的即时通讯软件，更是开发者们展现创造力和技术实力的一个舞台。想象一下，在一个可以自由定制界面、扩展功能，并且完全开放源代码的平台上构建属于你自己的社交网络，这听起来是不是既刺激又充满挑战？Fiora不仅提供了丰富的功能和优秀的用户体验，还支持高度自定义。你可以根据个人喜好调整界面风格，添加各种插件来扩展功能。无论是文字、图片、文件传输，还是语音通话，Fiora都能满足你的需求。阅读详情

一个即时通信系统架构实现的讨论转载

标签：

im系统架构

分类：技术随想

前言：

看了些讨论类似QQ的系统的文章，自己以前参与的一个项目，就做这个，不过规模相对小点。写份文档，旨在清理清理思路，交流一下经验。这里的一些模块名称（ACS、NAS），采用了以前公司的命名方式，我觉得这么用不当，觉得没有必要令换个名字。文中的内容与那个系统也有很大的区别，时间太长了，很多东西记不清了是一个原因，再者一直觉得那东西问题多多，做了些更改，同时为简单起见，去掉了很多的细节内容。准确地说这里描述的系统应该是一个杜撰出来的，因此我想不涉及什么商业秘密。

一、摘要

这个系统就支持用户的能力，我觉得完全可以支持像QQ那样的用户规模，不过个人觉得要是那么大的用户规模的话要做不少的优化处理。我接手做这东西的时候，支持三十万左右的并发在线就会宕掉。经过我的一番修理基本可以稳定支持到40万用户。感觉这个系统设计的也还行吧。大致结构如下

二、整个系统的逻辑视图

各模块的说明：

C-XX：用户端使用自己定义的协议与NAS、ACS进行通信，提供IM的基本功能。
NAS：为用户C-XX分配ACS服务器，在用户登录时进行。NAS简单的采用轮转的方式，依次分配系统中存在的ACS给登陆的用户。
ACS：为用户提供IM服务端功能，主要有用户信息的修改，用户状态的维护，用户消息的处理等。ACS之间的逻辑结构是网状的，任何两个ACS都可以平等的进行通信。
DB：保存用户的状态，不同的DB分成不同的区，维护不同段的用户。每个ACS到各个分区的数据库都有连接，ACS根据用户所在的区，访问相应的数据库，存取用户的数据。

C-XX、NAS、DB-X的具体内容在这里不做太多的讨论，主要描述一下ACS的具体结构，主要的模块如下

三、ACS的主要逻辑模块

ACS中各个逻辑单元之间的描述：
UserAgentsManager：管理用户相应的Agent，登录到服务器的所有UserAgent由其进行维护。
UserAgent：用户的代理，提供用户功能的服务器侧实现。主要包括根据用户的操作，修改相应的数据库信息，维护用户状态，更新数据库中的用户状态和定位信息，包含用户的好友列表（Friends）维护用户的在线好友，根据用户的要求提供不同用户之间的通讯功能。
ServerManagerModule：收集服务器的性能信息，维护日志信息和配置信息等。
CommunicateWithOtherAcs：提供到其他ACS的通信服务功能。维护配置数据库中自身的状态，并从配置数据库中同步系统中其他ACS服务器的状态。
UserLocatorInfoCache：对于用户的定位信息，要在向指定的用户发送数据包的时候频繁使用到，为减少这种数据库的访问操作给服务器带来很大的压力，对这种信息进行缓存，减少对数据库的压力。
DatebaseAccessModule：提供数据库的访问接口。区分用户所在的段，到相应的数据库，存取用户的数据。

用户定位信息：包括用户ID，登录的ACS编号，用户登录使用的IP地址，用户登录使用的端口(Port)，用户使用的网络类型。这些信息是实现用户间的通信必需的，这些信息的维护和获取是系统中一个核心任务，相关操作十分频繁。

四、物理部署视图

说明：NAS为避免单点实效性，可以采用DNS或者NAT的方式，在多台服务器之间进行负载平衡。

五、主要流程

5.1 登录处理

简单描述：用户的登录时，要将所有的在线好友的状态从数据库中取出，通知所有的好友用户登录事件，同时更新自己在数据库中的信息。以后用户数据包的转发，基本上是在好友之间的，保存好友的信息可以大量的减少对数据库的访问。

5.2 ACS转发用户的中转消息的处理

简单描述：在向指定的用户发送信息的时候，需要用户的定位信息，这些信息依次在好友列表，本地缓存和数据库之中进行查询。实际测试发现，使用本地缓存可以大大减少对数据库的访问。

5.3 通过ACS转发消息

简单描述：对于一些比较特殊的网络类型，如果需要保证数据包抵达指定用户，最稳妥的方式就是通过目的用户登录的ACS进行中转。在上图中User-01登录到ACS-01，User-02登录到ACS-02。

后记

一、支持更大规模应用的考虑

我不维护这个系统的时候，系统可以支持40万左右。当时的感觉系统并没有达到支持的上限，感觉可以支持到100万左右。对于系统的近一步扩大，觉得系统还有宽展的潜力，支持更大规模的应用不是什么问题。可以在以下方式进行扩展：

1、根据用户的使用习惯，细分分区，减少单个数据库的压力。服务器对于分区的变化能够给与相应的支持。
2、对于用户登录的ACS的分配，使用复杂的策略，可以区分用户，使用不同的ACS。对于系统压力分布的可以方便的调整。
3、感觉通过提高系统的配置性，可以实现不停的通过简单堆叠扩展系统容量，使系统随用户数量增加不断扩大。

二、和以前看过的一些系统的对照

后来感觉这个系统和GSM系统有些相似的地方，像保存用户信息和用户状态的数据库有点类似HLR的功用，对于ACS则有点像SMC，用户可以在各个ACS登录，登录到ACS后用户数据库中的用户状态要进行更新，以示其他用户和这个用户进行通信。对于NAS和ACS集群，很像个基于DNS的负载均衡系统。也许真的是万法归综…

收录于