关于物联网:eKuiper-Newsletter-202206|离线缓存重发机制升级优化弱网场景使用

22次阅读

共计 2331 个字符,预计需要花费 6 分钟才能阅读完成。

六月的隆冬季节正是 eKuiper 我的项目募捐给 LF Edge 基金会一周年之时。六月初,我的项目圆满完成了在基金会的第一次年度 review,并确立了下一年度降级到 Stage 2 的指标。在此咱们衷心感谢各位社区贡献者、合作伙伴和用户,期待新的一年能有更多搭档退出到社区的建设中。

咱们的开发工作也获得了不错的停顿。月初,小版本 1.5.1 公布,次要解决了一些用户问题。在 1.6.0 版本开发方面,咱们实现了离线缓存和重发机制的降级,更适应边缘部署中常见的边云网络连接易失落的弱网场景。与此同时,咱们补齐了一些 SQL 语法反对,包含 IN/NOT IN 表达式的反对、ORDER BY 对表达式和别名的反对等,不便用户编写更简单的过滤和排序逻辑。最初,可视化拖拽能力的开发目前已实现后盾 API 的局部验证。

离线缓存和重发

大数据时代,云边协同是支流的计算模式。边缘计算的一部分后果须要发送到云端进行进一步的整合。然而边云之间的网络连接经常是不稳固的,网络连接故障时有发生。作为边缘流式计算引擎,eKuiper 常常有规定将计算结果汇入内部零碎,尤其是近程的内部零碎中。这种状况下,咱们须要思考弱网环境的解决:在网络断开等故障期间,必须对数据进行缓存,并在从新连贯后从新发送。

此前,eKuiper 在肯定水平上反对 sink 缓存。它提供了一个全局配置来切换缓存开启;零碎 / 规定级配置用于内存缓存的序列化工夫距离。然而,缓存只是在内存中和复制到 DB(内存的镜像)中,并且没有定义明确的重发策略。六月,咱们对缓存机制进行了优化,缓存将同时保留在内存和磁盘中,这样缓存的容量就变得更大了;它还将继续检测故障复原状态,并在不重新启动规定的状况下实现主动从新发送。

流程

缓存只产生在 sink 中,因为那是 eKuiper 之外惟一能够发送数据的中央。每个 sink 都能够配置本人的缓存机制。每个 sink 的缓存流程是雷同的。如果启用了缓存,所有 sink 的事件都会通过两个阶段:首先是将所有内容保留到缓存中;而后在收到 ack 后删除缓存。

  • 谬误检测:发送失败后,sink 应该通过返回特定的谬误类型来辨认可复原的失败(网络等),这将返回一个失败的 ack,这样缓存就能够被保留下来。对于胜利的发送或不可复原的谬误,将发送一个胜利的 ack 来删除缓存。
  • 缓存机制:缓存将首先被保留在内存中。如果超过了内存的阈值,前面的缓存将被保留到磁盘中。一旦磁盘缓存超过磁盘存储阈值,缓存将开始 rotate。内存中最早的缓存将被抛弃,并加载磁盘中最早的缓存来代替。
  • 重发策略:如果有一个 ack 正在发送中,则期待一个胜利的 ack 以持续发送下个缓存数据。否则,当有新的数据到来时,发送缓存中的第一个数据以检测网络情况。如果 ack 胜利,按程序链式发送所有的缓存(mem + disk)。链式发送可定义一个发送距离,避免造成音讯风暴。

配置

sink 缓存的配置有两个档次。etc/kuiper.yaml 中的全局配置,定义所有规定的默认行为。还有一个规定 sink 层的定义,用来笼罩默认行为。

  • enableCache:是否启用 sink cache。缓存存储配置遵循 etc/kuiper.yaml 中定义的元数据存储的配置。
  • memoryCacheThreshold:要缓存在内存中的音讯数量。出于性能方面的思考,最早的缓存信息被存储在内存中,以便在故障复原时立刻从新发送。这里的数据会因为断电等故障而失落。
  • maxDiskCache:缓存在磁盘中的信息的最大数量。磁盘缓存是 FIFO。如果磁盘缓存满了,最早的一页信息将被加载到内存缓存中,取代旧的内存缓存。
  • bufferPageSize:缓冲页是批量读 / 写到磁盘的单位,以避免频繁的 IO。如果页面未满,eKuiper 因硬件或软件谬误而解体,最初未写入磁盘的页面将被失落。
  • resendInterval:故障复原后从新发送信息的工夫距离,避免信息风暴。
  • cleanCacheAtStop:是否在规定进行时清理所有缓存,以避免规定重新启动时对过期音讯进行大量重发。如果不设置为 true,一旦规定进行,内存缓存将被存储到磁盘中。否则,内存和磁盘规定会被清理掉。

目前,该性能的代码曾经合并到 1.6.0 版本的分支(https://github.com/lf-edge/ek…)中。感兴趣的敌人能够自行编译应用。

列表过滤

在规定引擎中,咱们常常须要判断某个值是否在一个列表中,从而触发相应的动作。在规范 SQL 语法中,通常应用 IN/NOT IN 表达式进行这样的过滤。本月,咱们实现了 IN 运算符的反对。应用办法反对以下两种:

  1. 与规范 SQL 语法雷同,反对同时设置多个表达式。

    expression [NOT] IN (expression2,...n)
  2. 在 eKuiper 的应用场景中,简单类型和无模式应用较多,因而也反对间接应用表达式(须要确保为数组类型)作为右侧运算符。

    expression [NOT] IN arrayExpression

1.5.1 版本

月初公布的 1.5.1 版本次要解决问题和小性能更新。次要的性能更新包含:

  • 扩充数据模板的反对范畴。新的版本中增加了 memory sink,edegX sink, tdengine sink 等对数据模板的反对。
  • 反对 window_start() 和 window_end() 作为其余函数的参数。

解决的 bug 包含:

  • 重启规定后,Neuron 连贯失败问题
  • 插件更新导致规定语法错误时,已运行规定的状态异样问题
  • 应用共享源时,重启规定可能随机导致连贯失败
  • REST API 应用鉴权后的跨域拜访问题

版权申明:本文为 EMQ 原创,转载请注明出处。

原文链接:https://www.emqx.com/zh/blog/ekuiper-newsletter-202206

正文完
 0