转自：http://www.ylmf.net/linux/tips/2010122417687.html
rsync是用来做文件同步的一个很好的工具，传统的rsync就是使两个目录的文件保持一致，但随着文件数量增多，rsync会造成同步缓慢，系统负载比较高，直至系统死机。
为了解决文件增多导致rsync变慢的问题，方案是很多的。
1、使源目录保存较少文件
这是一个传统优化办法，因为rsync虽然是同步所有文件，但和同步最近更新的文件是一个道理，因此将源服务器上的目录删除，仅仅保持最近更新的文件，文件数量就变得不但很少，而且是稳定的，随着时间推移，这数量也不会涨得很快。但这样做有个缺点，就是rsync不能使用删除模式，如果有文件要删除，可以将其弄成空文件，假如有更严格要求，可以另一个程序来删除。
2、使用/dev/shm内存分区
在源目录保持较少文件的前提下，将文件不存在硬盘上而放入内存，就可以避免系统IO带来的问题，但是这个内存分区在系统reboot后会丢掉所有数据，虽然并不常常需要reboot，但是其中的风险也需要计算清楚。
3、使用推送方式
因为性能问题是出现在rsync的客户端，用生产服务器抓取源服务器的话，性能问题就会出现在生产服务器上，这当然不很妥当。假如在生产服务器上使用 rsync daemon，源服务器执行rsync命令将文件推送到生产服务器上，性能问题就转移到了源服务器上，这在一定程度可以保证生产服务器的稳定性。
4、仅用一台作同步比较
假如源服务器的文件要被同步到很多台生产服务器，那么会出现rsync并发。可以分析到这些生产服务器在同一时刻文件是一致的，因此每台机都和源服务器做一次比较就是浪费的。这时可以让源服务器和生产服务器同步一次，并且使用-v参数打印出log，其它生产服务器通过同步这个log记录的文件就可以避免数次比较过程。
5、使用inotify
inotify就不是rsync了，inotify是一个守护进程，它可以监控到文件目录下的文件变动情况，根据其输出然后用rsync做文件传输，就可以减掉文件比较这个环节。inotify使用并不复杂，对文件变更情况的监控是实时的，也不消耗很多性能。
6、双路同步
以上均是对rsync性能方面做优化，但是优化也会带来问题。在3、4、5号方案中，假如生产服务器有一台机器因为负载或其它问题reboot了，在 reboot过程中同步就失败了，这部分失败的文件假如没有其它处理，就永远不会再同步到生产服务器上。这时可以使用多一路rsync来处理，譬如使用 inotify，做到了实时同步，然后再每小时进行一次完整的rsync同步。这样就可以保证有很高的同步速度，又能使丢失文件的风险控制在一小时之内。
本文转自holy2009 51CTO博客，原文链接:http://blog.51cto.com/holy2010/550452
