使用csync和lsyncd飞速同步数据.docVIP

在大型的网站架构中，通常会使用上多部网页服务器来组成server farm，并在前端架设负载均衡设备,例如F5,NetScaler,LVS,nginx等，以便随时根据访问量及服务器负载而增减服务器，达到高可用性的架构。 我公司中有一个对外的BBS，这个BBS由3台后端web服务器组成，前边是NetScaler做的负载均衡。因为访问量不大，出于成本的考虑，用户在BBS中上传的图片和附件都存在了web服务器的本地硬盘上。但因为做了负载均衡，那么必须保证后端的3台服务器上的文件都是一样的，否则用户访问时如果不是他上传的那台服务器就会找不到附件和图片。而且，因为无法预见到用户每次会上传到哪个服务器上，所以这些服务器之间必须互相同步以确保同一目录中的文件完全一致。 一般这样的需求都是采用rsync+inotify的方式同步的，我之前也写过一篇文档用lsyncd实现简单网站数据同步。但是这个BBS有点特殊，因为上传的文件虽然大小不大，但数量较多，而且都是5K左右的头像这类的图片，因此采用rsync+lsyncd的方式发现效率不行。因此，只有再次拜托google大神，找到这篇很棒的文档Lightning fast synchronization with csync2 and lsyncd,参考文中的方法解决了我的需求。 我在此把这位大牛的文章按我的理解重写整理了一下，写在这当个备忘，不过强烈推荐大家去看看原文。系统示意图参考下图。 按照原文的称呼，这3台服务器的hostname分别为: apollo,chronos,hermes。根据原文，作者之所以能做到飞快的同步大量文件，成功来源于两点: ? 1.csync2的节点之间采用了链状结构，而不是通常的网状交叉结构 2.作者编写了自己的lsyncd的配置脚本，修改了lsyncd的event call处理方式，从per-file方式改成了批量处理方式。 ? 那么为什么要采用链状的同步关系呢？假设我们采用普通的网状交叉结构的同步关系,让我们考虑如下的场景: ? 1) 用户上传一个文件test.gif到了apollo的 /var/www/html/images目录中 2)apollo上的lsyncd检测到onCreate inotify事件，触发启动csync2开始同步 3)csync2复制test.gif到所有其他节点上 4)几乎同一时间内 chronos上的lsyncd检测到自己的/var/www/html/images目录中的onCreate inotify事件，触发启动csync2开始同步 hermes上的lsyncd检测到自己的/var/www/html/images目录中的onCreate inotify事件，触发启动csync2开始同步 ? 这时chronos和hermes之间就产生了竞争条件，因为csync2的上传操作几乎瞬间就完成了。chronos和hermes之间会就谁的文件为最新产生竞争，经过一系列计算最终才会确定下来。如果每个文件都经历这样一个过程，那么可以想象，效率是多么的差劲。 ? 而所谓的链状结构如下图所示: 而在这种链状结构中，就解决了上边提到的竞争问题，因为数据只允许单向流动。 ? 1) 用户上传一个文件test.gif到了apollo的 /var/www/html/images目录中 2)apollo上的lsyncd检测到onCreate inotify事件，触发启动csync2开始同步 3)csync2复制test.gif到chronos上 4)chronos上的lsyncd检测到自己的/var/www/html/images目录中的onCreate inotify事件，触发启动csync2开始同步 5)csync2复制test.gif到hermes上 6) hermes上的lsyncd检测到自己的/var/www/html/images目录中的onCreate inotify事件，触发启动csync2开始同步 7)hermes想要复制test.gif到apollo上，但此时apollo上已经有了test.gif，经过比对以后，这个复制不会继续下去。 ? 大家可以看到，这种链状结构有效的避免了节点间的竞争关系，不过这种结构也有自己的缺点，那就是一旦其中某一台节点死机或csync2服务停止，则整个链条的完整就被打破，各节点间数据就会出现不同步。在这种情况下，我们只能修复好损坏的节点以后，手工强制同步一次。因此，是否能接受这样的损失，也是考虑采用这种链状结构的一个关键问题。 ? 另外，单纯采用链状结构只是改善了一点竞争问题，但是效率并没有特别显著的提升。为什么呢？这就涉及