瘋狂創客圈 Java 分布式聊天室【 億級流量】實戰系列之 -25【 博客園 總入口 】
1.寫在前面
1.1 實戰Netty集群的理由
Java基礎練習中，一個重要的實戰練習是： java的聊天程序。基本上，每一個java工程師，都有寫過自己的聊天程序。
實現一個Java的分布式的聊天程序的分布式練習，同樣非常重要的是。有以下幾個方面的最重要作用：
1 體驗高並發的程序的開發：從研究承載千、萬QPS級的流量，拓展能夠承載百萬級、千萬級、億萬級流量
2 有分布式、高並發的實戰經驗，面試談薪水的時候，能提升不少
3 Netty集群的分布式原理，和大數據的分布式原理，elasticsearch 的分布式原理，和redis集群的分布式原理，和mongodb的分布式原理，很大程度上，都是想通。 Netty集群作為一個實戰開發， 是一個非常好的分布式基礎練習
4 更多的理由，請參考機械工業出版社的書籍 《Netty Zookeeper Redis 高並發實戰》
1.2 Netty 集群 實戰源碼
本文的代碼，來自於開源項目CrazyIm , 項目的地址為
https://gitee.com/crazymaker/crazy_tourist_circle__im.git源碼 目前已經完成了基本的通信，在不斷迭代中，不少的群友，通過瘋狂創客圈的QQ群，溝通迭代過程中的問題。
2 Netty 集群中，服務節點的注冊和發現
2.1 服務節點的注冊和發現
zookeeper作為注冊中心，每一個netty服務啟動的時候,把節點的信息比如ip地址+端口號注冊到zookeeper上。
具體的原理，請參見書籍《Netty Zookeeper Redis 高並發實戰》。
2.2 服務的發現
利用zk有一個監聽機制，就是針對某個節點進行監聽，一點這個節點發生了變化就會收到zk的通知。我們就是利用zk的這個watch來進行服務的上線和下線的通知，也就是我們的服務發現功能。
具體的原理，請參見書籍《Netty Zookeeper Redis 高並發實戰》。
3 負載均衡策略
3.1 負載均衡策略的基本思路
在我們解決了服務的注冊和發現問題之后，那么我們究竟提供給客戶端那台服務呢，這時候就需要我們做出選擇，為了讓客戶端能夠均勻的連接到我們的服務器上（比如有個100個客戶端，2台服務器，每台就分配50個），我們需要使用一個負載均衡的策略。
這里我們使用輪詢的方式來為每個請求的客戶端分配ip。具體的代碼實現如下：
具體的原理，請參見書籍《Netty Zookeeper Redis 高並發實戰》。
4 環境的啟動
4.1 啟動Zookeeper
Zookeeper的安裝和原理，以及開發的基礎知識，請參見書籍《Netty Zookeeper Redis 高並發實戰》。
啟動zookeeper的兩個節點，本來有三個，啟動二個即可
客戶端連接zookeeper集群。命令如下：
./zkCli.cmd -server localhost:2181
4.2 啟動Redis
Redis的安裝和原理，以及開發的基礎知識，請參見請參見書籍《Netty Zookeeper Redis 高並發實戰》。
redis 的客戶端界面。
5 Netty集群啟動
5.1 啟動WEBGate
使用一個WEBGate，作為負載均衡的服務器，具體的原理，請參見書籍《Netty Zookeeper Redis 高並發實戰》。
除了負載均衡，從WEBGate還可以從 zookeeper中刪除所有IM節點
連接為： http://localhost:8080/swagger-ui.html
swagger 的界面如下：
5.2 啟動第一個Netty節點
服務端的端口為7000
5.3 啟動第二個Netty節點
服務端的端口為7001，自動遞增的
5.4 啟動第一個客戶端
啟動后輸入登錄的信息
請輸入登錄信息，格式為：用戶名@密碼
z1@1
啟動客戶端后，並且登錄后，會自動連接一個netty節點, 這里為7001，第二個Netty服務節點。
5.5 啟動第二個客戶端
啟動后輸入登錄的信息
請輸入登錄信息，格式為：用戶名@密碼
z2@1
啟動客戶端后，並且登錄后，按照負載均衡的機制，會自動連接一個netty節點, 這里為7000，第一個Netty服務節點。
6 不同服務器直接進行IM通信
下面演示，不同的客戶端，通過各自的服務器節點，進行通信。
6.1 發送聊天消息
在第二個客戶端（用戶為z2），發送消息給第一個客戶端（用戶為z1），消息的格式為 ：“ 內容@用戶名”
請輸入聊天信息，格式為：內容@用戶名
hello@z1
請輸入聊天信息，格式為：內容@用戶名
helloworld@z1
6.2 遠程客戶端接收消息
通過Netty服務節點的轉發，第一個客戶端收到的消息如下：
收到消息 from uid:z2 -> hello
收到消息 from uid:z2 -> helloworld
7 總結
7.1 開發的難度
通過Netty+Zookeep+Redis的架構，整個Netty的集群，具備了服務節點的自動發現，節點之間的消息路由的能力。
說明一下，整個程序，還是比較復雜的，如果看不懂，建議不要捉急，慢慢來。
如果能從0到1的自己實現一版，開發的水平，也就不一般了。
全面的理論基礎，請參見 《Netty Zookeeper Redis 高並發實戰》 一書
7.2 Netty集群的最全理論基礎
《Netty Zookeeper Redis 高並發實戰》 一書，對Netty 集群的基本原理，進行了詳盡的介紹，大致的目錄如下：
12.1 【面試必備】如何支撐億級流量的高並發IM架構的理論基礎
12.1.1 億級流量的系統架構的開發實踐 338
12.1.2 高並發架構的技術選型 338
12.1.3 詳解IM消息的序列化協議選型 339
12.1.4 詳解長連接和短連接 339
12.2 分布式IM的命名服務的實踐案例 340
12.2.1 IM節點的POJO類 341
12.2.2 IM節點的ImWorker類 342
12.3 Worker集群的負載均衡之實踐案例 345
12.3.1 ImLoadBalance負載均衡器 346
12.3.2 與WebGate的整合 348
12.4 即時通信消息的路由和轉發的實踐案例 349
12.4.1 IM路由器WorkerRouter 349
12.4.2 IM轉發器WorkerReSender 352
12.5 Feign短連接RESTful調用 354
12.5.1 短連接API的接口准備 355
12.5.2 聲明遠程接口的本地代理 355
12.5.3 遠程API的本地調用 356
12.6 分布式的在線用戶統計的實踐案例 358
12.6.1 Curator的分布式計數器 358
12.6.2 用戶上線和下線的統計 360
瘋狂創客圈 Java 死磕系列
- Java (Netty) 聊天程序【 億級流量】實戰 開源項目實戰
- Netty 源碼、原理、JAVA NIO 原理
- Java 面試題 一網打盡
- 瘋狂創客圈 【 博客園 總入口 】