浅谈分布式环境下WebSocket音讯同享问题
技术分析
咱们在开发时会遇到需求运用即时通讯的场景，当然，完成方法许多，Socket、MQTT、Netty….等等。
具体用哪种就在于事务的需求了，去挑选合理的方法完成。
今天小扼要聊的场景便是分布式环境下，WebSocket的音讯同享问题。
分布式环境下，事务方面往往最需求处理的是数据同步同享这类问题。
此刻出现了一个场景，后端存在一个分布式服务，我需求两个服务都能收到WebSocket的音讯，怎么去完成？
或者说，服务端项目存在多个负载均衡实例，实例均在不同的实例上，这样当一次恳求负载到A服务器实例时，socket的session在A服务器线程上，第2次恳求负载到另一台B服务器的实例，此刻B服务器并不存在A服务器的Session(即Socket的会话音讯)。
考虑处理
思路一(失利)
咱们首要考虑，改怎么处理这个问题呢？要完成同步，依据上面的需求，咱们能够直接定位到Socket的Session不能同享问题，只需能够同享会话目标，那就能够处理当时问题。
没错，小简也是这样想的，可是，实际上是错误的，请看下文。
咱们首要联想到，分布式下，咱们的分布式锁、分布式状况信息，都是能够经过Redis去完成一个同享的，那咱们直接给Socket的Session经过Redis同享不就能够。
思路确实是对的，可是运用
Redis同享目标是有条件的，要去完成Serializable接口，才能够被序列化。
咱们查看源码就会发现，Socket的Session是不能被序列化的，那天然不能去运用Redis来完成Session目标的同享了。
为什么HttpSession能够运用Redis同享？
/**
* @author JanYork
* @date 2023/3/14 11:36
*/
org.apache.catalina.session.StandardManager
org.apache.catalina.session.PersistentManager
WEB的中的HttpSession主要是经过上面的两个管理器完成序列化的。
StandardManager是Tomcat默许运用的，在web运用程序封闭时，对内存中的所有HttpSession目标进行耐久化，把他们保存到文件系统中。
默许的存储文件为：<tomcat装置目录>/work/Catalina/<主机名>/<运用程序名>/sessions.ser
PersistentManager比StandardManager更为灵活，只需某个设备供给了完成org.apache.catalina.Store接口的驱动类，PersistentManager就能够将HttpSession目标保存到该设备。
所以spring-session-redis处理分布场景下的session同享便是将session序列化到redis中，运用filter加装饰器形式处理分布式场景httpsession享问题。
注：此段参阅自程序员DD大佬的文章。
思路二
已然不能同享目标，那咱们同享音讯不就能够，咱们的目的是要其他实例也能够收到Socket的音讯，那咱们便是个1对n的音讯模型，一对多音讯那就简略了。
哪些方法？
首要咱们会第一时间想到，MQ，也便是音讯行列中间件。
其次咱们也能够运用Redis的发布订阅功用完成。
MQ
运用MQ去完成一对多音讯，信任也不需求我多说，MQ天然的播送、发布订阅、点对点、路由这些音讯形式能够很方便的处理这个问题。
Redis
Redis完成有大佬已经写过了，请参阅：
怎么运用
Redis处理WebSocket分布式场景下的Session同享问题: cloud.tencent.com/developer/a…
尾述
说浅谈就浅谈，文章就这么短（暗暗窃喜：又水一篇，嘿嘿），下篇再见。
