当前位置: 首页 > news >正文

深入解析:站内信设计分析

文章摘要

本文详细阐述了站内信系统的设计与实现方案。首先分析了当前依赖第三方推送服务(如Jpush和短信)的高成本与功能局限困难,提出了构建自主站内信架构的必要性。系统设计包含前后端功能模块:前端支撑消息接收、分类查看和删除;后端给予消息创建、审核和发布功能。技术选型采用MongoDB非关系型数据库存储消息数据,设计了发送和接收两张核心数据表。文章详细描述了包括消息创建、审核、发布、删除等业务流程,并针对运营类消息和架构类消息分别制定了处理逻辑。系统支持多平台(APP端、PC端、商户端)消息推送,旨在降低运营成本,减少外部依赖,提高用户粘性。

一、背景

  1. 运营成本:本计划中目前进行通知的有Jpush和短信功能。这些都是第三方使用的。而高频次的发送信息,是要求高额的成本支出的。
  2. 功能局限:例如短信功能运营商短信只能提供单一的固定短信模板,每一条的短信模板都必须经过运营商相关部门的审核,缺乏良好的灵活性和定制性可能性,对业务形态多样的产品尤为不利。
  3. 合理的,主次分明也有助于业务的清晰明了。就是迭代规划:产品规划过程中,周期性迭代升级是一种良好产品运营模式下的宠儿。初期产品重点关注基础和核心功能,相对结构复杂且优先级不高的站内信功能,适当地下放至后期的迭代完,过程上肯定
  4. 业务驱动:降低运营成本固然主要,而减少产品对外部服务的依赖性也不容小觑,逐步完善产品内部功能,增强用户的产品粘性,迫使用户自然延长产品的运用/停留时间。站内信息的发送和接收,形成一个完善的产品正向反馈闭环。

二、产品分析:

2.1站内信是什么:

百度百科:

站内信,是为方便会员商务信件往来而设的服务特性,类似于邮箱,主要由收件箱、发件箱、草稿箱和垃圾箱四部分组成,但该功能仅对网站的注册会员开放。

“站内信”不同于电子邮件,电子邮件通过专门的邮件服务器发送、保存。而“站内信”是架构内的消息,其实就是通过数据库插入记录来完成的。

“站内信”有两个基本功能。一:点到点的消息传送。用户给用户发送站内信,管理员给用户发送站内信。二:点到面的消息传送。管理员给用户(指定满足某一条件的用户群)群发消息。

本项目中考虑到的层面有:

管理员给某一个用户发送消息。

管理员给一群用户(满足一定条件的)发送消息。

管理员给所有用户发送消息。

2.2站内信启用范围:整体分为平台类型。

平台范围:后台,APP端,商户端

2.3 业务流程:

运营人员可在资管后台创建站内信,站内信选择用户所属平台,例如融信。即决定了之后站内信的用户所属平台。选择用户种类群体即选择了之后哪些用户会收到站内信的信息。选择是否人工发送即决定了站内信的发布触发者是谁。例如选择人工发送,则需运营人员进行最后的发布。若选择了不是人工发送,则需要在作业中或业务逻辑代码中进行执行发布消息。

2.4 APP端功能:

1.接收消息:借助站内消息通知,及时了解某个任务/行为的进程,是一种产品设计策略性的方针。

2. 打开方式:消息的呈现形式很大程度决定了——用户是否愿意查阅推送的系统消息

消息列表:站内消息列表查看详情:消息通知详情

3. 功能设计:通知、查看、删除(单一/批量)、详情,简单的执行和思路让用户自主式地优化信息,使其更加清晰地呈现在用户面前。基础功能决定产品上层结构,重视前期的基础建设,为后期完善产品细节和逻辑将会有莫大的益处。

4. 消息类别:以消息状态或消息类型划分类别,两种维度的信息归类各有权衡利弊与得失的必要。

消息状态:已阅读、未阅读(默认全部)消息类型:系统消息 ,运营类消息。

一款优秀产品的开始。就是消息类型可能存在扩容,而消息的状态相对固定/稳定,包括:已阅读、未阅读,完整诠释了事物的两个方面。良好的产品必定一开始就为后期的扩展预留了足够的空间,这也

2.5 后端功能:

站内信本质上:是某一特定场景之下触发的某一条通知性消息。大致分为:

系统消息:主要是行为信息流的关键节点类通知;

运营类消息:自定义手动发送运营消息,主要是运营人员依据实际的业务需求手动推送的指向性信息

系统消息:由系统业务流触发不同场景下的消息提醒,极具过程性,将每一个结果融于有意义的过程中。

运营类消息:由运营人员在后台管理直接投入到前台内容的生产和管理。

三、消息推送方式:

推送到PC端,APP端,商户端

四、技术选型:

4.1 数据库的选择:

考虑消息内容的容量大,与业务流程的耦合性。建议选择非关系型数据库:MongoDB 。它本身面向文档存储(类JSON内容模式简单而强大),Auto- Sharding自动分片支持云级扩展性,复制和故障切换帮助。目前不支持事务,开发时需要注意。

发送消息表

字段

类型

描述

是否必填

messageId

varchar(36)

消息ID uuid

自动生成

fromUserId

bigint

发送者ID

messageName

varchar(50)

消息名称

messageSummary

http://www.hskmm.com/?act=detail&tid=30872

相关文章:

  • 实验报告2
  • Agentic RAG对比传统RAG的优势
  • 实验二
  • linux系统查看磁盘过程
  • 2025-10-14 闲话
  • ftp多用户多目录配置
  • 芋道框架怎么样
  • 神级掩护软件!老板路过我电脑在“系统更新中”
  • 超真实“电脑崩溃模拟器”:蓝屏、重启、FBI警告一应俱全!
  • (20)ASP.NET Core2.2 EF创建模型(必需属性和可选属性、最大长度、并发标记、阴影属性) - 指南
  • (在构造函数中)调用super(props)的目的是什么?
  • 温故知新,机器人进化论,机器人分类与全球格局
  • Zemax:初学者的混合模式 - 指南
  • 西门子博图软件TIA V18使用PLCSIM Advanced V5.0进行仿真与其他程序进行通讯
  • MyEclipse 2017/2018 安装与破解 图文教程
  • 面向对象初级
  • 【文章目录】
  • Excel DDE 教學:即時資料交換的詳細指南 - 指南
  • 子网掩码基础知识
  • AI元人文构想基础理论体系研究
  • 微信机器人框架
  • 数论学习笔记
  • 实用指南:JavaWeb 课堂笔记 —— 24 AOP 面向切面编程
  • 微信机器人接口开发
  • 2025年7款与Jira数据同步的实用国产优秀项目管理软件对比
  • ESP8266 PMW使用的简单介绍
  • DevEco Testing全面解析:HarmonyOS测试框架与实战指南 - 教程
  • 本周第一单 多晶硅
  • 加州新规要求AI必须表明其AI身份
  • 详细介绍:【rabbitmq 高级特性】全面详解RabbitMQ TTL (Time To Live)