dropbox的HTTP notification架构

lingyang

在PyCon上他们提到了特别设计的massive HTTP notification infrastructure， 用来解决超大规模客户端polling服务器的问题。有没有高手指点一下dropbox是怎么解决这个问题的， 思路也可以。


谢了，奉上今明两天所有的分数。

来打我啊

会有啥问题。。

lingyang

来打我啊 发表于 2013-1-4 11:20
会有啥问题。。

当你drop了一个文件以后，其他设备基本就是即时同步，每分钟dropbox接受超过了1百万个文件，如果算上要同步的终端，基本就是好几百万每分钟，我觉得不管是服务器主动通知设备还是设备轮询服务器都会是一个很繁重的任务，

手头有一个项目感觉又类似的挑战，就是想多了解一下他们解决这个问题的思路，

lingyang

等高手

psaux

个人觉得可能性比较大的架构是有个处理服务器集群，还有个负载均衡服务器集群（被动）。当drop action发生后，client跟负载均衡服务器集群进行对话（主动），再被分配去被选择的处理服务器，每台服务器上应该有多重线程进行实时监听。

我在centos上用beanstalkd做过一个类似的系统(c++)，当然我只用了一个load balancing sever， 2个processing servers，2个db servers，每台processing server上跑8个beanstalkd tubes，所以总共是有8个并行处理线程在run。当时我们大约有2000个clients在外部（中国，英国，澳大利亚），当初这个系统的设计就是能一天handle 20万的文件，但实际一天的文件（EDI）进量大约是3 - 4万，所以我觉得这个系统的处理还没完全被利用起来。BTW，这种架构的系统很容易扩展的。

lingyang

”当drop action发生后，client跟负载均衡服务器集群进行对话（主动），再被分配去被选择的处理服务器“
那如果大量的从客户端来的主动对话会造成DDOS类似的行为吧？

这个设计的效率如何，dropbox的同步速度真的很快，感觉一般的loadbalancer这种设计很难达到

psaux

我是用haproxy(http://haproxy.1wt.eu/)来做load balancer的。一般来说，单纯对访问做load balancing是不需要担心这个问题的（除非你的量太惊人，超出了我的认知），我用ab (http://httpd.apache.org/docs/2.2/programs/ab.html)给我们的load balancer做过测试，每5秒发5000个并行请求，连续发60秒，就load balancer来说没有任何压力，至于后台的处理那需要考虑到其他很多因素，没有可比性。

我用过dropbox在linux下的client，是用python写的，我看了一下代码，没看到有什么特殊的跟server的交互方式，所以我猜他们的server可能是跨地域的，你在澳洲做同步，在澳洲的server就给你处理了。

brahmasky

psaux 发表于 2013-1-4 12:07
个人觉得可能性比较大的架构是有个处理服务器集群，还有个负载均衡服务器集群（被动）。当drop action发生 ...

学习一下，再次感叹足迹高人太多了

清风拂山岗

" 那如果大量的从客户端来的主动对话会造成DDOS类似的行为吧？"
为什么要"主动对话"? Messaging应该效率更好吧。事实上，所有的通讯都可以建立在Messaging的基础上。

清风拂山岗

Messaging的好处是当并发量太大的时候，the whole system can run as far as it can, but not faster. 换句话说，当并发太大，系统仍然继续处理请求，不会彻底的瘫痪。通过实时监控Message Queue,你知道系统的瓶颈在哪里,然后进行相应的优化。

IsDonIsGood

学习兼感叹高人们都不穿好鞋啊~~~

lyingdragon

学习中。。。

joerkky

首先dropbox client上传肯定是主动连接的。然后notification这东西肯定是用message queue的。至于这个notification怎么发到client上去，是push还是pool, 这个取决于网络协议了。如果是keep-alive的协议，push notification是没问题的，否则就只能pull了。

具体思路是这样的：
1、client上传一个文件到web server, web server接收了文件之后发notification to the queue (dropzone queue).
2、application server收到这个notification, 这个client上传了文件，然后找出来哪些client需要被通知，然后对每个需要通知的client发一个notification进queue (process queue)
3、
如果是push: notification server查看process queue, 每一个notification，发送给对应的client
如果是pull: 把notification存数据库里，然后当client polling的时候，查询数据库看有没有notification.