[2012站庆技术讨论]：如何设计分布式异步事件处理系统？（获奖名单已公布-12-26）
获奖名单已公布，详情请看：http://bbs.chinaunix.net/thread-4060812-1-1.html站庆活动：
2012站庆活动拉开大幕，欢迎大家积极参与！所有参与ChinaUnix社区11周年站庆的朋友，都有机会获得站庆定制礼品一份！
话题背景：
在大容量，高并发的业务请求下，如何处理费力费资源的服务请求而不阻塞住，从而耽误其他的服务，如何能快速响应即时业务需求，例如，充值，就发短信通知等等。这些服务请求极有可能又分布在不同的服务器上，那如何处理这些分布式的请求呢。 那我们是否可以建立一个分布式的异步事件处理服务呢。
分布式异步事件处理是在例如处理不同事务的服务器通过网络进行通信的分布式通信环境下，发送端发出承载消息的事件后不必等待接收端应答就继续执行。而接收端在接收到事件之后采用异步的方式来处理事件。分布式异步事件处理解决了发送端必须等待接收端处理完毕事件后才能继续执行的问题，也解决了接收端并发处理多个发送端请求的事件的性能瓶颈问题，因此显著提高了事件处理的效率。
在分布式异步事件处理系统中，因为异步无等待，由于发送端没有等待接收端的反馈就继续执行，那开发者又能如何知道服务是否已执行完成呢？若是异步事件处理服务挂掉了，又怎么能让没有成功执行的事件重入呢？
讨论话题：
现实中，你会如何设计这样的一个系统呢？
邀请嘉宾：
happy_fish100：分布式文件系统版版主，FastDFS文件系统作者
crazyhadoop：Linux环境编程版版主
T-Bagwell：嵌入式开发版版主
活动时间：
2012.11.16-2012.12.06
活动要求：
1，针对本次话题说说您对分布式异步处理系统的理解
2，分享您在开发、部署和运维这些异步处理系统中的经验
讨论有奖：
活动结束后，我们会评选出四位积极参与话题讨论的网友奖励分布式系统：概念与设计（英文版·第5版）图书一本，对其他积极参与讨论的网友（回帖有参考价值）我们将奖励积分20分。
图书简介：
原书名： Distributed Systems：Concepts and Design，Fifth Edition
原出版社： Addison-Wesley; 5 edition
作者： (英)Jean Dollimore George Coulouris Tim Kindberg Gordon Blair
丛书名： 经典原版书库
出版社：机械工业出版社
ISBN：9787111397724
上架时间：2012-10-29
出版日期：2012 年10月 分布式架构有点太大了, 我们还是主要关注基础服务集群方面的开发技术吧...
1, 服务端微架构上我们是完全可以实现: 单线程 + 异步 +等待但不阻塞的事件框架的, 从nginx/lighttpd的异步事件框架如何与fcgi module协调工作就可以掌握其原理, 所以我们是有能力开发一个逻辑中转服务端, 作为一个反向代理进行工作, 保证请求的接入->转发到具体业务服务端->从业务服务端接受应答->将应答转发回客户端.
2, 在1)的基础上, 并不是所有业务都可以实现立即响应, 可能有的事情要处理1小时, 我们不能借助1中的实现手段解决此类问题, 因为客户端并不一定喜欢阻塞1小时等待你的应答, 虽然我们的服务端有能力异步的接入足够多的并发请求.
这时候, 如果我们能够给客户端提供推送通知或者提供询问接口是一种常用设计, 还是要提到买火车票的问题, 铁道部都会用买票排队这种手段降低DB的负载, 何况我们...
我们需要借助高效的中间件来完成一些事情, 在这方面我们主要是架构师, 不是码农...(说出来都嫌丢脸..)
比如我们都知道用消息队列, java用activemq... c(python/php)用zeromq, rabbitmq, memcacheq...
消息队列是干嘛的? 容量无限(可持久化到磁盘), 没有关系型数据库的复杂所以读写效率高(一个queue一个queue, 能有多复杂呢), 支持订阅与发布模型很容易扩展, 等等.
借助消息队列, 我们可以简化编程, 开发生产者, 开发消费者, 消费者完成业务逻辑并通知客户端(客户端开个端口监听不就得了?)/存DB, 所以还是挺好玩的.
3, 还有种模型, 就是XMPP这种天生聪颖的协议+jabberd2这种天生聪颖的架构了. 如果客户端始终维持一个到服务端的长连接来发送命令和读取应答, 那么前两种方案弱爆了, 我们不如把业务迁移到XMPP集群中去, 我们只要开发服务型的客户端连接到XMPP集群, 就可以为客户端型的客户端提供发布与订阅(新闻推送?), 或者普通的一问一答了, 因为客户端是长连接的特点, 谁也没强迫谁要在多少时间内应答, 就算不答又怎样? 在XMPP里, 请求和应答从来都不是"一问一答"的, 所以这真的是种特殊的工作模式, 并且很常见, 比如IM. 太底层了,没接触过,友情支持下 回复 2# linux_c_py_php
你们很多技术都太专业了，能分享一下一些基础平台的信息么？
前端用的什么服务器，apache/nginx或者自己定制的，大约部署了多少台这样的机器？
还有主要的开发语言，开发出来的事件处理系统负责了什么业务逻辑，（我很菜，对大型系统架构不熟悉），为什么传统的架构模型就不能胜任了呢（遇到了什么瓶颈）？
后端用到nosql没有，目前平台大约部署了多少台数据库机器？？
就包括机器配置，面临的业务数据量，也可以分享一下的。这也重要，至少让别人了解一下环境，然后再了解具体采取了的措施。 回复 3# chenyx
这个人很牛的，{:3_188:} 分布式一个很大的问题是信息同步，要尽量减少同步的数据量，还要保证同步的及时性。
一种办法是让客户端尽量在一个服务器上被服务，减少服务器间的切换，这可能需要在客户端方面做一定的配合。
业务性质不同，对架构影响很大。如有的业务客户端发送请求一段时间之后没收到结果可以重复发起请求，但有的不行，必须先查询之前的结果，再决定是否重发。有的对可靠性要求高，如服务器收到应答，已反馈客户端已经收到请求之后，即使服务器宕机，也得想办法恢复该请求，这要求服务器有可靠的持久化、备份措施。
同样是分布式异步事件处理系统，架构可能是千差万别 apache traffic server前身是雅虎收购的inktom公司的traffic server，人家大约10年前就实现了异步事件处理，即事件驱动框架。
apache traffic server支持cluster模式，对URL采用一致性hash来分布。 很牛逼。。。。。。。。。。。。 抛砖引玉~分布式异步事件处理系统应该可以专注的处理多方的事件且不影响别人，微侵入，高性能。
那么事件是什么样子的呢？
1. 类似消息通知的，有些要求及时传递，比如qq上线通知，有些可以忽略，比如好友写了新日志
2. 不可重入的事件，充值加积分，这样的事件发生了，相应的积分加且只能加一次，要求精准处理
3. 多方关注的事件，例如充值50Q币，可能很多业务逻辑都要发生动作，会员会xx，VIP系统会xxx，礼物系统会XXX
4. 可重入的事件，比如在线时长加积分
5. 耗费时间的事件，如发送1亿份邮件，或者抓取10亿张图，只关注结果，不关注过程，事件丢一点也没有关系
这样看来，用一个队列存储这些任务比较合适，根据事件的类型和数量，可能堆实现的优先级队列效率会更高一点。查询某个任务
效率会极大的提高。
提到持久化，可以用binlog日志去记录这些事件，一旦当队列暂时崩溃，重新启动就可以恢复工作。这也是数据库事务系统常用
的一致性解决方法。
队列可以只是做简单的工作，存储数据就好了，亦可以实现一些调度的功能，例如gearman这样的集队列和调度为一身。
或者用redis的数据结构搞起，外包一个事件处理调度框架，这样可以自由的做很多事情。
既然是分布式，那就还能处理多方请求，那如何收集呢？为了降低复杂度，提高可靠性，用日志收集处理的方法是
一个可行的选择。所有的发生的事件记录统一的格式，然后多机可以路由到同一台机器，然后再用一个分析程序
去分析这些事件，灌入队列。
事件任务被分配以后，又如何知晓事件是否做好呢？ 可以考虑让处理的程序发个反馈。不过让业务反馈这实在是不友好，
那最好是能获取到处理程序执行任务的状态，事件处理系统自己反馈这个信息，然后根据自己的判断，这个任务下一步该
如何处理，是删除掉，还是继续推送。
其实方法很多。关键的一点是可靠性高，能做到万无一失最好了，就算是除了一些纰漏，能快速找到这些事件，再执行也
是可以的。 分布式系统好象应该建立在分布式计算上的吧