报文设计
报文的结构我是用一个SimpleTogether，里面有两个属性，type，和一个抽象类MessageData data，这个data目前里为空，主要起一个约束规范的作用。
public class SimpleTogetherMessage {// 操作类型private Integer type;// 信息private MessageData data;
}
问题处理及系统完善
但其实这个系统并不完善，存在着诸多问题，比如房间问题，举例，当我创建一个A房间时并复制了A房间的链接，有人邀请我进入B房间，前端的房间变量变成B，但是A房间并未消失，允许别人进入，要做的就是在invite逻辑中删除该房间
invite逻辑增加的代码：
// 删除痕迹，获取原来的房间号，然后直接删除房间String originalRoomId = redisTemplate.opsForValue().get(TOGETHER_USER_KEY + inviteeAccount);redisTemplate.opsForHash().delete(TOGETHER_ROOM_KEY + originalRoomId);redisTemplate.opsForValue().set(TOGETHER_USER_KEY + inviteeAccount, roomId);// 这里对邀请改成失效状态LambdaUpdateWrapper<TogetherInvitePo> updateWrapper = new LambdaUpdateWrapper<>();updateWrapper.set(TogetherInvitePo::getStatus, 3).eq(TogetherInvitePo::getRoomId, TOGETHER_ROOM_KEY + roomId);update(updateWrapper);
系统新引入了一个TOGETHER_USER_KEY键来标识使用功能的用户及对应的房间号，这个key，value值在onOpen，createRoom和invite逻辑中进行赋值，然后在前端增添一个接口逻辑就是当我前端RoomId为null的时候就查询一下redis里的键并拿出来，直接加到createRoom逻辑里即可。
接口逻辑
主要就是对主体的ws逻辑做辅助和条件建立，有生成邀请链接接口，接收邀请接口，创建房间接口，获取房间信息接口等等。房间没有对其进行mysql的持久化，因为房间其属性，较为临时，而且重要性也不是很强，最坏情况，redis进行宕机，数据丢失，直接重新创建一个房间即可，房间只相当于一个容器，不存储什么重要信息。
所有的sql操作都只对一个表操作，这个表就是邀请信息表：
逻辑是这样的，当我调用生成邀请链接接口时，会创建一条邀请信息，room_id为主键，status为1，以后的这个房间的每次创建邀请信息都会在这条信息上进行更新过期时间，music_id；当发生接收邀请操作的时候，就会去检查过期时间，检查status等等，然后设置status；渲染邀请页面时（如下图1所示），根据musicId去渲染页面；
图1
