效果如下图
image.png
本文主要介绍如何实现这种推送机制的技术方案
技术选型思路
定时调度数据库轮询
这种是很容易想到方案, 有点是简单粗暴, 缺点也同样明显, 效率低下, 适合在用户量很少的时候...最简单的时间轮, 可以拿钟表比喻, 比如有的任务固定在15分钟的时候触发, 那么这些任务就排队盯着15分钟这个维度, 等着时间点到, 就触发链表挨个调用函数, 如下图
[image.png]
上面的简单模型有一个问题...sofar so good, 直到有2个问题暴露出来,
一个就是官方文档提到的, reconnect的之后, 不保证可靠性, 这个监控显示有概率非常小发生, 不到十万分之一, 对比了机器的环境, 应该是和网络抖动有关...而key的的通知回调, 时间其实并不敏感, 我们的推送迟个几秒钟, 就算迟发1分钟, 其实也好好. 只要不是不发就行, 于是这个方案目前在成本和可靠性方面, 提供一个最优解.