工程项目大背景

和诸位听众大体如是说下具体内容情景，圣戈当斯区的小流程中对外开放许多音频话筒的卧室，让使用者步入卧室后能相互透过音频闲聊的形式展开交互。

这儿撷取呵呵有关的控制技术结构设计图。这款控制系统的具体内容来说结构设计是怎样能让两个使用者收到的音频通告到其他使用者下边。音频统计数据在应用流程同僚的处置下最后变为的是io报文允诺到了后端，后端只须要将那些报文传递给各相同的终端产品方可达至该台通告的效用。

Advance构架

最末期上架的这时候，为的是赶速率，加速纠错，因此单纯地选用了Advance构架去结构设计。紧密结合控制技术栈为 SpringBoot，WebSocket，MySQL控制技术。

圣戈当斯区一间音频卧室的同时在线人数并不会特别多，大概在15-50人的区间段内，控制系统核心代码是透过SpringBoot内部的WebSocket控制技术去展开统计数据的主动推送。

结构设计思路

整体的结构设计图比较单纯，基本就是一台服务器存储WebSocket连接，如下图所示：

使用者展开WebSocket初始化连接的这时候须要两个连接分配和存储的过程：

早期的存储是存放在了服务器本地的两个Map集合中。

当WebSocket展开连接的这时候就会往内存中写入一条统计数据信息，当镜像断开的这时候，就将内存中的统计数据移除。然后展开音频该台的这时候须要紧密结合WebSocket内部的该台发送功能展开通告

看似结构设计比较单纯，但是在后期业务变得庞大的这时候出现了瓶颈。因为随着参加音频活动使用者的增加，越来越多的WebSocketSession对象须要被存储到内存当中，这种有状态性的存储对于单机扩容不灵活。

结构设计缺陷

1.假设原先的服务器扩容到了A，B两台机器，A使用者在A机器下边建立了WebSocketSession，B使用者在B机器下边建立的WebSocketSession连接。此时如果A想要和B展开对话发送，须要先查找到具体内容WebSocketSession存放在哪台机器下边。

2.当使用者出现了网络异常，临时断开连接展开重连的这时候，也可能会出现1所说的问题。

集群构架

结构设计思路

一旦出现须要发送音频通告的这时候，发送一条该台的mq消息，每个机器都接收到消息后，触发自己的该台操作方可。

RocketMq的接入控制系统结构设计里面mq选用的是该台模式，这和我们通常使用的集群模式有一定的区别。

消息队列RocketMQ版是基于发布或订阅模型的消息控制系统。消费者，即消息的订阅方订阅关注的Topic，以获取并消费消息。由于消费者应用一般是分布式控制系统，以集群形式部署，因此消息队列RocketMQ版约定以下概念：

• 集群：使用相同Group ID的消费者属于同两个集群。同两个集群下的消费者消费逻辑必须完全一致（包括Tag的使用）。
• 集群消费：当使用集群消费模式时，消息队列RocketMQ版认为任意一条消息只须要被集群内的任意两个消费者处置方可。
• 该台消费：当使用该台消费模式时，消息队列RocketMQ版会将每条消息推送给集群内所有注册过的消费者，保证消息至少被每个消费者消费一次。

集群消费模式适用情景 适用于消费端集群化部署，每条消息只须要被处置一次的情景。此外，由于消费进度在服务端维护，可靠性更高。具体内容消费示例如下图所示。

注意事项

• 集群消费模式下，每一条消息都只会被分发到一台机器上处置。如果须要被集群下的每一台机器都处置，请使用该台模式。
• 集群消费模式下，不保证每一次失败重投的消息路由到同一台机器上。

该台消费模式适用情景 适用于消费端集群化部署，每条消息须要被集群下的每个消费者处置的情景。具体内容消费示例如下图所示。

注意事项

• 该台消费模式下不支持顺序消息。
• 该台消费模式下不支持重置消费位点。
• 每条消息都须要被相同订阅逻辑的多台机器处置。
• 消费进度在应用流程维护，出现重复消费的概率稍大于集群模式。
• 该台模式下，消息队列RocketMQ版保证每条消息至少被每台应用流程消费一次，但是并不会重投消费失败的消息，因此业务方须要关注消费失败的情况。
• 该台模式下，应用流程每一次重启都会从最新消息消费。应用流程在被停止期间发送至服务端的消息将会被自动跳过，请谨慎选择。
• 该台模式下，每条消息都会被大量的应用流程重复处置，因此推荐尽可能使用集群模式。
• 该台模式下服务端不维护消费进度，因此消息队列RocketMQ版控制台不支持消息堆积查询、消息堆积报警和订阅关系查询功能。

这儿面的应用情景须要对集群内部对每个消费者都对服务器内存中的socket连接展开session是否存在对判断，因此须要选用mq的该台模式。

关于mq部分的接入代码

Consumer模块的配置：

package