在群聊系统中，管理未读消息的两种常见方法是：记录每个用户与每条消息之间的已读/未读状态，以及记录用户的最后一次阅读消息ID。通过上述设计，可以有效地利用缓存提高未读消息功能的性能，同时通过WebSocket实时推送，确保用户界面上的未读消息数能够即时更新，提升用户体验。如果你的系统需要精确跟踪每条消息的阅读状态，或者需要支持复杂的消息阅读状态查询，可以选择记录每个用户与每条消息之间的已读/未读状态

但是自己这个项目最开始使用的shiro，而且权限对应的角色，菜单都已经写好了，所以主体采用的shiro。使用jwt 标识每个用户的身份。使用redis 存储每个用户的权限。JWT由3部分组成：标头(Header)、有效载荷(Payload)和签名(Signature)。在传输的时候，会将JWT的3部分分别进行Base64编码后用.进行连接形成最终传输的字符串。在这个realm里面有认证和授权的逻辑

在实现IM（即时通讯）聊天系统时，随着用户数量和消息量的增加，数据库的压力会逐渐增大。为了保证系统的可扩展性和性能，通常需要对聊天消息进行分库分表。分表策略按时间分表优点：可以根据时间轴快速查询，旧数据归档处理也较为方便。实现：每个时间周期（如每月、每周）创建一个新表，表名包含时间标识。按用户分表优点：可以将用户的消息分散到不同的表中，减少单表数据量，提高查询效率。实现：根据用户ID的hash值分

分布式事务是分布式系统中非常常见的问题。是非常必要钱常见的。实现的方式也是多种多样。今天这个视频主要来分享一下RocketMQ实现事务消息来保证分布式事务的一致性。不知道大家使用过这种方式没有。这种分布式事务的原理其实和本地消息表一样。

这个项目的聊天模块是由netty构建的websocket服务构建的，不满足分布式的情况。当项目需要更高并发的时候可拓展性不足。需要往分布式方向改进，这边文章主要写改写成分布式遇到了哪些困难以及目前的架构，后续会分享已经实现的功能和计划实现的功能。点个关注，后续持续分享。

自己之前分享了分布式websocket的视频有同学去fork项目了，自己启动一下更方便理解项目嘛。然后把项目启动需要的东西全部梳理出来。支持群聊单聊,表情包以及发送图片。支持消息可靠，消息防重，消息有序。同时基础架构有分布式权限，分布式唯一id，分布式websockt， 分布式事务等常见的分布式技术。已经分享的文章git项目地址 【IM即时通信系统（企聊聊）】点击可跳转分布式websocket即时

前言先介绍一下对称加密算法，在介绍一下加密流程，然后是介绍一下查询加密消息的策略。然后结合现有技术架构然后去选型。决定采用客户端解密。简而言之就是采用对称服务端加密。然后将加密内容存储到消息表的content字段。然后客户拉取content字段 然后解密。拉取到消息解密后进行展示。客户存储的时候进行加密。目前已经写的文章有。并且有对应视频版本。git项目地址 【IM即时通信系统（企聊聊）】点击可跳

上一篇中说了一下项目的构成，比较枯燥，一些基本构造方面，这一片呢，一定会更加枯燥。这一篇讲报文协议。后端嘛，不像前端花里胡哨，就是更有内涵一点。为什么这块需要着重说呢，因为聊天系统中需要设计一套保证消息可靠的机制。否则消息都不知道发过去了没有。需要通过报文去保证这些。这些都是需要去设计的。具体设计思路如下。

在日常开发中，主键id应用是非常广泛的，但是当涉及到分布式系统的时候，往往需要使用到分布式id，每一个服务里面一套生成规则的不易管理，容易引发冲突。我的IM聊天系统中使用分布式id来生成消息唯一键,为后面幂等做准备。后续做幂等可以采用数据库唯一主键来做，也可以使用Redis token 令牌来做，但是都是需要唯一的分布式id。以及涉及到分布分表等场景也是会使用到。这篇文章重点介绍美团Leaf 号段

id是自己器的，uri：负载均衡到在nacos中注册的服务。predicates里面放上前端请求到某服务需要加上的路径。filters重写请求进服务的路径。通用依赖里面引入了 服务注册于服务发现。然后里面将文件服务里面涉及到的接口签名复制出来；打开控制台默认账号密码都是 sentinel 登录后就可以进行简单的监控了。然后默认是懒加载的，你第一次请求的时候。我将按照 引入依赖 加配置 改代码三部曲