服务器端周期提醒如何设计

Question

为了活跃App,运营那边提出需要实现一个提醒功能，大概需求就是到了用户设置的提醒时间，打开APP，方便用户记录。

用户可以设置重复的时间，就像闹钟一样，可以自己定义哪几天需要提醒。

现在我的困惑是，这个数据库如何设计呢？怎么设计会比较方便且容易扩展，我是打算后台用定时任务去轮询，发现有需要提醒的，然后服务器就发推送通知给APP

Answer 1

数据库设计--下一次提醒时间，重复的时间，特定时间

到时间发送通知，然后更新数据库的下一次提醒时间

Answer 2

使用quartz来定时，数据库设定触发时间和触发次数

Answer 3

分析需求:

1. 有三种模式:礼拜提醒;日期提醒;隔天重复提醒;

2. 每种模式都有自己的提醒时间点

存在疑问:
如果模式冲突,优先级如何？

表设计

1. 一共三张表,模式表;时间点表;结果表.模式表和时间点表关系为1对多,结果表为提醒信息

2. 考虑模式表上的设置的时间不会作为搜索条件,可以将模式表里面的时间存为JSON(这里需要限制日期提醒,允许设置最大个数)

优化方案
如果按照题主说的,定时任务轮询,当数据量很大,并且提示时间密度很小的时候,提醒时间差度会有点大,并且对数据库也是一个不小的负担.

1. 在每个礼拜六或者礼拜天,根据模式表和时间点表生成第三天的提醒条目放入结果库(条目状态为待提醒),当用户修改了提醒时间,直接删除该账号对应的提醒条目,并且重新生成(考虑到用户修改的频率不会很频繁)

2. 当push成功以后,发送一个消息,监听到消息以后将提醒条目状态修改为已提醒

3. 定时器扫描到数据以后,需要先将数据更新为提醒中,防止在push回调过程中该条记录被删除

需要考虑的问题

1. 当把状态更新为提醒中,但是push消息失败如何处理

2. 如果发生某些异常情况导致提醒条目结果没有正确生成,怎么能快速发现

3. 其实定时器扫库的方式时效性不是很高

4. 主要难点个人觉得是,用户修改条目而引起的数据更新和边界问题