音信系统规划与贯彻

文/JC_Huang(简书作者)
原来的小说链接:http://www.jianshu.com/p/f4d7827821f1
小说权归小编全体,转发请联系笔者得到授权,并标注“简书小编”。

文/JC_Huang(简书笔者)
原稿链接:http://www.jianshu.com/p/f4d7827821f1
文章权归作者全数,转发请联系小编得到授权,并标明“简书作者”。

产品分析

第叁大家来看一下市集上有关音讯的实现是怎么样的。

产品分析

首先我们来看一下市集上有关新闻的兑现是哪些的。

简书

简书的音讯系统重点分了三种

  • 简信
  • 提醒

简信
简信的质量其实跟私信是一模一样的,是用户发送给用户的一则音讯,有现实的音讯内容。

图片 1

简书简信

提醒
而提示,则是系统一发布送的一则音信,其文案格式是稳定的,并且对特别指标一般装有超链接。

图片 2

简书指示

简书

简书的音讯系统首要性分了三种

  • 简信
  • 提醒

简信
简信的性质其实跟私信是相同的,是用户发送给用户的一则消息,有切实的消息内容。

图片 3

简书简信

提醒
而唤醒,则是系统一发布送的一则新闻,其文案格式是一直的,并且对特出对象一般装有超链接。

图片 4

简书提醒

知乎

果壳网跟简书一样,首要分了二种:

  • 私信
  • 消息

私信
跟简书一样,使用户发送给用户的一则新闻,也足以是管理员发送给用户的新闻。

图片 5

今日头条私信

消息
今日头条的消息比简书的提醒有过之而无不如,搜狐会对多条形似的新闻实行聚会,以达到减轻用户阅读压力的体验。

图片 6

网易音信

知乎

和讯跟简书一样,首要分了两种:

  • 私信
  • 消息

私信
跟简书一样,使用户发送给用户的一则音信,也足以是管理员发送给用户的新闻。

图片 7

知乎私信

消息
乐乎的音讯比简书的唤起有过之而无不如,天涯论坛会对多条形似的音信进行聚会,以高达减轻用户阅读压力的心得。

图片 8

新浪音讯

音信的三种分类

经过三种产品的简要分析,得出他们的音讯有几种分类,在那基础上,大家再加上一种:布告。
公告的第3品质是系统一发布送一则含有具体内容的新闻,站内全数用户都能读取到那条新闻。
之所以,新闻有三种分类:

  1. 公告 Announce
  2. 提醒 Remind
  3. 私信 Message

新闻的三种分类

通过二种产品的大约分析,得出他们的新闻有二种分类,在这基础上,我们再添加一种:公告。
公告的重点品质是系统一发布送一则含有具体内容的音信,站内全体用户都能读取到那条音信。
故而,音讯有二种分类:

  1. 公告 Announce
  2. 提醒 Remind
  3. 私信 Message

唤醒的言语分析

作者们从简书取一组提示样本:

  • 3dbe1bd90774 关心了您
  • magicdawn 喜欢了你的稿子 《单点登录的三种实现情势》
  • 无良程序 喜欢了你的篇章 《基于RESTful API 怎么统一筹划用户权限决定?》
  • alexcc4 喜欢了您的稿子 《在Nodejs中落到实处单元测试》
  • 你在《基于RESTful API 怎么设计用户权限控制?》中吸收一条 cnlinjie
    的评头品足
  • 你的小说《Session原理》已被投入专题 《ios开发》

解析句子结构,提示的剧情唯有正是

「什么人对同样属于哪个人的东西做了什么样操作」
「someone do something in someone’s something」

someone = 提示的触发者,也许发送者,标记为sender
do something =
提示的动作,评论、喜欢、关怀都属于2个动作,标记为action
something = 提示的动作作用对象,那就具体到是哪一篇小说,标记为target
someone’s = 提示的动作成效对象的主人,标记为targetOwner

那就知道了,sender和targetOwner正是网站的用户,而target是切实可行到哪一篇小说,假诺提醒的指标不仅局限于文章,还有别的的话,就必要增加一项targetType,来标记指标是小说依旧其余的怎样。而action,则是固定的,整个网站会触发提示的动作只怕就只有那几样:评论、喜欢、关心…..(大概其它事情须要提示的动作)

提醒的言语分析

大家从简书取一组提示样本:

  • 3dbe1bd90774 关心了你
  • magicdawn 喜欢了您的稿子 《单点登录的两种达成格局》
  • 无良程序 喜欢了您的小说 《基于RESTful API 怎么规划用户权限决定?》
  • alexcc4 喜欢了你的篇章 《在Nodejs中贯彻单元测试》
  • 你在《基于RESTful API 怎么统一筹划用户权限控制?》中接受一条 cnlinjie
    的评论
  • 你的稿子《Session原理》已被投入专题 《ios开发》

剖析句子结构,提示的内容仅仅就是

「什么人对同一属于哪个人的东西做了哪些操作」
「someone do something in someone’s something」

someone = 提示的触发者,或许发送者,标记为sender
do something =
提醒的动作,评论、喜欢、关切都属于四个动作,标记为action
something = 提醒的动作功用对象,那就现实到是哪一篇作品,标记为target
someone’s = 提示的动作功能对象的持有者,标记为targetOwner

那就驾驭了,sender和targetOwner正是网站的用户,而target是现实性到哪一篇作品,假设提示的指标不仅局限于小说,还有任何的话,就需求追加一项targetType,来标记目的是作品仍然别的的如何。而action,则是定点的,整个网站会接触提示的动作大概就只有那几样:评论、喜欢、关心…..(可能其余工作须要提示的动作)

音信的二种获得方式

  • 推 Push
  • 拉 Pull

以微博为例
推的可比宽泛,须要针对某二个标题维护着一张关心者的列表,每当触发这些难题推送的规则时(例如有人回答难点),就把这一个公告发送给每种关怀者。

拉的相对劳累一点,便是推的反向,例如每一种用户都有一张关心难题的列表,每当用户上线的时候,对各样标题展开轮询,当难题的事件列表出现了比笔者原本时间戳大的音信就开始展览拉取。

而大家则按照音信的两样分类采纳分化的获取格局
通报和提示,适合选择拉取的点子,音讯爆发之后,会存在音讯表中,用户在某一一定的时光依据本身关怀难题的表举行音讯的拉取,然后添加到本人的音讯队列中,

消息,适合选取推的方法,在发送者建立一条音信之后,同时钦命接收者,把新闻添加到接收者的音讯队列中。

消息的三种获得形式

  • 推 Push
  • 拉 Pull

以博客园为例
推的相比普遍,必要针对某二个题材维护着一张关心者的列表,每当触发这些标题推送的条件时(例如有人回复难点),就把那些文告发送给每一个关心者。

拉的相对艰巨一点,便是推的反向,例如各样用户都有一张关心难题的列表,每当用户上线的时候,对各类难点开展轮询,当难题的轩然大波列表出现了比自身原本时间戳大的音讯就展开拉取。

而小编辈则基于消息的不及分类选择不一样的得到格局
通报和唤醒,适合利用拉取的方法,音讯发生之后,会设有消息表中,用户在某一特定的时日遵照自身关切难题的表展开消息的拉取,然后添加到本身的新闻队列中,

音信,适合利用推的艺术,在发送者建立一条新闻之后,同时钦赐接收者,把新闻添加到接收者的音讯队列中。

订阅

依据提示使用拉取的办法,必要维护三个关心某一事物的列表。
那种表现,大家誉为:「订阅」Subscribe

一则订阅有以下多少个焦点属性

  • 订阅的目标 target
  • 订阅的对象项目 targetType
  • 订阅的动作 action

譬如说笔者颁发了一篇作品,那么笔者会订阅小说《XXX》的评论动作,所以作品《XXX》每被人评价了,就须要发送一则提示告知自个儿。

订阅的条条框框还足以扩大
本身欢悦了一篇小说,和本身发表了一篇小说,订阅的动作只怕不均等。
喜欢了一篇小说,笔者盼望笔者订阅那篇小说更新、评论的动作。
而公布了一篇作品,笔者梦想笔者只是订阅那篇小说的评论和介绍动作。

此时就要求多3个参数:subscribReason
今非昔比的subscribReason,对应着三个动作数组,
subscribReason = 喜欢,对应着 actions = [更新,评论]
subscribReason = 发布,对应着 actions = [评论]

订阅的条条框框还还是能扩展
用户大概会有2个谈得来的订阅设置,比如对于拥有的欢欣的动作,笔者都不期待接受。
诸如Knewone的唤醒设置

图片 9

Knewone提醒设置

所以大家须求再维护3个表:SubscriptionConfig,来存放在用户的唤起设置。
还要,当用户并未提示装置的时候,能够使用系统提供的一套暗中认可设置:defaultSubscriptionConfig

订阅

听新闻说提醒使用拉取的格局,须要保证叁个爱护某一东西的列表。
那种作为,大家誉为:「订阅」Subscribe

一则订阅有以下八个着力属性

  • 订阅的靶子 target
  • 订阅的目的项目 targetType
  • 订阅的动作 action

例如自身公布了一篇小说,那么笔者会订阅文章《XXX》的评说动作,所以小说《XXX》每被人品头论足了,就供给发送一则提醒告知本身。

订阅的规则还是能够扩张
自身爱好了一篇文章,和自个儿揭橥了一篇小说,订阅的动作也许不一致等。
喜好了一篇小说,作者期待作者订阅那篇文章更新、评论的动作。
而公布了一篇作品,作者期望自个儿只是订阅那篇小说的评头品足动作。

这时候就需求多一个参数:subscribReason
不等的subscribReason,对应着三个动作数组,
subscribReason = 喜欢,对应着 actions = [更新,评论]
subscribReason = 发布,对应着 actions = [评论]

订阅的平整还还是可以扩充
用户或者会有三个要好的订阅设置,比如对于拥有的欣赏的动作,笔者都不愿意接受。
诸如Knewone的提醒装置

图片 10

Knewone提示设置

由此大家须要再维护五个表:SubscriptionConfig,来存放在用户的晋升装置。
同时,当用户没有提醒设置的时候,能够采取系统提供的一套暗中同意设置:defaultSubscriptionConfig

聚合

比方本人公布了一篇小说《XXX》,在自家不在线的时候,被评价了11遍,当自家一上线的时候,应该是收到十条音讯类似于:「什么人什么人哪个人评价了您的篇章《XXX》」?
或然应该吸收接纳一条新闻:「甲、乙、丙、丁…评论了您的篇章《XXX》」?

微博在集合上做的很理想,要清楚她们要促成这些照旧挺有技术的:
果壳网的新闻机制,在技术上怎样统一筹划与规划?
网站的消息(布告)系统一般是怎么着兑现的?

至于这一部分职能,我们还没有实际的完结方式,权且也惊慌失措讲得更其详实。⊙﹏⊙

聚合

借使自个儿发布了一篇作品《XXX》,在自个儿不在线的时候,被评价了十二回,当自身一上线的时候,应该是收取十条消息类似于:「何人什么人哪个人评价了您的篇章《XXX》」?
抑或应当吸收接纳一条音讯:「甲、乙、丙、丁…评论了您的文章《XXX》」?

腾讯网在集合上做的很了不起,要知道她们要促成那几个照旧挺有技术的:
乐乎的音讯机制,在技术上如何统一筹划与设计?
网站的音信(通告)系统一般是什么贯彻的?

至于那有些意义,大家还尚无具体的贯彻格局,近日也心中无数讲得尤为详实。⊙﹏⊙

八个实体

由此上边的分析,大致知道做这么些音讯系统,必要怎么样实体类:

  1. 用户消息队列 UserNotify
  2. 用户 User
  3. 订阅 Subscription
  4. 订阅设置 SubscriptionConfig
  5. 消息 Notify
    • 通告 Announce
    • 提醒 Remind
    • 信息 Message

七个实体

通过上边的辨析,差不离知道做那些新闻系统,要求什么实体类:

  1. 用户新闻队列 UserNotify
  2. 用户 User
  3. 订阅 Subscription
  4. 订阅设置 SubscriptionConfig
  5. 消息 Notify
    • 通告 Announce
    • 提醒 Remind
    • 信息 Message

表现分解

说了这么多,整理一下方方面面音讯流程的一对行事:

  • 系统可能管理人,创制消息
    • createNotify (make announce | remind | message)
  • 用户,订阅消息,撤废订阅
    • subscribe, cancelSubscription
  • 用户管理订阅设置
    • getSubscriptionConfig, updateSubscriptionConfig
  • 用户,拉取新闻
    • pullNotify (pull announce | remind | message | all)
  • 用户,查询音信队列
    • getUserNotify(get announce | remind | message | all)
  • 用户阅读新闻
    • read

 

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

表现分解

说了如此多,整理一下整整新闻流程的一些表现:

  • 系统或然管理人,创立消息
    • createNotify (make announce | remind | message)
  • 用户,订阅音讯,打消订阅
    • subscribe, cancelSubscription
  • 用户管理订阅设置
    • getSubscriptionConfig, updateSubscriptionConfig
  • 用户,拉取音讯
    • pullNotify (pull announce | remind | message | all)
  • 用户,查询消息队列
    • getUserNotify(get announce | remind | message | all)
  • 用户阅读新闻
    • read

 

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

模型设计

模型设计

Notify

id            : {type: 'integer', primaryKey: true},        // 主键
content     : {type: 'text'},    // 消息的内容
type        : {type: 'integer', required: true, enum: [1, 2, 3]},  // 消息的类型,1: 公告 Announce,2: 提醒 Remind,3:信息 Message
target      : {type: 'integer'},    // 目标的ID
targetType  : {type: 'string'},    // 目标的类型
action      : {type: 'string'},    // 提醒信息的动作类型
sender      : {type: 'integer'},    // 发送者的ID
createdAt    : {type: 'datetime', required: true}

Save Remind
音讯表,我们需求targettargetType字段,来记录该条提示所提到的对象。而action字段,则记录该条提示所涉嫌的动作。
例如消息:「小明喜欢了小说」
则:

target = 123,  // 文章ID
targetType = 'post',  // 指明target所属类型是文章
sender = 123456  // 小明ID

Save Announce and Message
当然,Notify还协助存款和储蓄公告和音信。它们会用到content字段,而不会用到targettargetTypeaction字段。

Notify

id            : {type: 'integer', primaryKey: true},        // 主键
content     : {type: 'text'},    // 消息的内容
type        : {type: 'integer', required: true, enum: [1, 2, 3]},  // 消息的类型,1: 公告 Announce,2: 提醒 Remind,3:信息 Message
target      : {type: 'integer'},    // 目标的ID
targetType  : {type: 'string'},    // 目标的类型
action      : {type: 'string'},    // 提醒信息的动作类型
sender      : {type: 'integer'},    // 发送者的ID
createdAt    : {type: 'datetime', required: true}

Save Remind
音讯表,大家要求targettargetType字段,来记录该条提示所涉嫌的靶子。而action字段,则记录该条提示所关联的动作。
比如说音信:「小明喜欢了稿子」
则:

target = 123,  // 文章ID
targetType = 'post',  // 指明target所属类型是文章
sender = 123456  // 小明ID

Save Announce and Message
自然,Notify还接济存款和储蓄文告和音信。它们会用到content字段,而不会用到targettargetTypeaction字段。

UserNotify

id            : {type: 'integer', primaryKey: true},        // 主键
isRead      : {type: 'boolean', required: true},   
user        : {type: 'integer', required: true},  // 用户消息所属者
notify      : {type: 'integer', required: true}   // 关联的Notify
createdAt    : {type: 'datetime', required: true}

作者们用UserNotify来存款和储蓄用户的新闻队列,它关系一则提示(Notify)的具体内容。
UserNotify的开创,重要透过两个路子:

  1. 遍历订阅(Subscription)表拉取文告(Announce)和提醒(Remind)的时候创立
  2. 新建音讯(Message)之后,马上创设。

UserNotify

id            : {type: 'integer', primaryKey: true},        // 主键
isRead      : {type: 'boolean', required: true},   
user        : {type: 'integer', required: true},  // 用户消息所属者
notify      : {type: 'integer', required: true}   // 关联的Notify
createdAt    : {type: 'datetime', required: true}

咱俩用UserNotify来存款和储蓄用户的消息队列,它事关一则提示(Notify)的具体内容。
UserNotify的创设,首要透过五个途径:

  1. 遍历订阅(Subscription)表拉取公告(Announce)和唤醒(Remind)的时候创制
  2. 新建新闻(Message)之后,立即创制。

Subscription

target      : {type: 'integer', required: true},    // 目标的ID
targetType  : {type: 'string', required: true},    // 目标的类型
action      : {type: 'string'},   // 订阅动作,如: comment/like/post/update etc.
user        : {type: 'integer'},
createdAt    : {type: 'datetime', required: true}

订阅,是从Notify表拉取音信到UserNotify的前提,用户率先订阅了某3个目的的某3个动作,在此之后发生那么些指标的这些动作的信息,才会被通报到该用户。
如:「小明关怀了成品A的评论」,数据显现为:

target: 123,  // 产品A的ID
targetType: 'product',
action: 'comment',
user: 123  // 小明的ID

如此那般,产品A下发生的每一条评论,都会发出文告给小明了。

Subscription

target      : {type: 'integer', required: true},    // 目标的ID
targetType  : {type: 'string', required: true},    // 目标的类型
action      : {type: 'string'},   // 订阅动作,如: comment/like/post/update etc.
user        : {type: 'integer'},
createdAt    : {type: 'datetime', required: true}

订阅,是从Notify表拉废除息到UserNotify的前提,用户率先订阅了某二个目的的某3个动作,在此之后发生那一个指标的这些动作的音信,才会被打招呼到该用户。
如:「小明关怀了产品A的评论」,数据表现为:

target: 123,  // 产品A的ID
targetType: 'product',
action: 'comment',
user: 123  // 小明的ID

诸如此类,产品A下爆发的每一条评论,都会产生公告给小明了。

SubscriptionConfig

action: {type: 'json', required: true},   // 用户的设置
user: {type: 'integer'}

区别用户只怕会有不平等的订阅习惯,在这一个表中,用户能够统一指向某种动作举办是还是不是订阅的安装。而暗中认可是采用系统提供的暗中认可配置:

defaultSubscriptionConfig: {
  'comment'   : true,    // 评论
  'like'      : true,    // 喜欢
}

在那套模型中,targetTypeaction是足以依据供给来扩张的,例如大家还是能扩张多多少个动作的唤起:hate被踩、update被更新….诸如此类。

SubscriptionConfig

action: {type: 'json', required: true},   // 用户的设置
user: {type: 'integer'}

今非昔比用户只怕会有不均等的订阅习惯,在那么些表中,用户能够统一指向某种动作实行是或不是订阅的设置。而暗中同意是行使系统提供的默许配置:

defaultSubscriptionConfig: {
  'comment'   : true,    // 评论
  'like'      : true,    // 喜欢
}

在那套模型中,targetTypeaction是能够依据须求来扩张的,例如大家还足以追加多多少个动作的晋升:hate被踩、update被更新….诸如此类。

安顿文件 NotifyConfig

// 提醒关联的目标类型
targetType: {
  PRODUCT : 'product',    // 产品
  POST    : 'post'    // 文章
},

// 提醒关联的动作
action: {
  COMMENT   : 'comment',  // 评论
  LIKE      : 'like',     // 喜欢
},

// 订阅原因对应订阅事件
reasonAction: {
  'create_product'  : ['comment', 'like']
  'like_product'    : ['comment'],
  'like_post'       : ['comment'],
},

// 默认订阅配置
defaultSubscriptionConfig: {
  'comment'   : true,    // 评论
  'like'      : true,    // 喜欢
}

布局文件 NotifyConfig

// 提醒关联的目标类型
targetType: {
  PRODUCT : 'product',    // 产品
  POST    : 'post'    // 文章
},

// 提醒关联的动作
action: {
  COMMENT   : 'comment',  // 评论
  LIKE      : 'like',     // 喜欢
},

// 订阅原因对应订阅事件
reasonAction: {
  'create_product'  : ['comment', 'like']
  'like_product'    : ['comment'],
  'like_post'       : ['comment'],
},

// 默认订阅配置
defaultSubscriptionConfig: {
  'comment'   : true,    // 评论
  'like'      : true,    // 喜欢
}

服务层 NotifyService

服务层 NotifyService

NotifyService拥有以下办法:

  • createAnnounce(content, sender)
  • createRemind(target, targetType, action, sender, content)
  • createMessage(content, sender, receiver)
  • pullAnnounce(user)
  • pullRemind(user)
  • subscribe(user, target, targetType, reason)
  • cancelSubscription(user, target ,targetType)
  • getSubscriptionConfig(userID)
  • updateSubscriptionConfig(userID)
  • getUserNotify(userID)
  • read(user, notifyIDs)

Notify瑟维斯拥有以下情势:

  • createAnnounce(content, sender)
  • createRemind(target, targetType, action, sender, content)
  • createMessage(content, sender, receiver)
  • pullAnnounce(user)
  • pullRemind(user)
  • subscribe(user, target, targetType, reason)
  • cancelSubscription(user, target ,targetType)
  • getSubscriptionConfig(userID)
  • updateSubscriptionConfig(userID)
  • getUserNotify(userID)
  • read(user, notifyIDs)

各艺术的处理逻辑如下:

createAnnounce(content, sender)

  1. 往Notify表中插入一条文告记录

createRemind(target, targetType, action, sender, content)

  1. 往Notify表中插入一条提示记录

createMessage(content, sender, receiver)

  1. 往Notify表中插入一条新闻记录
  2. 往UserNotify表中插入一条记下,并提到新建的Notify

pullAnnounce(user)

  1. 从UserNotify中赢得近期的一条布告新闻的创立时间: lastTime
  2. lastTime用作过滤条件,查询Notify的通告消息
  3. 新建UserNotify并涉及查询出来的文告音讯

pullRemind(user)

  1. 查询用户的订阅表,获得用户的一星罗棋布订阅记录
  2. 经过每一条的订阅记录的targettargetTypeactioncreatedAt去查询Notify表,获取订阅的Notify记录。(注意订阅时间必须早于提示创设时间)
  3. 询问用户的配置文件SubscriptionConfig,即使没有则利用私下认可的配备DefaultSubscriptionConfig
  4. 使用订阅配置,过滤查询出来的Notify
  5. 利用过滤好的Notify作为涉及新建UserNotify

subscribe(user, target, targetType, reason)

  1. 经过reason,查询NotifyConfig,获取相应的动作组:actions
  2. 遍历动作组,每3个动作新建一则Subscription记下

cancelSubscription(user, target ,targetType)

  1. 删除usertargettargetType相应的一则或多则记录

getSubscriptionConfig(userID)

  1. 查询SubscriptionConfig表,获取用户的订阅配置

updateSubscriptionConfig(userID)

  1. 履新用户的SubscriptionConfig记录

getUserNotify(userID)

  1. 获取用户的新闻列表

read(user, notifyIDs)

  1. 更新内定的notify,把isRead属性设置为true

各艺术的处理逻辑如下:

createAnnounce(content, sender)

  1. 往Notify表中插入一条布告记录

createRemind(target, targetType, action, sender, content)

  1. 往Notify表中插入一条提醒记录

createMessage(content, sender, receiver)

  1. 往Notify表中插入一条音讯记录
  2. 往UserNotify表中插入一条记下,并提到新建的Notify

pullAnnounce(user)

  1. 从UserNotify中得到近来的一条布告新闻的始建时间: lastTime
  2. lastTime用作过滤条件,查询Notify的公告音讯
  3. 新建UserNotify并涉及查询出来的通知音讯

pullRemind(user)

  1. 查询用户的订阅表,得到用户的一三种订阅记录
  2. 透过每一条的订阅记录的targettargetTypeactioncreatedAt去询问Notify表,获取订阅的Notify记录。(注意订阅时间必须早于提醒创设时间)
  3. 询问用户的安顿文件SubscriptionConfig,借使没有则利用暗中同意的陈设DefaultSubscriptionConfig
  4. 应用订阅配置,过滤查询出来的Notify
  5. 选择过滤好的Notify作为涉及新建UserNotify

subscribe(user, target, targetType, reason)

  1. 透过reason,查询NotifyConfig,获取相应的动作组:actions
  2. 遍历动作组,每三个动作新建一则Subscription记录

cancelSubscription(user, target ,targetType)

  1. 删除usertargettargetType对应的一则或多则记录

getSubscriptionConfig(userID)

  1. 查询SubscriptionConfig表,获取用户的订阅配置

updateSubscriptionConfig(userID)

  1. 更新用户的SubscriptionConfig记录

getUserNotify(userID)

  1. 得到用户的音信列表

read(user, notifyIDs)

  1. 立异内定的notify,把isRead属性设置为true

时序图

时序图

晋升的订阅、创立、拉取

图片 11

唤醒的订阅、创立、拉取

小编们能够在成品创造之后,调用NotifyService.subscribe方法,
接下来在成品被评价之后调用NotifyService.createRemind方法,
再不怕用户登录系统或许其余的某一个每一日调用NotifyService.pullRemind方法,
终极在用户查询音信队列的时候调用NotifyService.getUserNotify方法。

升迁的订阅、成立、拉取

图片 12

提醒的订阅、创造、拉取

笔者们可以在产品成立之后,调用NotifyService.subscribe方法,
接下来在产品被评论之后调用NotifyService.createRemind方法,
再不怕用户登录连串也许其余的某2个随时调用NotifyService.pullRemind方法,
终极在用户查询音信队列的时候调用NotifyService.getUserNotify方法。

通告的创造、拉取

图片 13

通知的开创、拉取

在协会者发送了一则布告的时候,调用NotifyService.createAnnounce方法,
下一场在用户登录系统可能其余的某三个整日调用NotifyService.pullAnnounce方法,
最终在用户查询音讯队列的时候调用NotifyService.getUserNotify方法。

通告的创办、拉取

图片 14

公告的创制、拉取

在组织者发送了一则文告的时候,调用NotifyService.createAnnounce方法,
接下来在用户登录种类或许其它的某贰个整日调用NotifyService.pullAnnounce方法,
末尾在用户查询信息队列的时候调用NotifyService.getUserNotify方法。

音信的始建

图片 15

消息的创导

音信的开创,只需求平素调用NotifyService.createMessage措施就足以了,
在下二遍用户查询音讯队列的时候,就会询问这条消息。


 

 

 

新闻的创导

图片 16

消息的开创

消息的创始,只须要直接调用NotifyService.createMessage办法就能够了,
在下2次用户查询新闻队列的时候,就会询问那条音讯。