疯狂创客圈 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 面试题 一网打尽
- 疯狂创客圈 【 博客园 总入口 】