通知|B端产品设计：消息中心数据流逻辑( 二 )

消息来源请求消息通知时，会向消息中心发送请求，请求中一般包含这些信息：来源标识ID、请求时间、接收对象ID、消息内容（标题+正文）、提醒方式等。消息中心可以理解为包含待发送池、已发送池两大数据表：

文章插图
消息来源信息会先进入待发送池排队，形成一个消息队列，遵循先进先出规则。消息中心会根据每个消息中所携带的接收对象ID进行消息分发，即将该消息发送至对应用户的消息盒子中；同时根据提醒方式判断是否调用外部通知系统启动其他提醒方式。外部通知系统一般有固定的消息模板和提醒逻辑，消息中心需要将提醒对象和应用模板ID、对应模板参数同步给外部通知系统，由外部通知系统判断并触发消息模板进行通知。
消息进入消息盒子，则可被用户所查阅。此时可以根据状态将消息分为2类，即未读消息和已读消息。用户重点关注会放在未读消息上，所以优先给用户呈现新触达的未读信息。2类消息之间转换也很简单，用户点击打开即为已读；逆操作（即已读变为未读）则看具体系统定位和用户需要，一般不会设置逆操作。
至此，消息流逻辑就基本梳理完成。特别地，消息中心在设计时尽量不要融入复杂逻辑，如定时发送、重复发送等，应尽量保持逻辑简单以支持大量的消息分发和保持其作为系统底层机制的包容性；而定时发送、重复发送等逻辑应归类于业务层逻辑，应由业务侧决定。
例如，某个少儿美术在线教育公司内部CRM客户管理系统，其业务上有众多重复提醒和定时发送提醒的逻辑，如给销售人员重复提醒某个销售任务没有完成，每周二、四晚定时提醒销售人员准备跟进体验课，等等。这些逻辑均是设置在业务层，由业务层判断是否需要触发提醒，如需要则向消息中心发出请求，传入相关参数进入消息队列排队发送。这样能保证消息中心简单而高效运转，不会因为复杂逻辑产生不必要的消息流问题（如无法兼容多种重发逻辑等）；也把运维的重心都偏移在业务层，使得不同业务消息互不影响。
三、总结消息中心是B端产品系统的基本功能，一个包容性强且设计合理的消息中心，能更好地支撑系统与用户之间的对话，传达我们想要告诉用户的信息。消息中心设计之初需要先确认系统定位和功能定位，才能规范好数据范围，从而在实现产品功能价值和满足业务需求。消息流逻辑也需要尽量梳理清楚，使其成为系统基础服务，不要与业务逻辑强融合，才能保证其良好地包容性和避免返工。
以上是个人工作过程的一些经验总结和思考，仍有不足，正在努力。
本文由 @群子原创发布于人人都是产品经理，未经许可，禁止转载
题图来自Unsplash，基于 CC0 协议