精华内容
下载资源
问答
  • 消息通知系统模型设计

    千次阅读 2019-02-21 00:42:29
    本篇主要明确消息通知系统的概念和具体实现,包括数据库设计、技术方案、逻辑关系分析等。消息通知系统是一个比较复杂的系统,这里主要分析站内消息如何设计和实现。 我们常见的消息推送渠道有以下几种: 设备推送 ...

    本篇主要明确消息通知系统的概念和具体实现,包括数据库设计、技术方案、逻辑关系分析等。消息通知系统是一个比较复杂的系统,这里主要分析站内消息如何设计和实现。

    我们常见的消息推送渠道有以下几种:
    • 设备推送
    • 站内推送
    • 短信推送
    • 邮箱推送
    我们常见的站内通知有以下几种类别:
    • 公告 Announcement
    • 提醒 Remind

      • 资源订阅提醒「我关注的资源有更新、评论等事件时通知我」
      • 资源发布提醒「我发布的资源有评论、收藏等事件时通知我」
      • 系统提醒「平台会根据一些算法、规则等可能会对你的资源做一些事情,这时你会收到系统通知」
    • 私信 Mailbox

    以上三种消息有各自特点,实现也各不相同,其中「提醒」类通知是最复杂的,下面会详细讲。

    数据模型设计

    公告

    公告是指平台发送一条含有具体内容的消息,站内所有用户都能收到这条消息。

    方案一:【适合活跃用户在5万左右】

    公告表「notify_announce」
    表结构如下:

    id: {type: 'integer', primaryKey: true, autoIncrement:true} //公告编号;
    senderID: {type: 'string', required: true} //发送者编号,通常为系统管理员;
    title: {type: 'string', required: true} //公告标题;
    content: {type: ’text', required: true} //公告内容;
    createdAt: {type: 'timestamp', required: true} //发送时间;

    用户公告表「notify_announce_user」
    表结构如下:

    id: {type: 'integer', primaryKey: true, autoIncrement:true} //用户公告编号;
    announceID: {type: 'integer'} //公告编号;
    recipientID: {type: 'string', required: true} //接收用户编号;
    createdAt:{type: 'timestamp', required: true} //拉取公告时间;
    state: {type: 'integer', required: true} //状态,已读|未读;
    readAt:{type: 'timestamp', required: true} //阅读时间;

    平台发布一则公告之后,当用户登录的时候去拉取站内公告并插入notify_announce_user表,这样那些很久都没登陆的用户就没必要插入了。「首次拉取,根据用户的注册时间;否则根据notify_announce_user.createdAt即上一次拉取的时间节点获取公告」

    方案二:【适合活跃用户在百万-千万左右】

    和方案一雷同,只是需要把notify_announce_user表进行哈希分表,需事先生成表:notify_announce_<hash(uid)>。

    用户公告表「notify_announce_<hash(uid)>」
    表结构如下:

    id: {type: 'integer', primaryKey: true, autoIncrement:true} //用户公告编号;
    announceID: {type: 'integer'} //公告编号;
    recipientID: {type: 'string', required: true} //接收用户编号;
    createdAt:{type: 'timestamp', required: true} //拉取公告时间;
    state: {type: 'integer', required: true} //状态,已读|未读;
    readAt:{type: 'timestamp', required: true} //阅读时间;

    提醒

    提醒是指「我的资源」或「我关注的资源」有新的动态产生时通知我。提醒的内容无非就是:
    「someone do something in someone's something」
    「谁对一样属于谁的事物做了什么操作」

    常见的提醒消息例子,如:
    XXX 关注了你 - 「这则属于资源发布提醒」
    XXX 喜欢了你的文章 《消息通知系统模型设计》 - 「这则属于资源发布提醒」
    你喜欢的文章《消息通知系统模型设计》有新的评论 - 「这则属于资源订阅提醒」
    你的文章《消息通知系统模型设计》已被加入专题 《系统设计》 - 「这则属于系统提醒」
    小明赞同了你的回答 XXXXXXXXX -「这则属于资源发布提醒」

    最后一个例子中包含了消息的生产者(小明),消息记录的行为(赞同),行为的对象(你的回答内容)

    分析提醒类消息的句子结构:
    someone = 动作发起者,标记为「sender」
    do something = 对资源的操作,如:评论、喜欢、关注都属于一个动作,标记为「action」
    something = 被作用对象,如:一篇文章,文章的评论等,标记为「object」
    someone's = 动作的目标对象或目标资源的所有者,标记为「objectOwner」

    总结:sender 和 objectOwner 就是网站的用户,object 就是网站资源,可能是一篇文章,一条文章的评论等等。action 就是动作,可以是赞、评论、收藏、关注、捐款等等。

    提醒设置

    提醒通常是可以在「设置-通知」里自定义配置的,用户可以选择性地「订阅」接收和不接收某类通知。

    呈现在界面上是这样的:

    通知设置
    
    我发布的 publish
        文章
            被 评论    是/否 通知我
            被 收藏    是/否 通知我
            被 点赞    是/否 通知我
            被 喜欢    是/否 通知我
            被 捐款    是/否 通知我
    
    我订阅的 follow
        文章
            有 更新   是/否 通知我
            被 评论   是/否 通知我

    订阅

    一般系统默认是订阅了所有通知的。系统在给用户推送消息的时候必须查询通知「订阅」模块,以获取某一事件提醒消息应该推送到哪些用户。
    也就是说「事件」和「用户」之间有一个订阅关系。

    那么接下来我们分析下「订阅」有哪些关键元素:

    比如我发布了一篇文章,那么我会订阅文章《XXX》的评论动作,所以文章《XXX》每被人评论了,就需要发送一则提醒告知我。

    分析得出以下关键元素:

    • 订阅者「subscriber」
    • 订阅的对象「object」
    • 订阅的动作「action」
    • 订阅对象和订阅者的关系「objectRelationship」

    什么是订阅的目标关系呢?

    拿知乎来说,比如我喜欢了一篇文章,我希望我订阅这篇文章的更新、评论动作。那这篇文章和我什么关系?不是所属关系,只是喜欢。

    • objectRelationship = 我发布的,对应着 actions = [评论,收藏]
    • objectRelationship = 我喜欢的,对应着 actions = [更新,评论]

    讲了那么多,现在来构建「提醒」的数据结构该吧!

    提醒表「notify_remind」
    表结构如下:

    id: {type: 'integer', primaryKey: true, autoIncrement:true} //主键;
    remindID: {type: 'string', required: true} //通知提醒编号;
    senderID: {type: 'string', required: true} //操作者的ID,三个0代表是系统发送的;
    senderName: {type: 'string’, required: true} //操作者用户名;
    senderAction: {type: 'string', required: true} //操作者的动作,如:赞了、评论了、喜欢了、捐款了、收藏了;
    objectID: {type: 'string', required: true}, //目标对象ID;
    object: {type: 'string', required: false}, //目标对象内容或简介,比如:文章标题;
    objectType: {type: 'string', required: true} //被操作对象类型,如:人、文章、活动、视频等;
    recipientID: {type: 'string’} //消息接收者;可能是对象的所有者或订阅者;
    message: {type: 'text', required: true} //消息内容,由提醒模版生成,需要提前定义;
    createdAt:{type: 'timestamp', required: true} //创建时间;
    status:{type: 'integer', required: false} //是否阅读,默认未读;
    readAt:{type: 'timestamp', required: false} //阅读时间;

    假如:特朗普关注了金正恩,以下字段的值是这样的

    senderID = 特朗普的ID
    senderName = 特朗普
    senderAction = 关注
    objectID = 金正恩的ID
    object = 金正恩
    objectType = 人
    recipientID = 金正恩的ID
    message = 特朗普关注了金正恩
    
    这种情况objectID 和 recipientID是一样的。
    这里需要特别说下消息模版,模版由「对象」、「动作」和「对象关系」构成唯一性。

    通知提醒订阅表「notify_remind_subscribe」
    表结构如下:

    id: {type: 'integer', primaryKey: true, autoIncrement:true} //订阅ID;
    userID: {type: 'string', required: true},//用户ID,对应 notify_remind 中的 recipientID;
    objectType: {type: 'string', required: true} //资源对象类型,如:文章、评论、视频、活动、用户;
    action: {type: 'string', required: true} //资源订阅动作,多个动作逗号分隔如: comment,like,post,update etc.
    objectRelationship: {type: 'string', required: true} //用户与资源的关系,用户发布的published,用户关注的followed;
    createdAt:{type: 'timestamp', required: true} //创建时间;
    特别说下「objectRelationship」字段的作用,这个字段用来区分「消息模版」,为什么呢?因为同一个「资源对象」和「动作」会有两类订阅者,一类是该资源的Owner,另一类是该资源的Subscriber,这两类人收到的通知消息内容应该是不一样的。

    聚合

    假如我在抖音上发布了一个短视频,在我不在线的时候,被评论了1000遍,当我一上线的时候,应该是收到一千条消息,类似于:「* 评论了你的文章《XXX》」? 还是应该收到一条信息:「有1000个人评论了你的文章《XXX》」?

    当然是后者更好些,要尽可能少的骚扰用户。

    消息推送

    是不是感觉有点晕了,还是先上一张消息通知的推送流程图吧:
    clipboard.png

    订阅表一共有两张噢,一张是「通知订阅表」、另一张是用户对资源的「对象订阅表」。
    具体实现就不多讲了,配合这张图,理解上面讲的应该不会有问题了。

    私信

    通常私信有这么几种需求:

    • 点到点:用户发给用户的站内信,系统发给用户的站内信。「1:1」
    • 点到多:系统发给多个用户的站内信,接收对象较少,而且接收对象无特殊共性。「1:N」
    • 点到面:系统发给用户组的站内信,接收对象同属于某用户组之类的共同属性。「1:N」
    • 点到全部:系统发给全站用户的站内信,接收对象为全部用户,通常为系统通知。「1:N」

    这里主要讲「点到点」的站内信。

    私信表「notify_mailbox」
    表结构如下:

    id: {type: 'integer', primaryKey: true, autoIncrement:true} //编号;
    dialogueID: {type: 'string', required: true} //对话编号; 
    senderID: {type: 'string', required: true} //发送者编号;
    recipientID: {type: 'string', required: true} //接收者编号;
    messageID: {type: 'integer', required: true} //私信内容ID;
    createdAt:{type: 'timestamp', required: true} //发送时间;
    state: {type: 'integer', required: true} //状态,已读|未读;
    readAt:{type: 'timestamp', required: true} //阅读时间;

    Inbox

    私信列表
    select * from notify_inbox where recipientID="uid" order by createdAt desc
    
    对话列表
    select * from notify_inbox where dialogueID=“XXXXXXXXXXXX” and (recipientID=“uid” or senderID="uid") order by createdAt asc

    私信回复时,回复的是dialogueID

    Outbox

    私信列表
    select * from notify_inbox where senderID="uid" order by createdAt desc
    
    对话列表
    select * from notify_inbox where dialogueID=“XXXXXXXXXXXX” and (senderID=“uid” or recipientID="uid") order by createdAt asc

    私信内容表「notify_inbox_message」
    表结构如下:

    id: {type: 'integer', primaryKey: true, autoIncrement:true} //编号;
    senderID: {type: 'string', required: true} //发送者编号;
    content: {type: 'string', required: true} //私信内容; 
    createdAt:{type: 'timestamp', required: true}

    参考

    消息系统设计与实现
    通知系统设计

    展开全文
  • 实际场景 早上买早点,扫码下单,用户在微信中会收到下单成功的服务通知。 扫码出地铁后,手机会收到APP支付通知。 微信、支付宝、刷卡消费后,手机会收到短信通知。...今天,我们就聊一聊通知系统怎么做。 架构设计

    实际场景

    早上买早点,扫码下单,用户在微信中会收到下单成功的服务通知。

    微信服务通知

    扫码出地铁后,手机会收到APP支付通知。

    app消费通知

    微信、支付宝、刷卡消费后,手机会收到短信通知。

    短信支付通知

    在海底捞吃完火锅,扫结账小票上的开票二维码开电子发票,商家开完票要通过邮件通知发送给消费者。

    电子发票通知

    在移动互联网时代,商家要通过各种渠道触达到消费者。触达的方式各种各样,可以通过Email、Wechat、DingDing、SMS、App、MQTT通知等。对于做B2C业务的企业,需要具备这些相关的能力。今天,我们就聊一聊通知系统怎么做。

    架构设计

    通常来说,一个公司有很多的业务线,这些业务线都需要通过不同的方式通知自己的消费者。虽然每条业务线都有这个需求,但是不用重复造轮子,可以做一个公司级别的通知系统,有业务线需要使用,就可以直接调用通知系统的接口,进行相关的通知发送。

    既然是一个公司级别的通知系统,上游业务方使用的通知方式肯定多种多样,这就需要通知系统聚合这些通知功能,然后向上游暴露这些接口,给业务方使用。

    同时,通知系统要考虑触达率,如果用户收不到信息,是不是需要做重试,重试的次数等问题。

    设计思路

    这里,给大家介绍一些相关的设计思路,及需要考虑的问题,供大家参考。

    重点问题

    1.并发问题

    既然是一个公司级别的通知系统,上游业务方众多,并发量大,考虑到是通知业务,并不是有非常非常高的实时性需求,所以可以考虑做异步处理,上游调用通知接口,通知服务将通知任务放入通知队列慢慢处理,并立即告诉上游业务方通知任务接受成功。这里异步可以考虑使用Kafka。

    对于有实时性要求的业务,可以单独再开接口处理。

    2.是否重试、如何重试

    因为上游业务是不一样的,有的业务需要对通知失败的任务进行重试,有的可能就不管了。所以通知业务再提供接口时,可以考虑加上参数QOS,也就是消息质量,如果传入了对应需要重试的QOS,则通知系统会重试通知。

    如果需要重试,如何自动重试,重试的时间间隔如何?这一点我在之前的文章《支付公司如何赚钱?支付网关如何设计?》中也说过,可以看一下。其中设计的参考信息也给出来,轮询时间间隔可以参考(微信通知),队列可以参考亚马逊云的死信队列(死信队列)。

    经过多次重试,最终还是失败的任务,需要持久化到数据库。

    重试功能应该是通知平台的重要功能之一。

    3.后台统计分析、通知监控、手动重试

    一个公用的通知平台,需要一个监控后台,监控、分析平台通知发送情况、通知到达率、失败任务手动重试等功能。

    4.实现各种通知能力

    触达消费者的方式各种各样,可以通过email、wechat、dingding、sms、app、mqtt 等各种方式,通知系统的功能重要功能之一就是聚合这些通知方式。

    Email

    消费者开电子发票,发票业务系统就需要把开除了的票通过Email发送给消费者,通知系统就需要集合邮件功能。

    Wechat

    消费者下完单,下单业务系统就需要通过公众号模版等形式给消费者微信推送下单成功的消息,通知系统就需要集成服务消息推送功能。

    SMS

    双十一之前,商户需要通过短信给自己的会员发送节日活动等信息,通知系统就需要集成短信推送功能。

    HTTP

    自己的系统替商户处理完业务后,需要回调通知商户系统,通常都需要使用http做回调,通知系统就需要实现http回调功能。

    MQTT

    业务系统需要使用mqtt发布订阅消息时,通知系统就需要实现mqtt的sub功能。可以参考我之前的一篇关于MQTT的介绍。

    当一个通知系统集成了各种通知功能,可以自动重试,同时有统计监控管理平台,一个通用的通知系统就搭建完成了。

    参考:

    Amazon Simple Notification Service

    Aliyun MQTT

    完成,收工!!

    传播知识,共享价值】,感谢小伙伴们的关注和支持,我是【诸葛小猿】,一个彷徨中奋斗的互联网民工。

    展开全文
  • Laravel消息通知系统之数据库

    千次阅读 2020-04-11 12:02:56
    Laravel 自带了一套极具扩展性的消息通知系统,尤其还支持多种通知频道,我们将利用此套系统来向用户发送消息提醒。 通知频道指通知的各种途径,Laravel自带的有如下几种 数据库 邮件 短信(通过 Nexmo) Slack ...

    Laravel 自带了一套极具扩展性的消息通知系统,尤其还支持多种通知频道,我们将利用此套系统来向用户发送消息提醒。

    通知频道指通知的各种途径,Laravel自带的有如下几种

    1. 数据库
    2. 邮件
    3. 短信(通过 Nexmo)
    4. Slack

    通过数据库实现消息通知

    1.准备数据表

     php artisan notifications:table
    

    该命令会生成消息通知表的迁移文件

    database/migrations/{$timestamp}_create_notifications_table.php
    

    使用命令执行迁移文件

    php artisan migrate
    

    2.生成通知类
    laravel中每一种通知属于一个类,使用如下命令创建通知类,通知类存放在app/Notifications

     php artisan make:notification TopicReplied
    

    3.定义通知类

    <?php
    
    namespace App\Notifications;
    
    use Illuminate\Bus\Queueable;
    use Illuminate\Notifications\Notification;
    use Illuminate\Contracts\Queue\ShouldQueue;
    use Illuminate\Notifications\Messages\MailMessage;
    use App\Models\Reply;
    
    class TopicReplied extends Notification
    {
        use Queueable;
    
        public $reply;
    
        public function __construct(Reply $reply)
        {
            // 注入回复实体,方便 toDatabase 方法中的使用
            $this->reply = $reply;
        }
    
        public function via($notifiable)
        {
            // 开启通知的频道
            return ['database'];
        }
    
        public function toDatabase($notifiable)
        {
            $topic = $this->reply->topic;
            $link =  $topic->link(['#reply' . $this->reply->id]);
    
            // 存入数据库里的数据
            return [
                'reply_id' => $this->reply->id,
                'reply_content' => $this->reply->content,
                'user_id' => $this->reply->user->id,
                'user_name' => $this->reply->user->name,
                'user_avatar' => $this->reply->user->avatar,
                'topic_link' => $link,
                'topic_id' => $topic->id,
                'topic_title' => $topic->title,
            ];
        }
    }
    

    通知类的构造方法可执行依赖注入,via方法表示通过什么途径发送通知,toDatabase是数据库通知的方法,这个方法接收 $notifiable实例参数并返回一个普通的 PHP 数组。这个返回的数组将被转成 JSON 格式并存储到通知数据表的 data 字段中。

    4.触发通知
    在某个模型的观察者中

    <?php
    
    namespace App\Observers;
    use App\Notifications\TopicReplied;
    use App\Models\Reply;
    
    // creating, created, updating, updated, saving,
    // saved,  deleting, deleted, restoring, restored
    
    class ReplyObserver
    {
        public function created(Reply $reply)
        {
            $reply->topic->reply_count = $reply->topic->replies->count();
            $reply->topic->save();
            // 通知话题作者有新的评论
            $reply->topic->user->notify(new TopicReplied($reply));
        }
    

    其中 User 模型中使用了 trait —— Notifiable,它包含着一个可以用来发通知的方法 notify() ,此方法接收一个通知实例做参数。

    这样当评论被写入数据库时,会触发消息通知并写入数据库。
    在这里插入图片描述

    展开全文
  • 网站的消息通知系统设计漫谈

    千次阅读 2015-06-07 18:55:40
    现在的很多网站都有消息通知系统,比如新浪微博页面右上角的小黄签,比如Facebook页面左上角的Notifications。但是消息通知系统的说法是个笼统的概念,我理解的其本质功能是网站把某些对用户有价值的信息及时告知...

    现在的很多网站都有消息通知系统,比如新浪微博页面右上角的小黄签,比如Facebook页面左上角的Notifications。但是消息通知系统的说法是个笼统的概念,我理解的其本质功能是网站把某些对用户有价值的信息及时告知用户。比如常见的SNS关系中谁关注了你,谁评价了你发布的内容,谁邀请你加入某个小组等。

    这类消息可以大体上分为两类,一种是告知性质的,就是用户知道有这么回事就行了,最多是具体看一下内容,比如其他用户对你发布的内容做了评论。另外一种是需要用户处理的,用户必须做出某种动作来回应,比如好友请求,你是接受、拒绝还是忽略。

    纵观现在一些网站的消息通知产品设计,可以分为两种实现方式,一种是把各个功能模块的消息分类,然后每类有多少数字告知用户,用户需要到具体的功能模块页面查看同类的内容,典型的是新浪微博的设计。如下图所示:

    其按功能分类通知每类新消息的数目,然后可以点击链接到某个功能模块查看同类消息。对应的,在功能设计上就有专门的评论汇总地方,有@我汇总的地方。这样的好处在同类消息很多的时候,比如收到几十条新评论的时候,用户不必频繁的在消息通知页面和具体评论页面来回切换,因为所有的评论在一个页面都能查看了。不好的地方就是不够直观,需要再次点击才能查看用户是对你的哪些内容发布了评论。另外,新浪微博中并没有用户必须处理的操作,用户之间是以关注为表现形式的弱关系,不需要确认就能关注一个人。

    相对的,Facebook是所谓的强关系,就是用户加一个人为好友,必须得到对方的确认,为了处理好告知性质和操作性质两方面的消息通知,Facebook把好友请求部分独立出来了,可以理解为是一种比较复杂的消息通知。其界面如下:

    用户必须在这个界面进行确认才能真正成为朋友,但是在消息通知里告知用户并能马上确认,对用户操作来说是很方便的。Facebook传统的消息通知和新浪微博不同,它可以在消息里显示具体的内容,而不是单纯的数量提示:

    这样做的好处就是,不必设计一个单独的功能汇总某一类的消息,不好的地方就是在消息很多的时候,用户需要频繁的在消息通知界面和具体的内容界面切换来查看未读的内容,比较麻烦。国内模仿quora的知乎也是这样设计消息通知功能的:

    那么有没有更好的方式来展现消息通知及其具体内容呢,Google Plus做成了更好的尝试,首先在消息通知的小窗口就能查看某一条具体消息的内容:

    以下是在小窗口查看具体消息内容的情况,在这个页面可以进行消息详细内容的前后切换:

    然后在完整的消息列表页,是直接显示了消息的详细内容:

    正如你看到的,前两条消息就要占用一屏以上的空间,这在消息很多的情况下,是很不方便的。那么有没有更好的展现方式呢,我认为Twitter的界面风格就是最佳的方式:

    在左边展示完整的消息列表,右边展示某个消息的具体内容及操作动作,用户可以很清晰的知道自己当前查看或处理的消息,并且不需要界面切换,perfect!

    消息通知的合并也很重要,可以避免大量同样的消息对用户造成干扰,新浪微博的通知数目的方式本身就是一种合并,Facebook和G+也都对合并做的很好。还要注意的是,Facebook对于一段时间以前的历史消息就不予显示了,这无论从消息通知的功能本质来说,还是系统的性能方面考虑,都是可以理解的。

    展开全文
  • Laravel 论坛系统消息通知功能

    千次阅读 2019-01-09 14:58:48
    Laravel 自带了一套极具扩展性的消息通知系统,尤其还支持多种通知频道,我们将利用此套系统来向用户发送消息提醒。 什么是通知频道? 通知频道是通知传播的途径,Laravel 自带的有数据库、邮件、短信(通过 Nexmo)...
  • 项目需求:管理员后台设置通知功能,每当后台有数据更新时,用户端实时提醒 实现方法: 项目所有页面包含公共页面 header.jsp 在公共页面中写入ajax,实现实时提醒 $(function(){ $.ajax({ type : "POST", ...
  • android设备在系统通知栏处提示有新消息,同时也有声音通知
  • 众所周知在对网站设计的时候,会遇到给用户“群发短信”,“订单系统有大量的日志”,“秒杀设计”等,服务器没法处理这种瞬间迸发的压力,这种情况要保证系统正常有效的使用,就需要“消息队列”的帮助。...
  • Java+MySQL版本的站内通知系统设计与实现 一、概述: 在B/S系统的设计与实现中,通知系统的开发是必不可少的一部分。在很多情况下,我们都需要使用通知这个提醒功能,比如,我们写了一篇文章,发了一个动态,这...
  • 微服务子系统调用消息通知机制

    千次阅读 2018-11-30 11:11:27
    微服务子系统调用消息通知机制 欢迎使用Markdown编辑器 你好! 这是你第一次使用 Markdown编辑器 所展示的欢迎页。如果你想学习如何使用Markdown编辑器, 可以仔细阅读这篇文章,了解一下Markdown的基本语法知识。 ...
  • Redis消息通知系统的实现

    万次阅读 2012-04-12 18:34:23
    Redis消息通知系统的实现Posted on 2012-02-29 by 老王 http://huoding.com/2012/02/29/146最近忙着用Redis实现一个消息通知系统,今天大概总结了一下技术细节,其中演示代码如果没有特殊说明,使用的都是PhpRedis...
  • [转]Redis消息通知系统的实现

    千次阅读 2012-03-17 21:49:01
    最近忙着用Redis实现一个消息通知系统,今天大概总结了一下技术细节,其中演示代码如果没有特殊说明,使用的都是PhpRedis扩展来实现的。 内存 比如要推送一条全局消息,如果真的给所有用户都推送一遍的话...
  • WebSocket+RabbitMQ实现消息推送系统

    千次阅读 2021-09-18 02:44:08
    一、用户获取新的消息通知有两种模式 上线登录后向系统主动索取 在线时系统向接收者主动推送新消息 设想下,用户的通知消息和新通知提醒数据都放在数据库中,数据库的读写操作频繁。如果消息量大,DB...
  • Web网站通知系统设计

    千次阅读 2014-07-25 09:40:45
    写在前面: 通知系统是网站信息传播机制的重要的一部分,足够写一大章来说明。本文只梳理设计原则,后续相关内容会持续更新。 这里的通知包括但不限于公告、提醒或消息(不同使用场景下的功能定义不同)。 关于各...
  • 官方描述: 用一个 Tray 来表示一个图标,这个图标处于正在运行的系统通知区,通常被添加到一个 context menu 上. 用 new Tray('/path/to/my/icon'); 创建一个与image相关的图标 给该图标绑定click事件, 单击该...
  • Java消息系统简单设计与实现

    千次阅读 2019-01-08 19:37:26
    前言:由于导师在我的毕设项目里加了消息系统(本来想水水就过的..),没办法...来稍微研究研究吧..简单简单... 需求分析 我的毕设是一个博客系统,类似于简书这样的,所以消息系统也类似,在用户的消息里包含了有...
  • V站需要增加3种消息提醒系统。需要实现的功能如下: 1.评论提醒。 实现功能 他人回复自己后,右上角自动提醒“未阅读的新消息”的数量。 点击后,清空新消息的提示。 思路 这个是最简单的。在数据库查询: ...
  • Android 监听系统消息通知事件

    千次阅读 2018-03-24 14:48:03
    0. 学习文章 参考了下面Blog 完全没有任何多余的代码 ...原来百度卫士的通知栏收纳是类似这样的原理完成的,很不错. 1.演示结果 数据源头 监听到的log 03-24 14:37:04.264 6155-6155/com.lava.noticeobser ...
  • Android消息通知

    万次阅读 2018-04-09 17:45:30
    日常生活中,相信很多人都会有这样的经历,每天手机都会收到一些来自不同来源app的一些消息,显示与状态栏,下拉即可查看,甚至可以点击进行调转到相应app界面, ... 跟Android中的api结合起来,通知消息...
  • 前端做消息通知

    千次阅读 2019-09-10 14:57:57
    1、消息通知,原生一些用webScoket 2、收费的,可以使用goeasy,http://www.goeasy.io/cn/doc/event/event.html 查看文档,事件与监听器即可
  • 消息通知栏demo

    2014-12-22 23:04:47
    以下为程序启动流程: 1.开机启动AlarmService 2.AlarmActivity一秒后发送一条系统广播 ...5.单击消息,取消通知栏信息 6.但程序关闭时,单击消息,重启程序 小知识:BroadCast、Service、Notification,初学者适用
  • 局域网通知系统消息群发)

    千次阅读 2011-08-05 17:01:12
    针对这种情况,自主开发了一个局域网通知系统。 本程序分为客户端和主机。主机可以发出通知,只要局域网内的电脑配置了客户端就可以收到通知。这个通知是强制显示在电脑屏幕中间的,绝对不用担心看不到!如图: ...
  • 二、Jenkins设置系统消息 三、Jenkins设置邮件通知 四、Jenkins设置扩展的电子邮件通知 一、Jenkins环境搭建 参考我的另一博文:【Jenkins】Jenkins+maven+git搭建项目自动化部署集成环境: ...
  • 一个websocket消息通知案例

    千次阅读 热门讨论 2019-01-11 09:33:09
    消息通知是服务器主动向客户发送消息,可以使用另一个用户模拟后台下载任务完成给888888用户发送消息,不嫌麻烦可以写定时任务测试 ()">测试 function refMessage(){ $.ajax({ type: "GET",dataType: "STRING...
  • Android通知栏微技巧,8.0系统通知栏的适配

    万次阅读 多人点赞 2018-04-17 07:39:11
    大家好,今天我们继续来学习Android 8.0系统的适配。...在上一篇文章当中,我们学习了Android 8.0系统应用图标的适配,那么本篇文章,我们自然要将重点放在通知栏上面了,学习一下Android 8.0系统通知栏适配
  • 网站消息通知设计

    千次阅读 2019-06-13 14:54:21
    通知系统是一个成熟的 web 网站或者 app 最基本的功能,比如微博、知乎、掘金等。当然今天本文要讨论的不是这种大网站、大流量的通知系统,而是一般用户量的网站或者应用。 通知系统的组成 一个通知系统主要由:通知...
  • 消息中间件MQ与RabbitMQ面试题(2020最新版)

    万次阅读 多人点赞 2020-03-01 11:11:21
    MQ的优点消息队列有什么优缺点?RabbitMQ有什么优缺点?你们公司生产环境用的是什么消息中间件?Kafka、ActiveMQ、RabbitMQ、RocketMQ 有什么优缺点?MQ 有哪些常见问题?如何解决这些问题?什么是RabbitMQ?...
  • 添加系统框架: #import &lt;AudioToolbox/AudioToolbox.h&gt;...2.消息声音 2.1 系统声音 AudioServicesPlaySystemSound(1007); 其中1007是系统声音的编号,其他的可用编号: iphone...
  • 参考地址: https://blog.csdn.net/DamonREN/article/details/83339636 ... 案例一: 多种消息提醒系统的设计模式、实现方案(附功能截图+表结构) 2018-09-25 08:28:59黑夜的风阅读数 982...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 338,798
精华内容 135,519
关键字:

消息通知系统