Esper概述
关系型数据库不适合每秒成百上千的数据量的查询,Esper引擎允许应用存储查询并运行数据通过,来代替存储数据并执行查询存储数据的工作方式。
Esper的事件模式匹配和事件流查询虽然是应对不同需求的,但是都是通过相同的API来实现的。
事件驱动应用服务器是为每秒需要处理超过100,000个事件的服务器提供一个运行时和多种支撑基础设施服务(如传输、安全、事件日志、高可靠性和连接、持久化等)。事件驱动服务器除了能实现事件处理,还要能将事件信息和长时间存在的数据(历史数据)结合起来,能在事件流上执行临时的关联关系和匹配操作。
在事件系统中要区分两个概念:
事件流处理(ESP,Event Stream Processing):检测事件数据流,分析出那些符合条件的事件,然后通知监听器
复杂事件处理(CEP,Complex Event Processing):监察各事件间的模式
Esper结构
Esper的事件驱动架构图:
整个EDA(Event Driven Architecture)包括:
- data Streams:事件源,提供高速、海量的实时数据。
- Event Stream adapters:事件源的接入适配器,用于接收事件源数据,并且转发事件给Esper引擎。
- Esper Engine:Esper引擎部分。其负责注册statement以及statement的监听、事件类型等信息,执行事件处理。
- output adapters:输出适配器,通过监听等获取引擎处理的有价值信息,通过该适配器输出。即与引擎外包程序连接的入口。
- Event Query & Causality Pattern Language:事件处理语言,包括规则引擎(事件查询语言)以及状态引擎(模式匹配)的定义。Esper引擎执行事件处理时,依赖这些引擎的定义。
- Core Container:核心容器。特殊算法、操作分析等。
- HistorycalData access layer:历史数据访问层。在引擎处理时,会将Esper引擎处理views的历史数据(比如时间窗口 取过去30s的平均值)时,保存历史数据,供引擎处理。
运行时,event stream的流转如箭头方向所指。
或者如下图:
上图中,通过事件处理总线,即接入adapter以及引擎注册,负责接收事件并交由引擎处理;引擎处理的过程需要借助Esper的内部缓存以及状态引擎、规则引擎等对事件进行解析、筛选处理。引擎处理输出的事件信息、历史数据等都会在内部缓存中进行保存。最后事件消费方获取有价值数据,执行相应动作。