云存储实践-备份数补全

应用场景：
      通常一个块及其备份的数目默认为3，但当某台含该备份的slave离线了，而且离线了很长时间，那么这个块可用备份实际只有2，这对云存储的高可用性是个隐患，所以系统会把该块的备份复制到其他slave上，这样没问题，但有一天那个离线的slave又加入到云存储里，那么该块的备份实际变成4了，这又多了一个，为了不必要的数据冗余，我们需要从4个备份中删除一个；还有种情况即是在客户端上传文件的时候，因为云存储没有足够的空间所以只能写一个备份或这两个备份，达不到应用程序要求的3份，这个也需要我们事后在复制。
细节
A： 复制一个备份依然要要能保证同Rack最多2个，非同Rack存一个
B： 删除一个备份的时候依然要能保证同Rack最多2个，非同Rack存一个
C： 删除时一定要先请求master删除该块对该slave的关联metadata，随后在物理删除该备份，如果删除不成功，那么也只是成为垃圾数据，等待gc回收，反之容易造成其他应用来访问该备份，儿此备份又已经被删除
D： 复制备份完成后即向master汇报该备份，加入到metadata，或者等待slave的定期汇报，前一种更好点，因为等待定期汇报需要时间，而这个空档时间如果mater运行第二次补全任务，将会得到多余的一份(当然，这种情况不多，因为补全任务的间隔时间大于定时汇报的间隔)
E：复制命令的缓冲及过滤
      测试过master短时间内向某slave发送10万个复制命令，结果是系统报出打开文件过多的错误，实际情况很难出现大量的复制命令发向同一个slave，但为了稳妥，每个slave上的gc都做缓冲，被动接收复制命令并放入缓冲队列，但限定同时刻最多只能有10个执行；master在发送复制命令时出现重启，重启后master将重新发送复制命令，slave上就要做过滤，对同一个block id从同一个复制源的复制将先检测缓冲中是否已经存在，存在就不用放入缓冲，这种过滤只是为了减少后续不必要操作，如果没有过滤，后续也会忽略或者重写该备份，因为一台机器上不可能出现两个完全一样的备份