通知系统，顾名思义即通知信息的传达处理系统。目的是为了让用户获得需要得到的消息及提醒并进行处理。这里的“需要得到”有两层意思：
1、用户彼此互动触发的信息流（留言、评论或者回复、私信等） 2、网站希望用户了解关注的信息（系统公告等）
通知系统设计的原则可简单的归纳为：
1、消息传播效率最高（获取、处理、信息传达、用户反馈等效率） 2、避免产生骚扰（噪音、频繁提示）

通知合并

通知在推送之前需要进行汇总合并，目的在于提高消息传播处理效率；减少骚扰，降低噪音；平衡服务器压力。

合并周期

固定时间内的消息全部汇总（24小时内/30天等）；
无固定时间（只要未处理/未读即汇总）
当然一般都组合着用：合并24小时内未处理消息

分类合并

同种类进行合并（如n条留言合并为1条）
同一发起人合并（如张三给你发来的n条私信）
同一时间周期合并（如24小时共收到n条评论）

通知分发

通知按照规则汇总完成后，系统将其通过通知管道推送到用户，以便用户处理。

分发方式

分发方式与Feed系统类似，多采用Push方式，即在指定时间内主动推送给用户。部分特定类型需要用户请求（Pull）拉取未读消息。目前大部分通知优先推送未处理通知合并后的总数，已提醒用户已有新消息需要处理。用户点击数字后再去服务端请求具体的消息内容。此种方式综合考虑了成本、压力和体验。当然，某些极端情况下需要进行优化处理：如未读消息超过1000，用户请求时先推送前50条或者放入cache中等。技术童鞋会有各种手段，这里不做详述。

分发频率（时间）

分发时间主要根据消息的优先级来做区隔：

分发管道

分发管道即消息通知的具体推送渠道，根据业务类型可以分为：Web、App、短信、邮件等。

用户处理

根据前文提到的分发方式，对于通知的处理在逻辑上可以分为两层：通知状态的处理和通知内容的处理。

状态的处理狭义的理解即为是否已读（已处理）。

通常初始数字即为系统推送过来的未读总量，用户点击数字进入相关功能列表查阅后，读取的动作完成，未读数字相应减少。

有几种情况需要变通处理：

若用户未读信息较多（m=100），但第一页列表只能显示（n=10）条的话，那未读数字即为m-n=90；
某些产品会将点击等同于已读。即用户只要点击无论是否打开列表查看均认为已读。这样的处理一般用于重要级别较低的消息。点击即已读可有效降低骚扰。
某些重要级别较高的消息已处理状态可以定义为用户进行相关操作后才为已处理，而非查阅。如用户进行评论、回复、点击忽略或点击删除等动作时才认为已处理。

内容的处理狭义的理解即为用户是否操作。

根据不同消息的种类和业务的需要，操作可分为：

处理：用户必须点击功能链接进行处理。如：你的密码过于简单，点此进行修改；
回复：如回复私信，对评论进行回复；
确认：对消息做出确认的反馈，如某些系统提示可设置”我已知道，不再提示”的选项；
忽略：用户进行忽略操作或不进行任何操作；
删除：用户删除本消息。

消息处理后的状态需要统一。

消息需要标记是否已处理的状态，且状态在不同的终端是打通的。如：用户在客户端对消息进行了查看，在web站点本消息应自动标记为已读状态。

通知回收

回收主要针对用户已处理消息的操作。

用户之间触发的消息一般需要留档保存。如评论/回复/留言/私信等。产品可提供选项询问用户是否超过一定周期自动清理。
在部分产品中，还需要考虑功能的优先级。如解除好友关系或加入黑名单后自动将删除双方的私信记录。
系统触发的消息一般设置一定的回收删除时间。如系统提醒、通知、公告等。过期后自动在产品里删除。物理上可以设置是否备份。
过期但用户未处理消息（用户长时间未登录但收到他人的回复）可以根据业务需求来处理。如未读的私信/评论/回复永久保留等。重要未读消息可尝试二次推送或使用其他途径（邮箱、APP、短信等）通知。