如何设计一个麻雀般的微型分布式架构? (3)

我们进行日志客户端系统,需要向日志服务器下载此次任务所需要的日志(一般是一个机器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相应知识

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/wpsgsx.html