基于TIme的通知体系结构 [英] TIme-based Notification Architecture

问题描述

我正在设计一个通知服务(服务器).我可以有两种通知:一种立即发送，另一种在将来的某个时间发送.

是否有处理未来通知的框架?

我知道我可以写后台工作人员，例如可以对数据库进行采样以查找需要发送的通知，但是我确定已经有数百万人尝试解决此问题，并且我希望重用经过验证的解决方案./p>

我还没有决定框架/数据库.我想我应该使用vertx.io或Jetty(WebSockets)进行推送通知.对于DB，我不确定，因为我希望它支持那些将来的通知.

更新: 您将如何建议我将数据保存在数据库中以用于实时"通知(用户收件箱中存在的通知)以及将来的通知?

更新: 我在考虑使用其中一种:

1. Jetty + Spring for WebSocket和SockJS +石英
2. Vertx.io(支持Websocket和Sockjs)

有什么建议吗?

解决方案

一种方法是将通知传递到计划组件.计划组件将使用所有通知，将其存储并定期检查以查看是否应发送通知.

这将允许将侦听器附加到通知，而不是在发布者侧堆积通知.

I am designing a notification service (server). I can have two kinds of notifications: one which is delivered immediately, and the other is delivered at some time in the future.

Is there a framework to handle the future notifications?

I know I can write background worker who can for example sample the DB to look for a notification which needs to be sent, but I sure millions tried to solve this problem already and I'd prefer to reuse a proven solution.

I didn't decide yet on the framework / DB. I am thinking I should use either vertx.io or Jetty (WebSockets) for push notification. I am not sure regarding the DB because I wanted it to support those future notifications.

Update: How will you recommend I should save the data in DB for "live" notifications (notifications which exists in the users inbox) and for future notifications?

Update: I am thinking of using either:

1. Jetty + Spring for WebSocket & SockJS + Quartz
2. Vertx.io (Supports Websocket and Sockjs)

Any recommendation?

解决方案

One approach is to deliver the notifications to a Scheduling component. The scheduling component consumes all notifications, stores it and checks regularly to see if a notification is due to be sent out.

This will allow to attach a listener to the notifications and not pile up the notifications at publisher side.

这篇关于基于TIme的通知体系结构的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！