转载请注明出处：http://blog.csdn.net/minimicall/
在接下来的20个工作日中，我将坚持翻译或者略翻译Esper的官方文档。
为什么需要学习Esper，因为我们需要理解复合事件处理 Complex Event Processing (CEP)。在量化交易系统中，CEP是必不可少的。它负责处理海量的实时事件。
关于CEP更多知识，大家可以翻阅网络相关资料。我这里集中在学习开源的CEP系统，Esper。。
今天开始第一篇：技术概览。
1. CEP和事件序列分析
Esper引擎主要解决现实中某类应用对事件的分析和响应的需求。这类需求的典型代表有：
1）商业管理和自动化（商业事件监听，BAM，异常事件紧急处理）
2）金融（程序化交易，欺诈检测，风险管理）
3）网络和应用的监管（入侵检测，SLA监管）
4）传感网络应用（RFID读取，生产线的控制和调度，空中航线监管）
这类应用的共同点就是需要实时地处理事件Event（消息Message），或者至少是接近实时。这种系统也叫Complex Event Processing(CEP)，或者事件序列分析。这类系统的关键特性是吞吐量、延迟性和复杂逻辑的需求。
1）高吞吐量 - 应用需要处理大量的事件（每秒处理1000至100K）
2）低延时 - 应用需要在事件发生时立即做出响应（从几毫秒到数秒内）
3） 复合计算 - 应用支持对事件的复杂处理，例如事件之间的模式(Patterns among events)，过滤事件(Filter events)，合并特定时间窗口或者长度窗口的事件，事件序列的合并，基于事件缺失的触发处理。
Esper 引擎就是为了简化应用实现CEP功能而生。
2. CEP和关系型数据库
关系型数据库和SQL语言主要是面向绝大多数数据是静态数据，大多数查询是简单查询的场景。大多数数据库也是将数据保存在磁盘上（除了in-memory 数据库），它们的优化也是针对磁盘存取的。
为了从数据库中获取数据，那么必须对数据库进行查询。如果应用每秒需要得到数据10次，那么势必触发10次数据库查询，这中方法很难扩展到每秒成千上万的查询量。
当数据的数据需要更新时，数据库的trigger会被激发，然后这种数据库触发器执行速度很慢，并且不擅长复杂的条件检测和逻辑处理。
In-memory数据库比传统的关系型数据库更适合CEP应用，因为它具备更好的性能。但，它并没有为CEP的实时查询结果以及事件序列分析进行设计和优化。
3. Esper作为CEP引擎
Esper和关系型数据不一样的点在于，它并不保存数据，相反，它保存查询。而数据是通过查询来处理。当一个数据（Event）来到时，它将通过我们预订的查询语句，决定下一个动作。
Esper提供两种机制处理事件流：事件模板(event patterns)和事件流查询（event stream queries）
Esper提供事件模板语言，用于基于表达式(expression-based)的事件模板匹配。模板匹配引擎是通过状态机来实现的。这种方法可以处理预料的事件序列、事件缺失和事件融合。它也提供了事件在时间方面上的相关性分析。
Esper也提供了事件序列查询方法，用于满足CEP应用对事件序列的分析需求。事件序列查询(Event series queries)提供窗口(window)，统计(aggregation)，合并(join)和分析函数，用于处理事件流。这些查询遵循EPL语法。EPL有点类似与SQL，但它是处理视图（View）的，而非表格（Table）。视图，代表了对一个事件序列的处理以及产生新的事件序列。
Esper 采用统一的API接口提供的这两种方法。
4. 需要的第三方库
Esper需要如下第三方库：
1）ANTL
2） CGLIB
3） Apache commons logging ，Log4J.
4）Junit
5）Mysql的连接库
本章完毕。。。
