Esper学习之三：进程模型
上周末本来要更新第三篇的，但是因为突发事情没能完成。这周我会争取更新两篇，让感兴趣的同学一次看个够。
之前对Esper所能处理的事件结构进行了概述，并结合了例子进行讲解，不清楚的同学请看Esper学习之二：事件类型。今天主要为大家解释一下Esper是怎么处理事件的，即Esper的进程模型。
1.UpdateListener
UpdaterListener是Esper提供的一个接口，用于监听某个EPL在引擎中的运行情况，即事件进入并产生结果后会通知UpdateListener。接口如下
从此图可以看出，随着时间推移，每个进入到引擎的W事件都是newEvents，即Insert Stream。W后括号里的值为属性值，可忽略。
有人可能要问了，为什么这里oldeEvents什么都没有。那是因为EPL的关系。看下面的例子
注：win:length(5)是个view，详细的后面会专门讲解，这里先暂时理解为Esper开放一个空间并最多可同时存放5个事件（此空间其实就是大小为5的数组）
由图可知，length window可存放w1,w2等事件，在w6事件进入之前，每个事件进入都属于newEvents。直到w6进入后，length window不能容纳w1～w6的事件，必须把w1事件移出，即w1为oldEvents。length window就像一个队列，每当事件进入队列时，就会触发updateListener并告知有新事件进入。当队列满了，再进入一个新事件时，Esper会触发UpdateListener告知有新事件进入并且有旧事件移出，正如上图所示的w6和w1。
实际上这个EPL触发监听器都只能看到newEvents，看不到oldEvents。如果想看到oldEvents，EPL要改写一下：
从图上可以看出，只有amount大于200，Esper才允许Apple事件进入view，并且作为一个newEvent触发UpdateListener
Where-Clause:
由图上可以看出，Apple事件先进入view，然后才被where子句过滤，以至于被过滤掉的事件不会作为newEvent触发UpdateListener
其实单看两个EPL，就能发现一个过滤是在进入view前，一个过滤是在view后，所以大家在应用的时候要注意。PS:在我写这段的时候才发现以前认为这两种是一样的效果是错误滴- -！
4.Aggregation and Grouping
之前说过EPL是类SQL语法，所以也会有聚合和分组的功能。语法和SQL基本一样，下面给大家展示一下：
// 统计进入的5个Apple事件，amount的总数是多少select sum(amount) from Apple.win:length_batch(5)// 统计进入的5个Apple事件，amount的总数是多少，并按照price分组select price, sum(amount) from Apple.win:length_batch(5) group by price// 统计进入的5个Apple事件，amount的总数和name，并按照price分组select price, name, sum(amount) from Apple.win:length_batch(5) group by price最后一个和前一个的区别在于name也在统计的范围内，所以当name和price都一样的两个事件进入Esper，会有两个一模一样的事件作为newEvent触发UpdaterListener，即price，name，sum(amount)都一样。当然要是group by name, price的话，就只会有一个事件触发监听器了。
今天介绍了Esper处理事件时的一些基本知识，对以后的深入学习是必不可少的。明天会再写一篇，内容是关于context，中文翻译为上下文我觉得不妥，我的理解是对EPL的运行增加了外在约束，想继续学习的请继续关注。
