流程描述：

懒得找图了，直接文字说明。详细的异常处理逻辑太多了，此处省去N千字，如果需要可以联系我:)（如，po机器死机、po网络中断、po下载过慢、避免单个po压力过大、避免master相对较闲等处理逻辑）

1. 假设master控制3个po程序，将数据分成N块，然后将这些数据块分成3（按照下游po的数量）个数据块组。
2. master生成种子信息，并连接CAC获取本次传输需要连接的po信息及相关配置。
3. CAC授权本次传输，并生成随机的密钥。master通过获取的密钥，连接正确的po。
4. po连接CAC验证密钥正确性后，本次传输开始
5. po1第一次从tr获取第一个数据块组。第一次接收到从master第一个数据块组后，再分别从po2和po3上下载剩余的2个数据块组
6. po1完成第一次数据块组下载后，按照master的控制，连接po2下载自己没有的数据块(第二个数据块组)
7. po1完成第二次数据块组下载后，按照master的控制，连接po3下载自己没有的数据块(第三个数据块组)
8. po2 和 po3 依次类推，循环连接其余po机器，完成数据下载。

• master和po中都会配置CAC的IP，CAC一般为多个，连接任意一个进行认证即可。是否开启P2P，限速以及传输后的动作都在CAC中进行配置。
• CAC采用epoll模式，读取配置并生成密钥，性能不是瓶颈
• 数据校验采用传输中校验，可以将全部校验再传输的cpu峰值降低，校验算法提供CRC和MD5 2种。

运行方式：

在每次传输时，master需要指定本次传输的类型，master通过类型连接CAC获取相关配置。

./masterwugui -c base1 -x a.txt b.txt c.txt -p /home/work/data/base
./masterwugui -h
./masterwugui -v
其中，-c用于指定传输的classname
-x用于指定排除的文件，可以是多个文件
-p用于指定源文件的目录
-h显示帮助信息
-v显示版本信息

po和CAC都是常驻内存运行，无参数。

优缺点：

优点

1. 源端机器负载过大，挂载的下游机器有限
2. 简化数据传输脚本的编写，将超时、限速、数据验证功能集成
3. 提高下游的机器数据获取的速度
4. 简化数据传输时对系统的依赖，如：ssh信任关系、proftp、wget、scp…
5. 中配置管理，数据安全认证

缺点：

1. 下游机器的负载会比传统wget负载载有所提升，可以通过限速进行控制。
2. 传输的数据总大小有限制，不能超过100G
3. 每次传输最多支持200个PO，如采用P2P模式，瓶颈还是在上游(已经有解决方案，下次分享)

测试：

• 测试环境：3台cac, 1台wugui, 20台po
• 测试数据：9.1G

case1：限速10m，且数据校验

case2：不限速，且数据校验

case3：不限速，不校验