我们进行日志客户端系统，需要向日志服务器下载此次任务所需要的日志（一般是一个机器10分钟的访问日志）。首先本地日志会去任务服务器查询重放任务。接着去日志服务器下载。如果该模拟集群是在DC网络组建，那么下载一个10分钟（约150M左右的文件）日志几乎在1两秒内搞定，但是如果这个分布式系统是组建于OC网络，那么OC网络的肉鸡服务器要去DC（考虑机房可靠性，日志服务器架设在DC网络）下载，经过nat转化内网到外网，下载则需要10s左右。如果为了等待日志服务器下载完，也是一笔时间开销。
在分布式系统中，所谓的stream-processing，和batch processing不同的是，数据是无边界的。你不知道什么时候日志下载完。而batch processing的前后流程关系，好比生产流水线的工序，前一道完成，后一道才开始，对于后一道是完全知道前一道的输出结果有多少。
所谓的流式处理则需要在前一道部分输出结果到达时，启动后一道工序，前一道工序继续输出，后一道则需要做出处理事件响应。后一道需要频繁调度程序。
消息系统（message broker）：前一道的部分输出，输入给消息系统。消息系统检测到是完整的一条日志，则可以产生后一道工序的输入。这里我们会碰到一个问题。下载日志的速度（10s）会远远快于执行重放这些日志的速度（3min）。按照一个消息系统可能的动作是：无buffer则丢弃，按照队列缓存住，执行流控同步后一道工序和前一道工序的匹配速度。这里我们选择了按照队列缓存住这个方案。当然在一个严谨的分布式数据库设计，message broker是一个能考率到数据丢失的节点。Broker会把完整数据发给后道工序，同时会把buffer数据缓存到硬盘备份，以防程序core dump。如果对于慢速前道工序，可以进行综合方案配置，丢弃或者流控。这里消息broker不同于数据库，他的中间未处理数据是暂时存储，处理过的消息要清除存储。
总结当然：现实中的生产线的分布式系统会远比这个复杂，但是本文实现的从0到1的迷你麻雀分布式系统有一定的实践意义。它不是一蹴而就的，不断地版本迭代。当然该系统也完成了作者的kpi-存储模型分析，在中途遇到问题时，进行的设计思考和改良，在此总结分享给大家。
问答
文字识别在格式上有什么要求？
相关阅读
原来你是这样的http2
我是怎么一步步用go找出压测性能瓶颈
HTTP/2之服务器推送(Server Push)最佳实践
【每日课程推荐】机器学习实战！快速入门在线广告业务及CTR相应知识