一种分布式复杂消息处理引擎设计与实现.docVIP

一种分布式复杂消息处理引擎设计与实现 　　摘要：阐述了一种高性能分布式复杂消息处理引擎的设计方案，这种引擎改进了传统复杂事件处理过程（CEP）处理引擎扩展性问题。新的设计方案通过将分布式无状态数据处理节点与分布式存储相结合，实现了复杂消息处理的规模和性能的线性扩展，同时避免了单点故障，保证了系统的高可靠性。 　　关键词： 复杂事件处理；流式计算；M2M；滑动窗口；实时计算 　　Abstract： This paper describes a high-performance， distributed， complex event processing engine that improves the scalability of a traditional complex event processing engine. In the design of this new complex event processing （CEP）， the stateless processing node is combined with distributed storage so that scale and performance can be linearly expanded. This design prevents single node failure and makes the system highly reliable. 　　Key words： CEP； stream processing； M2M； sliding window； real-time processing 　　中图分类号：TP393.03 文献标志码：A 文章编号：1009-6868 （2013） 04-0058-05 　　随着物联网和移动互联网的发展，整个世界已处于数据爆炸的进程中，这也导致了我们认识世界、处理数据的手段不断进步。数年前，各种企业系统还是一个个的信息孤岛，人们研究的重点在于获取信息、打通孤岛，这使得过去十年里人们一直热衷于面向服务的体系结构（SOA）的研究。但在现在这个信息爆炸的时代，每个系统、每个人面临的问题不再是无法获取信息，而是如何能够快速地从海量的信息中获取有价值的内容，并阻止无用的信息淹没有价值的内容。 　　物联网和互联网应用的一个共同特点是高并发、大数据量，海量消息系统不仅对消息处理的可靠性有一定的要求，对系统扩展性也有较高要求，希望能够从每秒几千次消息到上百万次消息平滑扩展。 　　电信领域的应用场景采用的实时监测用户信令和行为的方法，例如用户的每一次互联网访问请求、通话、短信、位置变更等信息都需要实时采集处理，并构建用户的行为模型。这个量更加巨大，百万人口的城市信令量就达到每秒数GB的量级，因此靠传统的离线处理基本不可能完成。 　　目前主要有两种海量实时数据处理方法：第1种方法是通过类似Map-reduce的方法进行在线采集、离线处理；第2种方法是事件流化，直接在内存中进行海量数据的运算和处理。对于消息系统，目前第1种方法有micro-mapreduce [1]，它可以将Map-reduce粒度变小，周期缩短，这种方法实时性稍差（5 min-1 h），但能够较好地处理可扩展性问题。第2种方法有现有开源的流式处理框架如S4，商用的产品如Oracle CEP[2]等，该方法能够将相关数据载入内存并进行计算，单机处理性能较高，但处理的可扩展性、容灾容错等存在一些问题，需要在前端进行数据分流，后端进行数据合并。 　　Storm[3] 提供了比较好的分布式解决方案，Storm集群有一个主节点和多个工作节点构成，工作节点与主节点通过Zookeeper协同工作。Storm本质上是一个可靠的分布式消息处理引擎，以保证每条消息都能够被处理。缺点在于其主节点存在单点问题，必须双机HA 2，并且没有时间窗机制，对于事件窗口，以及多路事件协同（例如发生事件A，如果同时过去30 s发生过事件B则生成新的事件C）没有比较好的支持。 　　对于复杂事件处理（CEP）来说，提供良好的用户使用界面非常有必要，常用的是使用类结构化查询语言（SQL）的事件处理语言（EPL）来定义事件处理逻辑。Cayuga[4]和Borealis[5]在EPL处理以及事件的服务质量（QoS）处理方面提供了很好的思路。 　　为达到可靠处理海量实时数据的目的，我们开发了一套全新的高性能分布式复杂消息处理引擎ZX-CEP，重点实现了以下一些能力： 　　·复杂事件数据的流式处理； 　　·高并发，单机支持每秒十万以上消息量，线性扩展能力较强； 　　·简单的EPL消息处理编排以及图形化处理流程编排； 　　·分布式计算，系统容量及处理能力的线性扩展；