基於Netty的聊天系統（一）通信原理篇

今天週六，正好順便把聊天系統的通信原理寫一下，原本是用XMPP+Openfire作了一個聊天，可是在作羣聊那塊須要去寫插件來主動向表裏變去寫數據，由於openfire外國人寫的，最初設計的羣聊是會議室那種形式，和咱們如今這種QQ羣聊仍是有差異的，改造起來比較麻煩，須要去通都源碼等等，openfire是基於mina來寫的，mina和netty又出自同一做者之手，那麼咱們就基於netty來寫一個吧，首先咱們來談一談通信的原理

1：通信原理

　　首先比方說A和B兩我的要進行聊天（這裏咱們先討論一對一這種聊天），那麼從登陸開始談起，既然有聊天功能因此，確定要有一個通信服務器，這個服務器只負責聊天，那麼例如查看別人信息了等等這些操做，咱們暫且稱之爲API服務器，只有聊天是經過scoket訪問通信服務器的，咱們在登陸的時候分爲兩個階段，第一個是鏈接階段，第二個是驗證階段，當登陸成功以後，而後A開始給B發消息，當服務器收到消息以後，找到對應的Handler而後來處理消息，其實在這裏咱們能夠直接解析消息發送給B，這樣是能夠的，可是當消息發送多的時候可能會發生消息丟失，因此咱們在這裏不採起這種方式，咱們首先把消息存到數據庫裏邊去，數據庫這裏咱們採用Redis數據庫，基於內存的，而後消息存到數據庫以後，而後咱們去看一下B的狀態，若是B在線就去發送一個通知給B，告訴B有消息了，B接收到消息以後，而後發送一個請求到服務器要求獲取消息，服務器接收到以後而後找對應的Handler來進行數據庫查詢，而後把查詢到的消息給B，而後B把收到消息的最大索引號發送會服務器端，而後服務器端根據最大消息的索引號來刪除對應數據庫裏邊的消息，通常聊天消息國家都會要求作存儲，方便監察，因此通常還會把所有聊天消息持久化起來，至此，一個簡單的發送-接受消息流程結束了。下邊我花了一個簡單的圖，文字比較多，圖好理解一些

至於Redis數據庫你們能夠先熟悉一下，尤爲是Redis的數據結構，在這裏咱們存儲單人聊天信息的時候採用的zset結構。下一篇，咱們將會談論一下通信協議的制定，歡迎你們持續關注。