多谢G_will, 见行间回复.
On Friday, December 5, 2014 7:14:42 PM UTC+8, G_will wrote:
读了的文章我有一些疑问：
你说你的业务是计算密集型，但不理解的是你们的业务需是要一个计算结果的返回，还是只是下达一个计算的任务，http的回应只是服务器说好的“任务收到我去计算了”？
需要在响应里返回计算结果, 的确没说清, 稍后会修改文章
如果你们需要返回计算结果，那么你所展示的架构看上去是不合理的：
你利用单 nginx worker + fork ，我猜测是为了利用多核。但实际上直接利用多个 worker nginx 就可以利用多核了，直接在 lua 里用 ffi 调用 c 代码就可以很好的实现你们的需求了。这样还省去了多余的 tcp 通信开销。
为了利用多核, 有些细节没讲到造成误解了, 这里没有使用多nginx worker的原因是:
1. 与客户端的通信的协议是websocket, 需要计算的数据是边接收边处理, 处理过程中还会有一些临时结果需要实时返回给客户端, 这样计算和网络IO放在一起会冲突.
2. 需要对计算进程有更灵活的控制, 比如某个计算耗时异常时需要强行kill, 某个计算进程crash时的特殊处理.
3. 需要在init_worker_by_lua里异步加载10GB级的只读计算资源到内存, 这样这些只读资源可以和fork出来的计算进程共享, 而目前版本init_by_lua还不支持ngx.timer.at或其它方式来异步加载资源. (已在ngx_lua计划中, 后续版本会支持)
4. ffi很强大, 因为有的计算模块不仅要运行在服务器还有可能运行在没有luajit的移动app里, 为了保证接口一致, 目前是全部做了lua绑定, 并提供一致的lua接口, 需要再优化时会考虑ffi
如果你们不需要计算结果，只需要下达计算任务，那这个架构也不合理：
直接后面接一个消息队列就好了。
总之，觉得你的架构设计过度了。
