我的XMPP协议IM架构(转载)

  09年进入公司就开始研究openfire,做一款手机IM软件,经过3个月的不懈努力,产品终于上线了。上线初产品功能比较简单。上线初架构比较简单,服务器是单机,后来由于用户的不断增长,单机已经不能满足需求,所以就不断优化架构,其中经历了不少的艰辛,到目前系统相对基本稳定(注册用户2000W,同时在线用户200W+)。废话不多说,下面直接上架构图,由于这个这个架构图有点老,跟现在的架构有一点点区别,但大致相同。

由于该产品服务端基本都由我一个人负责,所以目前的架构很存在诸多问题,还需不断优化,欢迎大家拍砖~~~

    系统架构:智能DNS + lvs  + nginx + memcache + redis + mysql  + lucene +  FastDFS

下面继续说下使用相关技术的原因及用处。

(一) 智能DNS,这个相信大家都知道,就不多说了

(二) lvs主要用来做负载均衡,终端用户通过lvs 连接到前端的服务器。lvs确实很变态,支持百万级连接,我们最多的时候通过lvs分发150W+用户到前端服务器。

    但是使用lvs也遇到很多问题,特别是lvs的分发策略及健康检查,如果用的不好,如果前端出现问题,会挂掉一批机器。曾经好多次lvs时不时误判某台前端挂掉,将该前端所有请求瞬间分发到其他机器,导致其他前端顶不住压力而挂掉,为此一直很烦恼找不到原因,经常百思不得其解。也许是苍天不负有人,有次灵感一闪,会不会是JVM垃圾回收导致的呢?

  由于JDK1.6 JVM默认采用UseParallelGC,JVM在全局回收的时候暂停服务,导致lvs的健康检查timeout。然后开始研究JVM的垃圾回收机制,优化JVM配置,同时修改lvs健康检查timeout时间,优化后问题从此解决。

下面是我的JVM配置:

-Xms8048M -Xmx8048M -Xmn1048m -Xss256k -XX:PermSize=256m -XX:MaxPermSize=256m -XX:+DisableExplicitGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=75

(三) nginx主要是用来做http代理请求转发。刚开始是由于业务的修改及代码的重新部署都需要重启服务器,然而用户都是通过socket与服务器通讯,重启必然造成登录到该服务器的所有用户掉线,这样体验很不好。时常想QQ每次更新服务器是怎么做到我们不掉线的呢?在网上也搜了很多关于IM的架构资料,后来想到openfire里面的业务处理大部分都是通过IQ包来请求处理的,所以把前端IQ包收到的请求都通过http转发给后端的服务器处理,这样更新代码只要不涉及到核心就只要更新业务处理服务器代码,利用nginx的平滑重启,用户根本不知道我们在更新代码,这样就不会对用户有影响。

(四)memcache集群与redis集群主要是用来缓存用户信息的,至于为什么要同时用redis和mc,是因为要支持多终端登录,需要用到redis的hset数据结构,但由于redis比较耗cpu,所以不想把mc换成redis。

(五)mysql主要用来做数据持久化,通过水平划分和垂直划分来存储数据,这个也是常用的办法。mysql表在千万级基于索引的查询性能还是可以的,但是mysql有个很致命的问题就是如果加字段,那就悲剧了。。。。。所以nosql在互联网才能将它的长处发挥的淋漓尽致。

(六)lucene主要用于用户的搜索,至于lucene的实时搜索我们是通过用户在修改资料的时候,通过http异步实时更新到lucene建索引。

(七)FastDFS分布式文件系统,主要用于存储用户头像。刚开始我们使用的单台服务器存储图片,但后来随着图片越来越多,同时通过rsy去备份很维护起来麻烦。通过多次文件系统相关开源产品的比较,我们选定了它,主要由于是FastDFS维护起来比较简单,并且很容易上手。

(八)服务器性能优化,经常发现服务器的单个cpu si(软中断)在35%,而其他cpu的si为0%,起初一直是以为程序的锁有问题,就一直找找,后面请运维同事帮忙,经过一段时间的研究发现是由于服务器较老,网卡不支持多CPU si,后来通过升级linux内核,同时购买新的网卡,优化后服务器终于可以支持在多cpu上的si,在此对运维同事表示感谢~~

(九)单台服务器支撑用户,上线初单台机器可以支撑6W+用户同时在线,优化后可支撑18W+,峰值可以支撑20W+,当前单台平均16W+,服务器配置Intel(R) Xeon(R) CPU 8核 + 16G内存

架构存在的缺点:

    前端服务器集群通讯还是依赖openfire本身的socket同步通讯机制,这样造成前端服务器之间的耦合性很强,本来是使打算引入RabbitMQ中间件的,对RabbitMQ也研究了一段时间,但由于种种原因,至今还未集成进去。接下来的目标是将其集成。

 

原文出处:http://my.oschina.net/pzh0819/blog/113946

posted @ 2013-03-16 09:31  Dylan.Zhang  阅读(444)  评论(1编辑  收藏  举报