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 后续扩展

• 发送消息接口新增过滤器，用于过滤、监控、拒绝敏感消息