快乐聊天室

核心功能：前端（多个）发送消息，通过后端想办法把消息广播出来。

设计方案：

轮询方案：

1.由客户端发起的，服务器被动响应----请求-响应模型（常见）HTTP协议

2.客户端发起订阅，服务器主动通知----订阅-通知模型

使用请求-响应模型模拟订阅-通知模型？（HTTP协议背景下，如果做到客户端及时收取服务器的新消息）

轮询模式的方案：客户端定期的（按照固定频率/随机频率/其他频率）去服务器询问

优点：方案实现简单，不需要长期保持信道

缺点：如果通知的比率不高，会产生很多性能浪费，有时延

长轮询与短轮询

客户端请求新消息时，当服务器没有新消息时，如果是短轮询，直接返回没有新消息，让客户端下次继续轮询；如果是长轮询，会阻塞，直到有新消息产生才返回新消息。

长轮询相比较短轮询，有以下优点：实时性，减少很多无效请求。

WebSocket方案：

客户端主动发起一次，一旦建立连接，之后，会产生一个全双工（可双向通信，互不功能、干扰）的信道。

WebSocket初次承载，也就是初次连接，是以HTTP协议作为承载的，客户端首次发起请求的时候，只要服务器支持WebSocket，就可以处理该请求方法；然后建立一个信道，信道双方都可以主动发起消息，都可以被动接收消息。

服务端的websocket提供的连接点被称为endpoint，定义Endpoint：

1.定义类

2.不需要实现什么接口或者继承什么类

3.通过@ServerEndpoint注解修饰类

websocket的处理，背后也是事件驱动的影子，可能事件：

open：当有客户端连接成功时

close：当对方关闭连接时

error：当通信过程中发生错误时

message：当收到对方消息时

对应四个注解：@OnOpen，@OnClose，@OnError，@OnMessage

线程封装出来的定时器（Timer），就类似js上的setInterval的用法。

聊天室-后端逻辑：

聊天场景（系统的所有人都在一个群里），一个人发送的消息，在线的所有人都能收到（核心）；针对离线的人（注册过但暂时没有登录），等他再次登录时，补发没有看到的历史消息；首次注册的人，看不到之前的消息。

我们需要一个在线用户管理机制（记录所有当前在线用户信息），同时可以动态的，正确的维护该信息。

一个人发送消息的数据流转流程：

1. 前端获取用户要发布的消息；2.通过websocket，将消息推送给服务器；3.后端遍历所有当前在线用户，通过websocket挨个发送消息

聊天室主要结构：

 WebSocket中事件驱动处理用户上线，用户下线，发送消息三种不同事件，当触发了onOpen时可以认为是用户上线了，当触发了onClose时可以认为是用户下线了，当触发了onMessage时认为是有用户发送消息了。