“批量少次”还是“少量多次”--邮件通信系统效率浅谈

    在做Web开发的时候，相信很多人都看过一个“批量少次”原则：

    Web服务器采用HTTP协议，它是一个非持久连接的协议，是无状态的（虽然可以采用多种方式来模拟Web会话状态，但本质上Web是无状态的），由于每一次连接都要耗费相当的资源，所以尽量减少连接的次数，每次连接发送尽量多的数据也是顺理成章，这样它能够提供极大的吞吐量，可以提高Web应用系统的处理效率，这便是著名的“批量少次”原则。

    这个原则在很多情况下都适用，比如ADO.NET相比原来的ADO数据访问，由于采用了断开式连接，极大地提高了系统的处理能力，又比如商业贸易中的“批发”模式，分销商每次从批发商那里批量进货，可以得到更高的价格折扣。因此，在实际工作中，“批量少次”原则，也是我极力推崇的一个原则。

    我们通常情况下手工收发邮件，如果有很多文件或者内容，也是希望对方一次发过来的，这也符合“批量少次”的原则。但是我们使用的邮件系统都有限制，即每次发送的附件数量和大小有一定的限制，比如4M，所以有更大的文件，就必须分割多次发送了，因此“批量少次”的原则也有不适用的场景。为什么会有这样的问题？发送超过1M大小的邮件，对于现在的网络系统和大多数邮件系统而言，发送速度都有点慢了，我测试使用FoxMail发送4M以上的邮件，大概有10%-40%的失败率，要么我这边的网络速度太慢，邮件服务器提示处理超时，要么对方邮件服务器拒绝接收或者接收很慢。

 

    每次发送多大的邮件速度和成功率最高？经过很多次试验，我发现如果内容在1M内成功率接近100% ，2M以内有95%左右，3.5M以后成功率大幅下降，只有60%左右。看来，要发送大量的邮件，必须采用另外一个原则：“少量多次”，每次发送成功率最高的最大容量（少量）的邮件，分多次连续发送。这样做还有一个好处，每个“任务”可以发送远大于邮箱容量的邮件，比如发送上G大小的邮件。

 

    WCF邮件通信系统之文件同步程序采用了“少量多次”的原则，来处理将整站文件同步到远程服务器的任务，发送的文件大小没有限制，它会自动切割大文件，每次发送一个分部文件，多次发送邮件，从而完成文件同步任务。

    对于数据同步的应用该采用那种模式？如果每个任务要同步多个表的数据，而且某个表的数据可能很大，“批量少次”的处理方式有可能增加处理的复杂度和消耗更多的资源，比如将数据打包成压缩文件，对方接收到压缩文件并解压缩，然后将内容很大的数据载入内存，再慢慢导入数据库，处理的最终结果，要等这个操作完成之后才能知道。如果采用“少量多次”的处理方式，每次只发送一个表的数据，如果表比较大分页发送，接收端处理后及时反馈处理结果，而不是等到全部处理完成后。由于每次发送的数据相对较少，所以系统通信的成功率很高，而且处理效率也很好。

 

    下面是数据同步程序处理“大数据量”的一个测试结果：

========================

网络情况：

测试环境：一个外网263邮箱，一个外网Notes邮箱，源数据库在外网，目标数据库在内网；

 

数据情况：

待同步的表：XX净资产值表；

记录数量：57万条；

记录大小：每2万条约4M（非压缩），总共约 1032M；

单次发送邮件的记录条数：2万条（数据经过自定义压缩）；

 

测试结果：

自开始发送到全部导入的时间：6分钟左右（受网络环境影响）；

 

===========================================================

6分钟处理50多万条记录的邮件通信系统，可以跟“批量少次”模式对比一下，相信这个速度还是令人满意的。

而且，采用“少量多次”的方案，提高了方案的灵活性，比如上面测试的这个表，如果一开始就发现对方数据库无法使用或者目标表结构不一致，从而及时终止这个表的同步，是不是比一次把所有数据发过去（姑且认为你有办法），然后在发送端傻等要好得多？

 

总结一下“少量多次”在邮件通信系统中的意义：

• 可以处理超过邮箱容量的数据；
• 可以适时了解接收端的工作状态；
• 可以应对网络状况不好的问题，提高系统的稳定性。

 

小技巧：

很多邮箱只是限制了“附件”的大小，但不会限制邮件正文的大小，所以WCF邮件通信系统的数据同步程序采用了“正文发送数据”的模式，不过该模式太过“非主流”，以至于得不到领导的认可，但这不失为“突破附件大小限制”的一个方案。