标题不知道怎么拟定比较好，总之是讲Promise的吧，基本上算是第一次讲Promise，以前Rails+Angular的时候曾经说过，不过那个时候对于callback hell和Promise解决的东西理解的并不深刻，所以解释的也很肤浅（不明明这次依旧是肤浅的解释）。
首先……V8的Promise性能实在不靠谱，都没有第三方的快，bluebird有一篇性能比较（反正大致是想说自己快吧）：http://bluebirdjs.com/docs/benchmarks.html
慢归慢，基本上一些对于性能需求不太迫切的项目还是可以用自带的Promise的，Node6对于ES6的支持已经相当全面了，这一点可以用npm install es-checker检查一下。（毕竟回调地狱恶心到吐血）。
好了，这一篇我们顺着上面几篇的思路来说说rsync，所有的内容在参考链接中都可以看到更详细应该也是更有深度的说明……
如果你在寻找一个差异同步上传机制，那么rsync就是你想要的，在目录中选择性拷贝，安全保障，提供多种传输方式，具体的功能可以从之后的介绍和扩展阅读中看出。
酷壳有一篇介绍，不过一些名词介绍的比较让人郁闷，先给个总结：rsync = 分块hash check + 滑动窗口。
在上一篇中我们介绍了一下pull、push模型，除了在网页获取数据时用得上以外，其实还有很多应用场景（甚至可以说处处都见得到），在这次第一个正式工作，是写一个同步发布脚本，因此也了解了一些常见的同步方案，其中包括了运用这两种不同模型的几种选择。
这是目前在使用的解决方案，Rsync的介绍与配置留在下一篇博客，Git只是负责从远程获取到最新的代码到源机器（把上一篇文章的服务器看做源机器，客户端看做目标机器即可），Rsync负责差异同步到目标机器。这套方案比较简单，缺点是太简单，没有后续方案的话失败需要手动回滚到上一版，后续搭配SSH自动或人工食用。（除了我们以外Teambiton似乎也有开源的解决方案sneaky）。
在上一个消息路由设计中，大概也有提到过关于pull和push的问题，但没有细说，我们在设计模式中，也就是观察者模式（也叫订阅发布模型）中，也遇到过相同的问题，那么push与pull到底有什么差别？
首先我们来确定一下定义：push（推），主动推送，换言之也就是从服务器发出请求给客户端，客户端接收数据，pull（拉），被动拉取，换言之，客户端去请求服务端，获取服务端的数据。
平时其实也很常见，如果我们网站的数据需要实时动态更新，此时我们有两种解决方案，一种Ajax轮询，从客户端的角度来说，我们可以看做把消息定时的拉下来，而另一种是WebSocket，当服务端生产出消息后，推送到客户端，实时性很强。
这学期做的一个作业，稍微总结一下自己的设计思路，顺便读了一篇美团技术部门写的《消息队列设计精要》，深感做一个消息队列的复杂程度。
简单介绍一下，我的消息路由开源中，但除了学习之中没有什么卵用（这篇文章也不会讲代码的实现，主要是设计思路），之所以这样是考虑到整个系统的开发难度进行了取舍，之后也会说到：https://github.com/csvwolf/Sky_Message_Routing_Middleware
我们要做的东西简单的来说英文是Message Router，也就是消息路由，实际上也就是没什么卵用的转发器，尤其是小规模的情况下——整体而言是一个问答系统，我们有3个前端，一个后端，在这种规模下，似乎确实没有什么意思，只能自己虚拟情况了。