系统设计中的文件渗漏问题，大家来看看.

Question

在一个系统的设计中，对磁盘中的文本文件进行处理时发现一个文件渗漏问题，现描述如下：
磁盘中有1000个文件，这些文件是从数据库加工后转换而来，可以理解为很多的文本文件，
由于数据库中的数据是变动的，现在设计一个程序，到数据库中把数据查询出来后与磁盘上的
文件进行比较，如果文件发生变化，那么需要将旧的文件替换成最新的文件，并把新的文件发送出去，但是不能一次发送太多的文件（接收端无法承受批量数据，现假设每次发送10个新的文件），
问题出来了：
    因为有多少文件变动是无法预知的，需要和磁盘上原来的文件比较后才知道是否变化，现假设有102个发生变化，每次发送10个，10次可以发送出去100个，但是还剩下最后2个新的文件由于无法满足发送的最小参数10而无法发送，导致客户端的数据无法正常更新，这就是文件的渗漏问题！
   大家有什么好的解决方案吗？

Answer 1

思路的问题.不能做成每次发一个吗?

Answer 2

将最小参数设计成1不就行了吗！

Answer 3

1、我就是想不通为什么发送文件要限制数量！
2、可以将文本文件改成数据库文件存储!好处是比对下起来比较快，别外可以增量传送！

Answer 4

思路有问题。改为：找到一个发一个，如果连续发了10个，则暂停(至于暂停多久，就要看你接收端的处理能力了)，暂停结束后，继续发送。

Answer 5

但是不能一次发送太多的文件（接收端无法承受批量数据，现假设每次发送10个新的文件）
==========================================================
既然这么说，应该讲超过一次发送的文件数如果超过10个，可能会把接收端弄坏掉；而发送10个以下的文件应该是没有问题的。因此"10"应该是最大参数而非最小参数。
当然还可以有别的方法，例如用一个队列来存放要发送的文件指针，用一个线程每次从这个队列里取出等待时间最长的N个文件打包发送，这样在一定程度上可以减少因文件变化过渡频繁而导致的性能下降。