当然,Transformer 应当可以多个连接到一路连动合作。
设计 Transformer 模块是一件有趣而富有挑衅的工作,这涉及到 Tranformer 功能多样性带来的 3 个问题:
- 多样的功能必定涉及到多样的设备,若何将不合的设备以优雅而同一的方法传达到插件中?
- 多样的功能也涉及到不合功能的描述,若何将功能描述以同一的情势表达给用户,让用户选择响应的设备?
- 若何将上述两个问题尽可能简单地解决,让用户编写 Transformer 插件时存眷尽可能少的问题?
这里我们留个悬念,感兴趣的同伙可以浏览 logkit Transformer 相干 (https://github.com/qiniu/logkit/tree/develop/transforms) 的源码寻求谜底,笔者后续也会在 logkit 的 wiki 页面中描述。
Channel
经由解析和变换后的数据可以认为已经处理好了,此时数据会进入待发送队列,即 Channel 部分。Channel 的短长决定了一个数据收集发送对象的机能及靠得住程度,是数据收集对象中最具技巧含量的一环。
数据收集对象,顾名思义,就是将数据收集起来,再发送到指定地位,而为了将机能最优化,我们必须把收伎?注送解耦,中心供给一个缓冲带,而 Channel 就是负责数据暂存的处所。有了 Channel,攫取和发送就解耦了,可以应用多核优势,多线程发送数据,进步数据吞吐量。
一种设计思路是把全部 Channel,包含多线程发送做成一个框架,封装成一个特别的 sender,我们称这个特别的 sender 为”ft sender”。其架构如图 2 所示,ft sender 与其他 sender 一样也供给了 Send() 办法,解析完毕后的数据调用 Send 办法实际上就是将数据传入到 Channel 中,然后再由 ft sender 处理多线程发送逻辑,将大年夜队列中掏出的数据交由实际的 sender 多线程发送。
同时须要为用户供给磁盘和内存两大年夜队列方法选择。
如不雅寻求更高的机能,可以应用内存队列,其实现方法就是 Go 说话的 Channel 机制,稳定而简单,在关停过程中也须要将 Channel 中的数据落地稻磁逄,在随后从新启动时载入,正常应用过程中也没稀有据损掉的风险。得益于 Go 说话的同步 Channel 机制,甚至可以把内存队列的大年夜小设置为 0,以此实现多线程发送,如许应用内存队列即使宕机,也没有了数据损掉的风险。
除了正常地作为待发送数据的等待队列以外,Channel 还可以具有如下一些异常有趣而实用的功能:
缺点数据筛选
并不是所有解析完毕的数据发送到办事端就必定是精确的,有时办事端指定的数据格局和解析完毕的格局存在进出,或者数据中含有一些不法字符等情况,则数据不克不及发送成功。此时,如不雅一批数据中只有一条如许缺点的数据,就很轻易导致这一整批都掉败。
缺点数据筛选的感化就在于,把这一整批数据中对的数据筛选出来,留下缺点的数据,将精确的发送出去。
做法很简单,当发送时碰到办事端返回存在格局缺点的数据时,将这一批数据平均拆分为两批(二分),再放入队列,等待下次发送。再碰到缺点时则再拆分,如许赓续二分,直到一个批次中只有一条数据,且发送掉败,那我们就找到了这个缺点数据,可以选择丢弃或记录。
借助队列,我们很轻易就能将缺点数据筛选出来。
包拆分(大年夜包拆小包)
包拆分的由来是办事端弗成能无穷制开放每个批次数据传输的大年夜小,出于办事器机能、传输机能等原因,总有会有一些限制。
当一个批次的数据过大年夜时,就会导致传输掉败。此时的做法与缺点筛选的办法类似,只要将包二分即可,如不雅照样太大年夜就再次二分,以词攀类推。
限速
限速的功能最轻易懂得,数据一切经由 Channel,那么只要限制这个 Channel 传输介质的速度即可。例如磁盘队列,只须要限制磁盘的 IO 读写速度;内存队列则限制队列大年夜小以此达到限速的目标。
常见的流量控制的算法有漏桶算法(Leaky bucket)(https://en.wikipedia.org/wiki/Leaky_bucket)和令牌桶算法(Token bucket)(https://en.wikipedia.org/wiki/Token_bucket) 两种,比较推荐采取令牌桶算法实现该功能,感兴趣的同伙可以浏览一下 logkit 的 rateio 包 (https://github.com/qiniu/logkit/tree/develop/rateio)。
Sender
Sender 的重要感化是将队列中的数据发送至 Sender 支撑的各类办事,一个最根本的实现同样应当设计得尽可能简单,理论上仅需实现一个 Send 接口即可。
那么实现一个发送端有哪些留意事项呢?
多线程发送:多线程发送可以充分应用 CPU 的多核才能,晋升发送效力,这一点我们在架构设计中经由过程设计 ft sender 作为框架解决了该问题。
缺点处理与等待:办事端有时出现一些异常是很正常的工作,此时就要做好不合缺点情况的处理,不会因为某个缺点而导致法度榜样掉足,别的一方面,一旦发明掉足应当让 sender 等待一准时光再发送,设定一个对后端友爱的变长缺点等待机制也异常重要。一般情况下,可以采取跟着持续缺点出现递增等待时光的办法,直到一个最巅峰(如10s),就不再增长,当办事端恢复后再撤消等待。
数据紧缩发送:带宽是异常名贵的资本,平日办事端都邑供给 gzip 紧缩的数据接收接口,而 sender 应用这些接口,将数据紧缩后发送,能节俭大年夜量带宽成本。
带宽限流:平日情况下数据收集对象只是机械上的一个从属法度榜样,重要资本如带宽照样要预留给主办事,所以限制 sender 的带宽用量也是异常重要的功能,限流的办法可以采取前面 Channel 一节提到的令牌桶算法。
字段填充 (UUID/timestamp):平日情况下收集的数据信息可能不是完全的,须要填充一些信息进去,如全局独一的 UUID、代表收集时光的 timestamp 等字段,供给这些字段主动填充的功能,有利于用户对其数据做独一性、时效性等方面的断定。
推荐阅读
沙龙晃荡 | 去哪儿、陌陌、ThoughtWorks在主动化运维中的实践!10.28不见不散!【编辑推荐】微软联袂FB推出开源项目 打造共享神经收集模型微软Skype开启第二轮Cortana整合,可参加对话傍边作为助手微软>>>详细阅读
本文标题:数据收集工具的设计与最佳实践
地址:http://www.17bianji.com/lsqh/38064.html
1/2 1