如何合理的在通知服务器?

2015-10-31 12:00:37 +08:00
 aiqier

我们后台的大部分 sever ,都是类似于收单系统的业务。

既会接受下单请求进行处理,在处理完成后,要么等其它服务自己主动轮询订单状态,要么将处理成功的通知推送给下单请求时带来的 notify_url 。

那么对于通知 notify_url 的这一实现,公司内部的实现五花八门。
1.有些通过在修改状态的那一刻,直接通过 http 发送消息。
2.有些起一个定时任务,每隔一段时间扫描,未发送的消息,将其发送并改为已发送。(也就是说,消息发送的状态字段也包括在订单表中)
3.还有专门丢给一个消息系统,由它负责发送和错误后的重发。(消息的状态与订单状态分开)

那么我想请教一下,什么样的做法,才是合理,专业的做法。而不是野路子。
(目前使用到的语言是 python ,数据库 mysql , web 框架 tornado 和定时任务 apscheduler 。)

2248 次点击
所在节点    Python
3 条回复
wind4
2015-10-31 12:38:01 +08:00
方法 1 的实时性比较高,但是如果 http timeout 就会丢失状态,再使用方法 2 定时检查一下会更保险一些。
GeekGao
2015-10-31 13:25:55 +08:00
还是用靠谱点的 message queue 来得容易,实现 subscriber 和 publisher 的解耦,而且还能做到跨平台跨语言
xujif
2015-10-31 13:58:24 +08:00
只有 3 才是靠谱的,第一个肯定会出问题,第二个实时性不够

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/232472

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX