我们后台的大部分 sever ,都是类似于收单系统的业务。
既会接受下单请求进行处理,在处理完成后,要么等其它服务自己主动轮询订单状态,要么将处理成功的通知推送给下单请求时带来的 notify_url 。
那么对于通知 notify_url 的这一实现,公司内部的实现五花八门。
1.有些通过在修改状态的那一刻,直接通过 http 发送消息。
2.有些起一个定时任务,每隔一段时间扫描,未发送的消息,将其发送并改为已发送。(也就是说,消息发送的状态字段也包括在订单表中)
3.还有专门丢给一个消息系统,由它负责发送和错误后的重发。(消息的状态与订单状态分开)
那么我想请教一下,什么样的做法,才是合理,专业的做法。而不是野路子。
(目前使用到的语言是 python ,数据库 mysql , web 框架 tornado 和定时任务 apscheduler 。)
1
wind4 2015-10-31 12:38:01 +08:00
方法 1 的实时性比较高,但是如果 http timeout 就会丢失状态,再使用方法 2 定时检查一下会更保险一些。
|
2
GeekGao 2015-10-31 13:25:55 +08:00
还是用靠谱点的 message queue 来得容易,实现 subscriber 和 publisher 的解耦,而且还能做到跨平台跨语言
|
3
xujif 2015-10-31 13:58:24 +08:00 via iPhone
只有 3 才是靠谱的,第一个肯定会出问题,第二个实时性不够
|