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/