json xmpp

https://github.com/lamfire/jspp

http://blog.csdn.net/nomousewch/article/category/823687

http://my.oschina.net/pzh0819/blog/113946

http://www.cnblogs.com/xiazh/archive/2011/04/02/2003852.html

11年进入公司就开始研究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也研究了一段时间，但由于种种原因，至今还未集成进去。接下来的目标是将其集成。

注：前端集群目前我们采用消息中间件RabbitMQ，前端openfire只做数据接收，所以的业务通过mq分发到后端处理。

同时各位有兴趣的可以了解下我们的产品:http://www.wecloud.io/