数据亲和架构--事件矩阵

        事件模型对于提高系统性能起到关键的作用,特别是网络IO模型,如EPOLL和IOCP已经深入人心。还有比较少为人知的事件处理引擎,用于高性能的商业逻辑实现。网络IO模型位于系统底层,深入研究的人为数不多,幸好接口很简洁,绑定句柄和事件,当事件触发时,会通知上层应用。在网络IO模型中,可以管理大量的句柄,但事件却只能是有限的几种,一个EPOLL句柄只能算一个观察者。

        在现实生活中的网络购物,在购物平台下单后,物流会自动配送。在到达后,快递小哥会通知我们,不需要我们随时候着【阻塞模式】,或者定期打电话问到了没有【轮询模式】,正常要干嘛还是干嘛去。一年一度的购物狂欢节双11马上要到了,我们会在多个店铺购物,甚至每个店铺都可能下多个订单,完全看心情。在我们接到快递小哥通知时,就是多个事件。这个事件的数量依赖于我们的购物疯狂程度。与此同时,每个网店乃至于每个热销商品,又可能被无数个购物者关注。

        我们知道,在真实的场景中,事件源、事件、观察者他们之间是天然的多对多关系。一个事件源可以触发多种事件,比如某个明星的花边八卦;而每个事件源又可以被多个观察者关注,比如近期关于李咏和金庸先生逝世的消息;同样,对于一个观察者来说,也可能会同时关注多个事件,如近期的房价涨跌,或者孩子的教育资讯。

        如上所述,在传统的事件模型中,对事件的数量进行限制,限定一个观察者,这样简化了整个模型实现,但与真实场景不符,就限制了它的应用范围。特别是上层应用在处理,依然需要进行二次分发,而这些分发的处理逻辑其实和底层分发是一致。这在技术上,是一种浪费。

        事件矩阵基于EPOLL的原理,将事件数量扩大为无限制,而不止32位,同时允许多个观察者。因此,事件和句柄就构成了一个对应矩阵 M(atrix) = E(vent) *  H(handle),这个对应矩阵是一个固定的对应矩阵,意味着每个句柄能够触发的事件是已知的,但每个句柄之间可以触发不同的事件。这一点和传统的事件模型是不同的。而事件矩阵的每个节点可以挂接多个观察者,每个观察者又可以关注多个事件源。于是,整个矩阵就形成一个复杂而巨大的矩阵M(atrix) = E(vent) *  H(handle) * W(atcher)。幸好,通常这些关联是稀疏矩阵。

        数据亲和架构为了更好更快地管理数据,需要及时有效的监控到多种数据的变化,并予以统一调度,因此事件矩阵作为基础技术支撑。不单于此,事件矩阵更贴近于真实场景需求,因此可以将事件模型推广到更大的应用场景。

你可能感兴趣的:(数据亲和架构--事件矩阵)