与Redis的第一次“亲密接触”--使用Redis+SSM搭建简易聊天室

初衷

最近在写一个项目的时候，需要编写一个私信系统，因为之前没有相关的经验，所以没法直接在项目上动工。经过思索后，决定选用Redis作为技术支撑来研究如何实现，因此想到先做一个聊天室来练练手。

完成图

用户聊天前需要输入用户名。

聊天界面将自己发的和别人发的区分开来。

实现思路

群聊和私信系统是有些不同的。

对于私信系统来说，通信是发生在两个用户之间，因此势必要为每对用户，甚至是每个用户创建一个相应的你选择用来存储信息Message的数据结构(List或其他的)。

而群聊比私信少一点，因为所有的用户可以共享一个消息池(Message)。

起初，我考虑使用Redis的发布订阅来做，但后来由于种种原因放弃了。因此最后选择使用Redis的List来做。

开发的难点

在我选定了使用List做存储这个消息池的数据结构以后，我就开始思考具体的实现过程，后来发现也是有许多小坑的。

如何确保用户不漏掉其他用户发的信息

在系统运行的过程中，List中的内容是不断变化的。比如说我当前获取到了最新的消息，那么如果其他用户互动的很热烈，我是否会因为一些原因错过一些消息呢，显然，如果设计的不当，一定会错过，这想来是无法接受的🤷‍♀️🤷‍♀️。

思考之后，我考虑为每一条消息设置一个id，用户在前端会记录这个id的值，下次再次获取信息时，就可以根据这个id来截取最新的信息（具体的设计流程可以有很多种）。当然，每次请求都获取全部的信息然后渲染也是一种方法，这里我没有使用这种简单粗暴的方法。

如何区分获取的信息中自己发的信息和别人发的信息

在最初我设计聊天室的页面的时候，我是设计成自己的和他人发的分开显示的，类似微信，QQ那种，但在实际编写后端代码 的时候发现这种设计为自己添加了一些麻烦。

这意味着前端必须对收到的信息进行区分，辨认。因为我为每条信息添加了一个uid(用户的id)。要注意的是，在这里，这个id我是在前端生成的，然后每次发送信息时要带上，然后在获取信息进行渲染时，会通过这个本地js中的uid和信息中的UID进行判断， 如果一致，则为自己的信息。

你一定想到了，这种在前端生成id的设计不会保留用户发送的信息，说的更正确一点，应该是，不会保留用户与用户信息的关系。当用户离开或者刷新页面时，一切都会重新开始，他将会获得一个新的id！

本项目已在Gitee(码云)上开源，地址为 chatroom,如果对你有帮助可以点个star噢，有问题或这个疑问可以提出来大家交流哦。

希望10月，11月一切顺利！😁

折腾了一天， 终于把它部署到阿里云上了，感兴趣的朋友可以去玩呀gakki😊**