1 数据操作需求
1.1 发消息
- 发送方新增已发消息 (用于消息判重)
- 接收方新增待收消息
- 根据发送方用户ID查询最近100条已发消息(用于消息判重)
- 消息持久化存储
1.2 收消息
- 根据接收方用户ID，最新已收消息ID，查询未收消息，支持分页查询，每次取1000条
1.3 删除数据
- 删除历史持久化存储数据
- 删除历史已发消息，接收消息
2 存储设计
基本存储结构
消息缓存存储使用redis，结构设计如下
每个用户关联redis中的一个List和一个Sorted Set(有序Set)：
- List中只保留用户最近发送的100条客户端消息ID(UUID，由客户端生成)
- Sorted Set中保留用户接收的消息，其中Set的score是服务端消息ID(long型，由服务端生成，递增)；Set的member是消息对象，包括发送方，消息内容，时间戳，消息ID等
发送消息操作
主要步骤如下：
- 步骤1 接收用户APP发送的消息报文，包括客户端消息ID
- 步骤2 保存用户已发客户端消息ID，保存到用户已发消息List中
- 步骤3 保存消息，保存到目标接收用户消息的Sorted Set中
- 步骤4 消息持久化存储数据库
- 步骤5 返回已发消息的服务端消息ID
实际情况中，有可能消息是重发消息，这时需要在步骤2之前查询用户已发消息List，与客户端消息ID比对判重
拉取消息操作
在APP发送消息接口，拉取未收消息接口都会拉取消息，主要步骤如下：
- 步骤1 用户APP基于本地已有最新服务端消息ID拉取消息
- 步骤2 服务器基于用户接收消息的Sorted Set分页查询未收消息
- 步骤3 返回消息
过期无效数据清理
用户已发消息List
限定List大小为100，超过100清除最旧的数据用户接收消息的Sorted Set
限定消息保存一个月，使用定时任务定时删除持久化数据库
限定消息保存一个月，使用定时任务定时删除
3 后续扩展
- 发送消息接口新增过滤器，用于过滤、监控、拒绝敏感消息
