背景：运营可以配置无上限的活动，在活动列表和详情中，用户可以进行关注，关注后需要在活动开始前 15 分钟向推送活动开始的通知消息。
当前方案：创建完活动之后向延迟队列中投递一个执行时间为（活动开始时间-15 分钟）的任务，目前关注用户存储在 redis 的 zset 中，向延迟队列中投递的是活动的 id 信息，延迟队列消费到这条消息的时候，从关注的用户 zset 中拉取用户 id 进行消息推送。
延迟队列的设计：目前是依赖 redis ，生产者向 redis 的 zset 中投递 task 信息，score 是活动的通知时间（活动开始时间-15 分钟），然后轮询这个 task 的 redis key ，读取到期是任务信息，读取到之后将该任务信息投递到 redis 的 list （通过 rpush ）中，消费者则一直读取这个 list 队列（通过 lpop ）。
目前想探讨的是：这个方案是否在活动很多的时候导致推送消息的延迟（虽然可以通过增加消费者来缓解，正常哪怕是一个活动有百万级别的活动关注者（极其罕见），从 redis 的 zset 中分页拉取出来并投递消息，一般处理时长不会超过 10 分钟）
但是隐隐约约还是觉得是不是还有更好的方案呢？可以尽量减少延迟的方案。