网站即时通讯功能的架构是什么？很多SEO人员为了提高用户体验，会给网站加通讯功能，看过我以前文章内容的人对于网站即时通讯功能的实现方法肯定是都知道了，这里为大家介绍一下网站即时通讯功能的架构。

即时通讯系统架构

简单地介绍一下大型商业应用的IM系统的架构。设计这种架构比较重要的一点是低耦合，把整个系统设计成多个相互分离的子系统。我把整个系统分成下面几个部分：(1)状态消息系统 (2)好友系统 (3)P2P系统 (4)其他扩展业务系统

先看状态消息系统

(1)connd

client接入服务器，可以支持UDP，也可以支持TCP，一般建议优先选择TCP。connd可以布置多台，client接入时，可以用简单的DNS轮询的方式实现负载均衡。connd功能是维护连接和转发消息包。

(2)pconnd

proxy connd, 代理接入服务器，是connd的扩展，除了有connd的功能外，支持服务器的接入，比如web server。

(3)msgd

消息处理服务器，主要功能是用户状态管理，消息转发(包括合理性验证)以及离线消息保存。

说一个用户登录成功后，对所有好友的状态通知过程。我设计的系统中，把用户状态也简单看成类似文本聊天消息。下面用户U的上线过程，他有好友F1, F2。

(1) connd收到U上线消息，将消息发给U所在的msgd。

(2) msgd获取U的好友，F1, F2;如果F1, F2和U不在同一个msgd上，msgd将消息通过connd转给F1, F2所在的msgd。

(3) 最终的msgd把上线通知通过connd发给F1, F2。

msgd的U是通过什么方式获取最新的好友呢? 这个问题我要着重描述一下。

用户的好友数据都在另外一个子系统中：好友子系统。 msgd通过TCP的方式(为什么用TCP呢?)主动从好友系统获取。同时，msgd也缓存一份好友数据。msgd获取用户好友时，如果cache是最新的，直接从cache取，否则要从好友子系统那边取。现在重点问题出来了，如何确定用户的好友是最新的?这类问题我们要根据不同的业务不同的特点灵活采用不同的方法。请看一种高效的处理方式：

(1) 好友子系统为每个用户的好友算个hash值(可以用MD5)。

(2) client获取好友时，同时也拿到这个hash值;发和好友相关的消息时，把hash值带给msgd。

(3) msgd第一次从好友子系统获取某个用户好友时，也获取这个hash值;像要转发状态消息，获取好友时，把client带过来的hash1和自身的hash2比较一下。。。

像IM这种业务特点是，对好友数据的写很少，读很多，相对于读的消耗，写基本可以忽略的。用上面的方法，基本上每次两者的hash值是相等的，直接从cache拿好友数据。这种处理方法也可以引入到其他应用业务中。建议不要每次都粗暴地跨进程获取类似好友数据。

网站即时通讯功能的架构是什么？以上就是对网站即时通讯功能的架构的相关描述了，这些你都学会了吗？