【办理方案】Java 互联网项目中消息关照系统的计划与实现（上） ...

目录

• 媒介
  
• 一、需求分析
  
  
  
  • 1.1发送关照
    
  • 1.2撤回关照
    
  • 1.3关照消息数
    
  • 1.4关照消息列表
    
  
  
• 二、数据模型计划
  
  
  
  • 2.1概念模型
    
  • 2.2逻辑模型
    
  
  
• 三、关键流程计划
  
• 本篇小结
  

媒介

消息关照系统（notification-system）作为一个独立的微服务，完整地负责了 App 端内全部消息关照相干的后端功能实现。该系统既需要与文章系统、订单系统、会员系统等相干联，也需要和其它业务系统相干联，是一个偏底层的通用服务系统。
App 端内的消息关照类型常见有这几项：评论关照、点赞关照、收藏关照、订单关照、活动关照、个人中心相干关照等。该系统在可拓展性、高性能、较高可用性、数据一致性等方面有较高要求，最终目的是提升用户粘性、加强 App 与用户的互动、支撑焦点业务的发展。
文章的（上）篇将从需求分析、数据模型计划、关键流程计划这 3 部门来阐明，（下）篇将从技术选型、后端接口计划、关键逻辑实现这 3 部门来进行阐明。
一、需求分析

主要从发送关照、撤回关照、关照消息数、关照消息列表这 4 个子需求来展开。
1.1发送关照

• 该操作一般由业务系统发出关照，业务系统包括了 App 端和管理后台这两种；
  
• App 内的发起的关照一般由 App 用户即会员（member）自己来操作，如：在评论区回复评论，则其父评论的发布者需要收到评论回复关照；
  
• 管理后台发出的关照一般是管理员将某种类型（文本or图片等）的消息发送至 App 用户，如：某个活动的运营者在后台给 App 用户发送获奖关照。
  

1.2撤回关照

• 这是一个可选操作，一般也是由业务系统来操作，具相识由管理后台来完成，在 App 端一般较少有此类操作；
  
• 管理后台可以针对已经发送成功的关照进行单条撤回或者批量撤回，App 用户的关照列表和未读消息数将会随之变革。
  

1.3关照消息数

• 在App ”我的“模块，新增消息关照 icon，建议命名为”关照“；
  
• 当有新关照时表现 x 条新消息（红色数字），表现数字为该用户全部未读新消息数之和；
  
• 有新增一条未读消息时数目+1，撤回一条未读消息数目-1；
  
• 未读消息数需要与消息关照列表的未读消息数一致。
  

1.4关照消息列表

• 点击 “关照” icon后进入消息关照列表，根据关照类型分为不同的 tab 页；
  
• 列表展示该用户收到的全部消息关照，并按关照时间倒序展示；
  
• 新消息用红点标识，查看后退出的状态标记为已读，即红点会消失；
  
• 点击具体的消息，假如是链接，则支持跳转到对应地址；假如是图文，则支持查看；假如是文章，则支持跳转查看。
  

二、数据模型计划

该系统的数据模型分为两部门：数据库与缓存。其中对数据库的概念模型（E-R图）和逻辑模型（表计划）进行展开，对缓存的数据结构在关键逻辑实现章节会进一步阐明。
2.1概念模型

该系统目前计划为3张表，命名为：notification（关照纪录表）、notification_config（关照配置表）、external_sys（外部系统表）。
概念模型使用 E-R 图来表现，其中 notification 与 notification_config 为1对多的关系，且下面为了便于描述，只给出关键字段，其它字段可以作为冗余。

E-R图 1external_sys 为单独纪录外部业务系统的信息，用于业务系统调用关照系统接口时的身份校验：

E-R图 22.2逻辑模型

下面只给出关键字段的表计划，其它字段可以作为冗余：
notification 表计划

notification_cofig 表计划

external_sys 表计划

三、关键流程计划

下面是业务简单拆分后的泳道图，基于此图再做关键流程的计划。

业务流程泳道图下面通过一个简单的时序图（不含撤回）来进行关键流程的拆解：

业务流程时序图本篇小结

到这里Java 互联网项目中消息关照系统的计划与实现（上）篇就暂告一段落了，剩下的部门包括技术选型、接口计划、关键逻辑计划会在下篇来进行阐明。
系统计划的文章都是通过大量的实践与验证，最后才气下笔成文分享给大家的。假如文章有不足和错误，还请大家指正。或者你有其它想说的，也欢迎大家在评论区里交流！

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。