postgresql - 设计简单的推送通知系统

需要一些关于实施推送通知系统的设计建议。我用于后端Symfony 3，Doctrine和postgres作为数据库。通知系统将有两种类型的通知： 1.即时通知 2.预定通知即时通知是指在后端执行操作并立即推送通知。例如，在数据库中删除用户时的通知。

预定通知适用于尚未触发但将来某个已知时间的通知。通知仅在达到设定时间时触发。例如闹钟。

基于此，我使用一些模拟数据设计了如下的简单表：

因此，根据以上信息，API概念在用户的设备（如手机）上，它将每2分钟运行一次GET /通知API。 API将返回当前日期之前的通知，但尚未针对该用户解除通知。例如，如果USER2在2017年4月18日执行当前日期的GET /通知，它将返回记录3.

我的问题是，如果不是传统做法，这种设计是否可以接受？此外，许多用户每隔2分钟运行相同的GET API，是否有可能减慢系统速度？我猜最多有3000个用户。

最后，随着通知表在记录中增长，执行此API时postgres会减慢吗？

谁曾经花时间阅读它一直感谢你，我非常感谢任何建议。

推送通知。

如果您的客户端设备通过GET API调用请求通知，则不称为推送通知。由于所有用户可能没有那么多通知，因此在服务器端处理太多不必要的请求将会非常繁重。

你不应该让你的客户打电话。您应该将通知推送到客户端。可以将iOS和Android个应用配置为通过deviceId和uuid获取推送通知。请咨询您的移动开发人员。这些天甚至HTML5浏览器都支持推送通知。

存储：

我认为您根本不必将instant push notifications存储在数据库中，除非您有应用程序级别要求存储日志。

您应该只存储scheduled notifications，以便Cron job可以在到期时选择并推送这些通知。

希望这有帮助！