[2012站庆技术讨论]：如何设计分布式异步事件处理系统？（获奖名单已公布-12-26）

xujg

回复 39# yifangyou

这两句没看出来说改造了TCP.

而且, "比TCP快"也是有前提的.
   

asdmonster

抛砖引玉,希望参与的热情能够混本书哈

在大容量，高并发的业务请求下，如何处理费力费资源的服务请求而不阻塞住，从而耽误其他的服务，如何能快速响应即时业务需求，例如，充值，就发短信通知等等。这些服务请求极有可能又分布在不同的服务器上，那如何处理这些分布式的请求呢。 那我们是否可以建立一个分布式的异步事件处理服务呢。
---------------------------------------
这个冲值发短信/通知的例子并不显著的分布式的例子,如果我来描述分布式的需求大致是这样:在1秒钟内有1000万个冲值请求,但是每台服务器仅能够在1秒内处理10条这样的请求,所以,分布式的需求就这样产生了.
所谓的异步请求是:充值需要10分钟才能处理完,用户不会等待10分钟,于是,异步,提交了任务以后,用户可以同时去做别的事情.
我觉得二者并不冲突,可以分别设计满足其需求,对于分布式,重要的是任务的调度,单点错误的容忍性,最终结果的正确性一致性这些,对于异步系统,无非就是建立等待队列,任务分发,任务结果分发或者回调什么的.这里面的每项技术,都不复杂.

分布式异步事件处理是在例如处理不同事务的服务器通过网络进行通信的分布式通信环境下，发送端发出承载消息的事件后不必等待接收端应答就继续执行。而接收端在接收到事件之后采用异步的方式来处理事件。分布式异步事件处理解决了发送端必须等待接收端处理完毕事件后才能继续执行的问题，也解决了接收端并发处理多个发送端请求的事件的性能瓶颈问题，因此显著提高了事件处理的效率。
-------------------------------------------
其实画一张逻辑的拓扑图,就很容易的看到系统的瓶颈(即多个任务需要最终同步的地方).一般而言,瓶颈无非是两个地方:前端接收请求,后端汇总结果这两个点.优化策略嘛,无非就是将最终只能单步的任务尽可能的简化呗.
需要提到一点的是,有些分布式系统号称它的拓扑图中所有的实例地位对等,也就没有了我上面描述的那两个瓶颈,但是据说也有个物理学家证明,这样的系统,理论上是不存在的.我更倾向于后者的观点.

在分布式异步事件处理系统中，因为异步无等待，由于发送端没有等待接收端的反馈就继续执行，那开发者又能如何知道服务是否已执行完成呢？若是异步事件处理服务挂掉了，又怎么能让没有成功执行的事件重入呢？
--------------------------------------------
基本上也就是注册/通知机制，当然，细节点，可能还有些什么任务序列化/调度等的问题。
更准确地说，除非整个服务器或者其master节点（群）down机，这个是灾难性的，在正常运行时，分布式系统需要处理的是，参与分布式的某个节点故障的时候，将该节点的任务转移到别的有效节点的问题。还有在启动/灾难恢复时，如何选举出仲裁者的问题。
对于分布式系统中的实例特别是实际的工作实例而言，它不关心自己是同步还是异步的，它需要做的是，将系统现有的任务，按着既定的调度策略执行完。同步还是异步，是接口考虑的问题，也仅仅是接口需要考虑的问题。

crazyhadoop

回复 37# propsyche


    方法很不错，scribe是个好东西，不过还是有些弱，syslog可以考虑一下

pitonas

太专业了

tulip0425

呵呵,谢谢楼主了~~~~~~~~~~~