分布式事件处理引擎（分布式事件处理引擎是什么）

本篇文章给大家谈谈分布式事件处理引擎，以及分布式事件处理引擎是什么对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享分布式事件处理引擎的知识，其中也会对分布式事件处理引擎是什么进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、flink组件擅长什么
• 2、为什么Flink会成为下一代大数据处理框架的标准
• 3、基于大数据审计的信息安全日志分析法
• 4、Apache Flink现在在大数据处理方面能够和Apache Spark分庭抗礼么
• 5、Apache Flink是什么？

flink组件擅长什么

Flink是一个框架和分布式处理引擎，用于对无限制和有限制的数据进行有状态的计算。Flink被设计为可在所有常见的集群环境中运行，以内存速度和任何规模执行计算。
Flink擅长处理无边界和有界的数据集。对事件和状态的精确控制使Flink的运行时能够在无限制的流上运行任何类型的应用程序。有界流由专门为固定大小的数据集设计的算法和数据结构在内部进行处理，从而产生出色的性能。
部署Flink应用程序时，Flink会根据应用程序配置的并行性自动识别所需的资源，并向资源管理器请求它们。如果发生故障，Flink会通过请求新资源来替换发生故障的容器。提交或控制应用程序的所有通信均通过REST调用进行。简化了Flink在许多环境中的集成。
Flink旨在运行任何规模的有状态流应用程序。将应用程序并行化可能在集群中分布并同时执行的数千个任务。因此，应用程序几乎可以利用无限数量的CPU，主内存，磁盘和网络IO。并且，Flink易于维护非常大的应用程序状态。它的异步和增量检查点算法可确保对处理延迟的影响降至最低，同时保证一次状态一致性。

为什么Flink会成为下一代大数据处理框架的标准

作者：张利兵

如需转载请联系华章 科技

在当前数据量激增传统的时代，不同的业务场景都有大量的业务数据产生， 对于这些不断产生的数据应该如何进行有效地处理，成为当下大多数公司所面临的问题。

随着雅虎对Hadoop的开源，越来越多的大数据处理技术开始涌入人们的视线，例如目前比较流行大数据处理引擎Apache Spark，基本上已经取代了MapReduce成为当前大数据处理的标准。

但随着数据的不断增长，新技术的不断发展，人们逐渐意识到对实时数据处理的重要性，企业需要能够同时支持高吞吐、低延迟、高性能的流处理技术来处理日益增长的数据。

相对于传统的数据处理模式，流式数据处理则有着更高的处理效率和成本控制。 Apache Flink就是近年来在开源社区发展不断发展的能够支持同时支持高吞吐、低延迟、高性能分布式处理框架。

在2010至2014年间，由柏林工业大学，柏林洪堡大学和哈索普拉特纳研究所联合发起名为“Stratosphere: Information Management on the Cloud”研究项目，该项目在当时的社区逐渐具有一定社区知名度，2014年4月，Stratosphere代码被贡献给Apache 软件基金会，成为Apache基金会孵化器项目。

期初参与该项目的核心成员均来自Stratosphere原来的核心成员，之后团队的大部分创始成员离开学校，共同创办了一家名叫Data Artisans的公司，其主要业务便是将Stratosphere，也就是之后的Flink实现商业化。在项目孵化期间，项目Stratosphere改名为Flink。

Flink在德语中是快速和灵敏的意思，用来体现流式数据处理器的速度快和灵活性强等特点，同时使用棕红色松鼠图案作为Flink项目的Logo，也是主要借助于松鼠灵活快速的特点，由此Flink开始正式地进入社区开发者的视线。

在2014年12月，该项目成为Apache 软件基金会顶级项目，从2015年09月发布第一个稳定版本0.9，到2019年4月已经发布到1.8的版本，更多的社区开发成员也逐步地加入，现在Flink在全球范围内拥有350多位的开发人员， 不断有新的特性被发布。

同时在全球范围内，越来越多的公司开始使用Flink，在国内比较出名的互联网公司如Alibaba，美团，滴滴等，都在大规模的使用Flink作为企业的分布式大数据处理引擎。

Flink在近年来逐步被人们所熟知和使用，其主要原因不仅因为提供同时支持高吞吐、低延迟和exactly-once语义的实时计算能力，同时Flink还提供了基于流式计算引擎处理批量数据的计算能力，真正意义实现了批流统一，同时随着Alibaba对Blink的开源，极大地增强了Flink对批计算领域的支持。

众多优秀的特性，使得Flink成为开源大数据数据处理框架中的一颗新星，随着国内社区不断推动， 越来越多的国内公司开始选择使用Flink作为实时数据处理的技术 ，在将来不久的时间内，Flink也将会成为企业内部主流的数据处理框架，最终成为下一代大数据数据处理框架的标准。

有状态流计算将会随着技术的发展，逐步成为企业作为构建数据平台的架构模式，而这种技术实现的开源方案目前从社区来看，能够满足的就是Apache Flink。 Flink通过实现Google Dataflow流式计算模型实现了高吞吐，低延迟，高性能兼具实时流式计算框架。

同时Flink支持高效容错的状态管理，Flink能够将其状态维护在内存或RockDB数据库中，为了防止状态在计算过程中因为系统异常而出现丢失，Flink周期性的通过分布式快照技术CheckPoints实现状态的持久化维护，使得在系统即使在停机或者异常的情况下都能正确的进行状态恢复，从而保证在任何时间都能计算出正确的结果。

数据架构的演变过程，伴随着技术的不断迭代更新，Flink具有先进的架构理念，以及诸多的优秀特性，以及完善的编程接口，而Flink也在每一次的Release版本中，不断推出新的特性。

例如Queryable State功能的提出，将直接容许用户通过远程的方式直接获取流式计算任务的状态信息，也就是说数据不需要落地数据库就能直接从流式应用中直接查询出，对于实时交互式的查询业务可以直接从Flink的状态中查询最新的结果，当然这个功能目前还属于Beta版本，但是相信在不久的未来，会变得越来越完善，那时Flink将不仅作为实时流式处理的框架，更多的可能会成为一套实时的存储引擎， 会让更多的用户从有状态计算的技术中获取收益。

Flink是一套集高吞吐，低延迟，高性能三者于一身的分布式流式数据处理框架。

非常成熟的计算框架Apache Spark也只能兼顾高吞吐和高性能特性，在Spark Streaming流式计算中无法做到低延迟保障；而Apache Storm只能支持低延迟和高性能特性，但是无法满足高吞吐的要求。而对于满足高吞吐，低延迟，高性能这三个目标对分布式流式计算框架是非常重要的。

在流式计算领域中，窗口计算的地位举足轻重，但目前大多数计算框架窗口计算所采用的都是系统时间（Process Time），也是事件传输到计算框架处理时，系统主机的当前时间，Flink能够支持基于 事件时间 （Event Time）语义的进行窗口计算，就是使用事件产生的时间，这种时间机制使得事件即使无序到达甚至延迟到达，数据流都能够计算出精确的结果，同时保持了事件原本产生时的在时间维度的特点，而不受网络传输或者计算框架的影响。

Flink在1.4版本中实现了状态管理，所谓状态就是在流式计算过程中将算子的中间结果数据的保存在内存或者DB中，等下一个事件进入接着从状态中获取中间结果进行计算，从而无需基于全部的原始数据统计结果，这种做法极大地提升了系统的性能，同时也降低了计算过程的耗时。

对于数据量非常大且逻辑运算非常复杂的流式运算，基于状态的流式计算则显得非常使用。

在流处理应用中，数据是连续不断的，需要通过窗口的方式对流数据进行一定范围的聚合计算，例如统计在过去的1分钟内有多少用户点击了某一网页，在这种情况下，我们必须定义一个窗口，用来收集最近一分钟内的数据，并对这个窗口内的数据再进行计算。

Flink将窗口划分为基于Time、Count、Session，以及Data-driven等类型的窗口操作，窗口能够用灵活的触发条件定制化从而达到对复杂的流传输模式的支持，不同的窗口操作应用能够反馈出真实事件产生的情况，用户可以定义不同的窗口触发机制来满足不同的需求。

Flink能够分布式运行在上千个节点之上，将一个大型计算的流程拆解成小的计算过程，然后将计算过程分布到单台并行节点上进行处理。

在任务执行过程中，能够自动的发现事件处理过程中的错误而导致数据不一致的问题，常见的错误类型例如：节点宕机，或者网路传输问题，或是由于用户因为升级或修复问题而导致计算服务重启等。

在这些情况下，通过基于分布式快照技术的 Checkpoints ，将执行过程中的任务信息进行持久化存储，一旦任务出现异常宕机，Flink能够进行任务的自动恢复，从而确保数据在处理过程中的一致性。

内存管理是每套计算框架需要重点考虑的领域，尤其对于计算量比较大的计算场景，数据在内存中该如何进行管理，针对内存管理这块，Flink实现了自身管理内存的机制，尽可能减少Full GC对系统的影响。

另外通过自定义序列化/反序列化方法将所有的对象转换成二进制在内存中存储，降低数据存储的大小，更加有效的对内存空间进行利用，降低GC所带来的性能下降或者任务停止的风险，同时提升了分布式处理过数据传输的性能。

因此Flink较其他分布式处理的框架则会显得更加稳定，不会因为JVM GC等问题而导致整个应用宕机的问题。

对于7*24小时运行的流式应用，数据源源不断的接入，在一段时间内应用的终止都有可能导致数据的丢失或者计算结果的不准确性，例如进行版本的升级，停机运维操作等，都能导致这种情况发生。

然而值得一提的是Flink通过其Save Points技术能够将任务执行的快照（Snapshot）保存在存储介质上，等待任务重启的时候可以直接从实现保存的Save Points恢复原有的计算状态，使得任务继续按照停机之前的状态继续运行，Save Points技术可以让用户更好的管理和运维实时流式应用。

同时Flink除了上述的特性之外也具有其他非常优秀的特性，可以让用户有更多选择。 Flink具备非常多的优秀特性，这不仅让Flink在社区的知名度越来越高，也吸引了众多的企业参与研发和使用Flink这项技术。

关于作者：张利兵，资深架构师，流式计算领域专家，第四范式华东区AI项目架构师，原明略数据华东区大数据架构师。有多年大数据、流式计算方面的开发经验，对Hadoop、Spark、Flink等大数据计算引擎有着非常深入的理解，积累了丰富的项目实践经验。

推荐语： 从功能、原理、实战和调优4个维度循序渐进讲解利用Flink进行分布式流式应用开发，指导读者从零基础入门到进阶。适读人群：流计算开发工程师、大数据架构工程师、大数据开发工程师、数据挖掘工程师、高校研究生以及高年级本科生。

基于大数据审计的信息安全日志分析法

噪声数据随着经济和信息技术的不断发展，许多企业开始引入了ERP等系统，这些系统使得企业的众多活动数据可以实时记录，形成了大量有关企业经营管理的数据仓库。从这些海量数据中获取有用的审计数据是目前计算机审计的一个应用。接下来我为你带来基于大数据审计的信息安全日志分析法，希望对你有帮助。

大数据信息安全日志审计分析方法

1．海量数据采集。

大数据采集过程的主要特点和挑战是并发数高，因此采集数据量较大时，分析平台的接收性能也将面临较大挑战。大数据审计平台可采用大数据收集技术对各种类型的数据进行统一采集，使用一定的压缩及加密算法，在保证用户数据隐私性及完整性的前提下，可以进行带宽控制。

2．数据预处理。

在大数据环境下对采集到的海量数据进行有效分析，需要对各种数据进行分类，并按照一定的标准进行归一化，且对数据进行一些简单的清洗和预处理工作。对于海量数据的预处理，大数据审计平台采用新的技术架构，使用基于大数据集群的分布式计算框架，同时结合基于大数据集群的复杂事件处理流程作为实时规则分析引擎，从而能够高效并行地运行多种规则，并能够实时检测异常事件。

3．统计及分析。

按照数据分析的实时性，分为实时数据分析和离线数据分析。大数据平台在数据预处理时使用的分布式计算框架Storm就非常适合对海量数据进行实时的统计计算，并能够快速反馈统计结果。Storm框架利用严格且高效的事件处理流程保证运算时数据的准确性，并提供多种实时统计接口以使用。

4．数据挖掘。

数据挖掘是在没有明确假设的前提下去挖掘信息、发现知识，所以它所得到的信息具有未知、有效、实用三个特征。与传统统计及分析过程不同的是，大数据环境下的数据挖掘一般没有预先设定好的主题，主要是在现有数据上面进行基于各种算法的计算，从而起到预测的效果，并进一步实现一些高级别数据分析的需求。

大数据分析信息安全日志的解决方案

统一日志审计与安全大数据分析平台能够实时不间断地将用户网络中来自不同厂商的安全设备、网络设备、主机、操作系统、数据库系统、用户业务系统的日志和警报等信息汇集到管理中心，实现全网综合安全审计；同时借助大数据分析和挖掘技术，通过各种模型场景发现各种网络行为、用户异常访问和操作行为。

1．系统平台架构。

以国内某大数据安全分析系统为例，其架构包括大数据采集平台、未知威胁感知系统、分布式实时计算系统(Storm)、复杂事件处理引擎(Esper)、Hadoop平台、分布式文件系统(HDFS)、分布式列数据库(Hbase)、分布式并行计算框架(Map／Reduce、Spark)、数据仓库(Hive)、分布式全文搜索引擎(ElasticSearch)、科学计算系统(Euler)。这些技术能够解决用户对海量事件的采集、处理、分析、挖掘和存储的需求。

如图1所示，系统能够实时地对采集到的不同类型的信息进行归一化和实时关联分析，通过统一的控制台界面进行实时、可视化的呈现，协助安全管理人员迅速准确地识别安全事件，提高工作效率。

2．实现功能。

系统能够实现的功能包括：审计范围覆盖网络环境中的全部网络设备、安全设备、服务器、数据库、中间件、应用系统，覆盖200多种设备和应用中的上万类日志，快速支持用户业务系统日志审计；系统收集企业和组织中的所有安全日志和告警信息，通过归一化和智能日志关联分析引擎，协助用户准确、快速地识别安全事故；通过系统的'安全事件并及时做出安全响应操作，为用户的网络环境安全提供保障；通过已经审计到的各种审计对象日志，重建一段时间内可疑的事件序列，分析路径，帮助安全分析人员快速发现源；整个Hadoop的体系结构主要通过分布式文件系统(HDFS)来实现对分布式存储的底层支持。

3．应用场景。

上述系统可解决传统日志审计无法实现的日志关联分析和智能定位功能。如在企业的网络系统中，大范围分布的网络设备、安全设备、服务器等实时产生的日志量非常大，要从其中提取想要的信息非常困难，而要从设备之间的关联来判断设备故障也将是一大难点。例如，某企业定位某设备与周围直连设备的日志消息相关联起来判断该设备是否存在异常或故障，如对于其中一台核心交换机SW1，与之直连的所有设备如果相继报接口down的日志，则可定位该设备SWl为故障设备，此时应及时做出响应。而传统数据难以通过周围设备的关联告警来定位该故障，大数据审计平台则是最好的解决方法。

大数据分析方法可以利用实体关联分析、地理空间分析和数据统计分析等技术来分析实体之间的关系，并利用相关的结构化和非结构化的信息来检测非法活动。对于集中存储起来的海量信息，可以让审计人员借助历史分析工具对日志进行深度挖掘、调查取证、证据保全。

Apache Flink现在在大数据处理方面能够和Apache Spark分庭抗礼么

我们是否还需要另外一个新的数据处理引擎？当我第一次听到flink的时候这是我是非常怀疑的。在大数据领域，现在已经不缺少数据处理框架了，但是没有一个框架能够完全满足不同的处理需求。自从Apache spark出现后，貌似已经成为当今把大部分的问题解决得最好的框架了，所以我对另外一款解决类似问题的框架持有很强烈的怀疑态度。
不过因为好奇，我花费了数个星期在尝试了解flink。一开始仔细看了flink的几个例子，感觉和spark非常类似，心理就倾向于认为flink又是一个模仿spark的框架。但是随着了解的深入，这些API体现了一些flink的新奇的思路，这些思路还是和spark有着比较明显的区别的。我对这些思路有些着迷了，所以花费了更多的时间在这上面。
flink中的很多思路，例如内存管理，dataset API都已经出现在spark中并且已经证明 这些思路是非常靠谱的。所以，深入了解flink也许可以帮助我们分布式数据处理的未来之路是怎样的
在后面的文章里，我会把自己作为一个spark开发者对flink的第一感受写出来。因为我已经在spark上干了2年多了，但是只在flink上接触了2到3周，所以必然存在一些bias，所以大家也带着怀疑和批判的角度来看这篇文章吧。
Apache Flink是什么
flink是一款新的大数据处理引擎，目标是统一不同来源的数据处理。这个目标看起来和spark和类似。没错，flink也在尝试解决spark在解决的问题。这两套系统都在尝试建立一个统一的平台可以运行批量，流式，交互式，图处理，机器学习等应用。所以，flink和spark的目标差别并不大，他们最主要的区别在于实现的细节。
后面我会重点从不同的角度对比这两者。
Apache Spark vs Apache Flink
1.抽象 Abstraction
spark中，对于批处理我们有RDD,对于流式，我们有DStream，不过内部实际还是RDD.所以所有的数据表示本质上还是RDD抽象。
后面我会重点从不同的角度对比这两者。在flink中，对于批处理有DataSet，对于流式我们有DataStreams。看起来和spark类似，他们的不同点在于：
一）DataSet在运行时是表现为运行计划(runtime plans)的
在spark中，RDD在运行时是表现为java objects的。通过引入Tungsten，这块有了些许的改变。但是在flink中是被表现为logical plan(逻辑计划)的，听起来很熟悉？没错，就是类似于spark中的dataframes。所以在flink中你使用的类Dataframe api是被作为第一优先级来优化的。但是相对来说在spark RDD中就没有了这块的优化了。
flink中的Dataset，对标spark中的Dataframe，在运行前会经过优化。
在spark 1.6，dataset API已经被引入spark了，也许最终会取代RDD 抽象。
二）Dataset和DataStream是独立的API
在spark中，所有不同的API，例如DStream，Dataframe都是基于RDD抽象的。但是在flink中，Dataset和DataStream是同一个公用的引擎之上两个独立的抽象。所以你不能把这两者的行为合并在一起操作，当然，flink社区目前在朝这个方向努力(https://issues.apache.org/jira/browse/FLINK-2320)，但是目前还不能轻易断言最后的结果。
2.内存管理
一直到1.5版本，spark都是试用java的内存管理来做数据缓存，明显很容易导致OOM或者gc。所以从1.5开始，spark开始转向精确的控制内存的使用，这就是tungsten项目了
flink从第一天开始就坚持自己控制内存试用。这个也是启发了spark走这条路的原因之一。flink除了把数据存在自己管理的内存以外，还直接操作二进制数据。在spark中，从1.5开始，所有的dataframe操作都是直接作用在tungsten的二进制数据上。
3.语言实现
spark是用scala来实现的，它提供了Java，Python和R的编程接口。
flink是java实现的，当然同样提供了Scala API
所以从语言的角度来看，spark要更丰富一些。因为我已经转移到scala很久了，所以不太清楚这两者的java api实现情况。
4.API
spark和flink都在模仿scala的collection API.所以从表面看起来，两者都很类似。下面是分别用RDD和DataSet API实现的word count
// Spark wordcount
object WordCount {
def main(args: Array[String]) {
val env = new SparkContext("local","wordCount")
val data = List("hi","how are you","hi")
val dataSet = env.parallelize(data)
val words = dataSet.flatMap(value = value.split("\\s+"))
val mappedWords = words.map(value = (value,1))
val sum = mappedWords.reduceByKey(_+_)
println(sum.collect())
}
}
// Flink wordcount
object WordCount {
def main(args: Array[String]) {
val env = ExecutionEnvironment.getExecutionEnvironment
val data = List("hi","how are you","hi")
val dataSet = env.fromCollection(data)
val words = dataSet.flatMap(value = value.split("\\s+"))
val mappedWords = words.map(value = (value,1))
val grouped = mappedWords.groupBy(0)
val sum = grouped.sum(1)
println(sum.collect())
}
}
不知道是偶然还是故意的，API都长得很像，这样很方便开发者从一个引擎切换到另外一个引擎。我感觉以后这种Collection API会成为写data pipeline的标配。
Steaming
spark把streaming看成是更快的批处理，而flink把批处理看成streaming的special case。这里面的思路决定了各自的方向，其中两者的差异点有如下这些：
实时 vs 近实时的角度
flink提供了基于每个事件的流式处理机制，所以可以被认为是一个真正的流式计算。它非常像storm的model。
而spark，不是基于事件的粒度，而是用小批量来模拟流式，也就是多个事件的集合。所以spark被认为是近实时的处理系统。
Spark streaming 是更快的批处理，而Flink Batch是有限数据的流式计算。
虽然大部分应用对准实时是可以接受的，但是也还是有很多应用需要event level的流式计算。这些应用更愿意选择storm而非spark streaming，现在，flink也许是一个更好的选择。
流式计算和批处理计算的表示
spark对于批处理和流式计算，都是用的相同的抽象：RDD，这样很方便这两种计算合并起来表示。而flink这两者分为了DataSet和DataStream，相比spark，这个设计算是一个糟糕的设计。
对 windowing 的支持
因为spark的小批量机制，spark对于windowing的支持非常有限。只能基于process time，且只能对batches来做window。
而Flink对window的支持非常到位，且Flink对windowing API的支持是相当给力的，允许基于process time,data time,record 来做windowing。
我不太确定spark是否能引入这些API，不过到目前为止，Flink的windowing支持是要比spark好的。
Steaming这部分flink胜
SQL interface
目前spark-sql是spark里面最活跃的组件之一，Spark提供了类似Hive的sql和Dataframe这种DSL来查询结构化数据，API很成熟，在流式计算中使用很广，预计在流式计算中也会发展得很快。
至于flink，到目前为止，Flink Table API只支持类似DataFrame这种DSL，并且还是处于beta状态，社区有计划增加SQL 的interface，但是目前还不确定什么时候才能在框架中用上。
所以这个部分，spark胜出。
Data source Integration
Spark的数据源 API是整个框架中最好的，支持的数据源包括NoSql db,parquet,ORC等，并且支持一些高级的操作，例如predicate push down
Flink目前还依赖map/reduce InputFormat来做数据源聚合。
这一场spark胜
Iterative processing
spark对机器学习的支持较好，因为可以在spark中利用内存cache来加速机器学习算法。
但是大部分机器学习算法其实是一个有环的数据流，但是在spark中，实际是用无环图来表示的，一般的分布式处理引擎都是不鼓励试用有环图的。
但是flink这里又有点不一样，flink支持在runtime中的有环数据流，这样表示机器学习算法更有效而且更有效率。
这一点flink胜出。
Stream as platform vs Batch as Platform
Spark诞生在Map/Reduce的时代，数据都是以文件的形式保存在磁盘中，这样非常方便做容错处理。
Flink把纯流式数据计算引入大数据时代，无疑给业界带来了一股清新的空气。这个idea非常类似akka-streams这种。
成熟度
目前的确有一部分吃螃蟹的用户已经在生产环境中使用flink了，不过从我的眼光来看，Flink还在发展中，还需要时间来成熟。
结论
目前Spark相比Flink是一个更为成熟的计算框架，但是Flink的很多思路很不错，Spark社区也意识到了这一点，并且逐渐在采用Flink中的好的设计思路，所以学习一下Flink能让你了解一下Streaming这方面的更迷人的思路。

Apache Flink是什么？

Flink其实就是Apache Flink，是一款业内非常火的大数据产品，由Apache软件基金会开发，核心是用Java和Scala编写的分布式流数据流引擎。Apache Flink是个旨在提供‘一站式’ 的分布式开源数据处理框架。
Flink以数据并行和流水线方式执行任意流数据程序，Flink的流水线运行时系统可以执行批处理和流处理程序。
此外，Flink的运行时本身也支持迭代算法的执行。
虽然，spark和storm的计算框架非常成熟，但是Flink仍然占据了一席之地。
主要在于flink在设计event time处理模型上比较优秀：watermark的计算实时性高，输出延迟低，而且接受迟到数据没有spark那么受限。
另外，Flink提供的window programming模型非常的灵活，不但支持spark、storm没有的session window，而且只要实现其提供的WindowAssigner、Trigger、Evictor就能创造出符合自身业务逻辑的window，flink可谓功能非常强大。 关于分布式事件处理引擎和分布式事件处理引擎是什么的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 分布式事件处理引擎的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于分布式事件处理引擎是什么、分布式事件处理引擎的信息别忘了在本站进行查找喔。