推荐学习书目
› Learn Python the Hard Way
Python Sites
› PyPI - Python Package Index
› http://diveintopython.org/toc/index.html
› Pocoo
值得关注的项目
› PyPy
› Celery
› Jinja2
› Read the Docs
› gevent
› pyenv
› virtualenv
› Stackless Python
› Beautiful Soup
› 结巴中文分词
› Green Unicorn
› Sentry
› Shovel
› Pyflakes
› pytest
Python 编程
› pep8 Checker
Styles
› PEP 8
› Google Python Style Guide
› Code Style from The Hitchhiker's Guide
这是一个创建于 3322 天前的主题，其中的信息可能已经有所发展或是发生改变。
我们后台的大部分 sever ，都是类似于收单系统的业务。
既会接受下单请求进行处理，在处理完成后，要么等其它服务自己主动轮询订单状态，要么将处理成功的通知推送给下单请求时带来的 notify_url 。
那么对于通知 notify_url 的这一实现，公司内部的实现五花八门。
1.有些通过在修改状态的那一刻，直接通过 http 发送消息。
2.有些起一个定时任务，每隔一段时间扫描，未发送的消息，将其发送并改为已发送。（也就是说，消息发送的状态字段也包括在订单表中）
3.还有专门丢给一个消息系统，由它负责发送和错误后的重发。（消息的状态与订单状态分开）
那么我想请教一下，什么样的做法，才是合理，专业的做法。而不是野路子。
(目前使用到的语言是 python ，数据库 mysql ， web 框架 tornado 和定时任务 apscheduler 。)
3 条回复 • 2015-10-31 13:58:24 +08:00
 |
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 才是靠谱的，第一个肯定会出问题，第二个实时性不够
|
Select Language