前言：
看了些讨论类似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的负载均衡系统。也 许真的是万法归综…