我们正在实施对应用程序中的Mailgun事件跟踪的支持。我们审核了提议的event polling algorithm,但发现自己对此不太满意。首先,我们不希望丢弃我们已经获取的数据,然后在暂停后从头开始重试。它不是很有效,并且为一个长循环的重试留下了一扇门,因为它不清楚循环应该何时结束。其次,“门槛年龄”似乎是确定“可信度”的关键,但其价值没有定义,只建议一个非常大的“半小时”。
我们的理解是,事件在一些阈值延迟后变得“值得信赖”,当事件被保证驻留在事件存储中时,我们称之为D_max
。如果是这样,我们可以用不同的方式实现这个算法,这样我们就不会获取我们知道不“值得信赖”的数据并利用已经获取的所有数据。
我们会定期获取数据,并且每次迭代我们都会:
T_1
到T_2 = now() - D_max
的升序时间范围。对于第一次迭代,T_1
可以设置为过去的某个时间,例如,半小时前。对于后续迭代,T_1
设置为上一次迭代的T_2
值。我的问题是:
D_max
的最低现实价值是多少?显然,我们可以使用“半小时”,但我们希望在跟踪事件时更加敏捷,因此知道我们可以设置的最小值是什么并且仍可靠地获取所有事件将是很好的。 / LI>
谢谢!
答案 0 :(得分:1)
1:我发现这个解决方案没有问题(事实上我正在做一些非常相似的事情)。我还存储事件的ID以验证我没有插入重复的条目。
2:我一直在努力完成这个类似的过程。现在我正在用10分钟的D_max进行测试。
此外,在进行测试过程中,我每晚都会运行一项额外的任务,这可以追溯到一整天,以验证一些事情: