看到这个帖子忽然有冒出这个想法 http://v2ex.com/t/79923 .
也是因为最近搭建了个源站,才有一些想法(没有使用过BTsync,就刚刚google了下):
1:BTsync可以单向同步,也可以双向(应该只是允许单向才比较安全,从主站向下).也可以做到主源主动推送.
2:BTsync吸引人的是P2P.手里的源站总得准备多个上游,有些上游常常不稳定,监控邮件报警后,然后自动或手动更换.如果有P2P,就没有这个烦恼了,也可以充分利用带宽了.
3:另外同步需要的实时性,BTsync似乎不错,看了这个帖子 http://www.v2ex.com/t/75016
4:Ubuntu这类需要两步同步 等特殊需求,应该可以解决.
5*:不知道BTsync能不能保证文件的Link和一些文件属性.如果这个不满足,就只能kill这个idea了.
6:然后我想,源站同步都P2P了,这样使用者安装软件包的时候可不可以也P2P...
关注这个想法，感觉很有意思

记得很早之前看过 twitter 的一篇部署文章，就是用 p2p 协议部署海量服务器的

感觉BTsync的处理机制还是有点问题，好几次遇到剩余几个文件（很小）长时间不被同步。
尤其是经常被修改的文件，这个问题更加严重。


这个文章中提到 http://www.v2ex.com/t/75016
"bittorrent的P2P技术相当成熟，显然也被借鉴过来了，多复杂的网络环境，只要带宽够，文件更改后的响应最多3分钟。无论文件数量多或少，这个很让人心动。"

文件数量太多的话估计不行，上次用BTsync长时间占用cpu 估计是先扫描文件列表，最后直接卡死了。

rsync不好用吗？


如果有P2P,会更美好:D,看我的第2点.

facebook 就是bt 部署代码 http://os.51cto.com/art/201204/328615.htm

rsync 每次是单对单的，机器多的话，很累。

静态网站完全没问题，数据库的话不那么方便

发现一个东西：apt-p2p
http://www.camrdale.org/apt-p2p/

关注。。。。。。