通知系统（Notification System），顾名思义即通知信息的传达处理系统。目的是为了让用户获得需要得到的消息及提醒并进行处理。

通知系统，顾名思义即通知信息的传达处理系统。目的是为了让用户获得需要得到的消息及提醒并进行处理。 这里的“需要得到”有两层意思

1、用户彼此互动触发的信息流（留言、评论或者回复、私信等）

2、网站希望用户了解关注的信息（系统公告等）

通知系统设计的原则可简单的归纳为：

1、消息传播效率最高（获取、处理、信息传达、用户反馈等效率）

2、避免产生骚扰（噪音、频繁提示）

不用的平台和产品本身由于对业务的需求不一样，种类也是有区别的。 大致可分为以下几种：

通知的逻辑精简后如下：

现对这几个环节分开说明：

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

1）合并周期：

当然一般都组合着用：合并24小时内未处理消息

2）分类合并

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

1）分发方式

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

2）分发频率（时间）

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

3）分发管道

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

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

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

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

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

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

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

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

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

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

注：具体的交互需要考虑本身业务特点和目标需求。特定业务可能需要强调，某些业务又需要考虑骚扰，故抛开具体情境本身谈交互是无耻的。 这里只针对一般的社区网站，描述一下个人所喜欢的交互方式。

1)、新消息到达时提醒交互

当新消息到达时，可以使用以下提醒方式

1.标题闪动

2.声音提醒 新消息到达后自动触发声音

3.气泡+数字

4.新消息浮层

5.弹窗提示

2)、通知处理

消息多采用当前触发、即时处理类似“所见即所得”的交互方式。 

采用此方式的需要考虑：

因消息本身业务性质，过多无用通知势必会造成噪音，打扰到用户。因此合理设置消息的通知频率和渠道，以防早上体验和效率上的损失。

1)、提供通知频率和渠道的管理功能

如常见的邮件退订管理，消息通知类型管理。 

Facebook通知设置



2)、增加屏蔽功能

消息屏蔽功能在业务上应该属于第一条中通知类型管理，当业务模块较多且之前关联分散时，或者开放平台功能接入的第三方应用通知时，可使用屏蔽功能。

facebook应用消息管理

3)、结合权限体系

①、功能隐私设置

使用隐私设置界定具体的接收权限、范围等

微博私信设置

②、结合黑名单功能

使用黑名单可屏蔽指定用户或关键词的具体消息通知。

当用户长时间不登陆或对消息不处理时，可使用其他渠道推送通知，已达到拉回的目的。 这个要与网站整体的拉回策略相结合。

iOS中提供了2种推送通知

推送通知的作用

不同的呈现效果

使用的几个细节

设计

企业内部通常都有通知需要上传下达，有时是临时通知，比如通知“下午2点开会”，如果是每个部门电话通知比较烦琐，而仅是通过电子邮件发送，则往往有部分人没有及时地查看而导致错过会议;有时是某个精神需要传达，是一些文本文档;另外一些时候则可能是部门之间交流的内部文件。为了防止员工工作时间闲聊和内部资料外泄，企业外网不开放，公共的即时聊天工具不适合这种场合的使用。而有些情况下，比如非工作时间，企业外网是开放的、允许员工使用的，员工在众多的聊天工具中选择几种是很常见的情况。

桌面通知系统是以企业内部局域网为基础进行设计的。它的目标是在企业内部建立即时通讯平台，方便通知的上传下达，同时对几种常用的公共聊天软件进行集成，使它们有统一的外观、配置，可以减少人们在不同聊天工具之间的切换，并限制公共聊天软件的使用时间段。

主要功能模块

UI模块

桌面通知系统客户端，随机器开机而自动起动;它的Ul(用户界面)仿照QQ聊天程序，不使用时，放置于系统托盘位置;若有企业内部消息时，消息窗口自动弹出，并将其设置为最前端窗口，强迫用户阅读并确认后才能够关闭，防止消息没有被及时阅读。

对于服务器端，界面很简单，主要显示出客户端发送消息内容，以及文件传送的时间、位置等信息。

在Eclipse RCP中，所有的一切都是通过扩展点机制实现的，开发RCP的主要过程也就是向应用添加视图、编辑器、透视图、菜单、工具栏、上下文菜单等等的扩展的过程。其中注意遵循模块化原则，按照功能、职责、以及模型和UI分离的原则将系统划分成不同的模块，同时要充分利用Eclipse提供的很多可重用的插件、扩展点、内置的Action、视图、编辑器、首选项等。

消息管理模块

消息分为两类，一是指企业内部发送的消息，二是指集成聊天软件的消息。

企业内部发送的消息，由系统本身进行管理。客户端用户名是部门名，由系统维护部门规定，整个部门的用户名均相同，防止个人利用桌面通知系统聊天。发送消息给某个部门时，该部门所有在线客户端均接收消息。利用Java提供的计时器类，桌面通知系统客户端消息窗口的新内容，每隔10分钟自动存储，减少意外断电的损失。

由于公用即时通讯工具通讯协议各异，软件升级更新周期短，桌面通知系统对于公用即时通讯工具，只是采用了简单的调用方式集成，并未对其内容进行限制和管理，这样可以简化桌面通知系统的实现过程。因此，桌面通知系统中集成的即时通讯工具消息发送，使用聊天软件原有的管理方式，系统并不对其干预，只是对其使用时段进行限制和管理。

文件管理模块

为了减少服务器的负担，加快传输速度，与消息发送不同，客户端的文件发送采用点对点传输。源客户端从服务器获取目的客户端的IP地址，然后启动新文件发送线程发送文件。由于采用了线程方式，文件传送操作不影响客户端针对桌面通知系统的其它操作。

时间管理模块

时间管理模块，主要针对集成的聊天软件上线时间进行管理。在系统维护部门规定工作时间内，除桌面通知系统外其它的即时通讯软件均为灰色，即:不可用状态。

数据管理模块

本系统在服务器端建立了数据库服务。服务器端数据库包括部门信息、管理员权限信息、设置时间段信息、日志管理等方面的内容。由于MySQL5.0免费版亦具有良好稳定的性能，并且安装简单、系统开销少，桌面通知系统利用它完成数据信息管理工作。

安全管理模块

由于桌面通知系统主要针对企业内网使用，所以其安全性相对于公用即时通讯工具具有天然的优势。该系统主要采用客户端权限等级制来实现安全管理，即为不同的客户端设置不同的权限，限制客户端访问消息和文件的权限，以达到保障内部资料安全的目的。