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/