事件模型对于提高系统性能起到关键的作用，特别是网络IO模型，如EPOLL和IOCP已经深入人心。还有比较少为人知的事件处理引擎，用于高性能的商业逻辑实现。网络IO模型位于系统底层，深入研究的人为数不多，幸好接口很简洁，绑定句柄和事件，当事件触发时，会通知上层应用。在网络IO模型中，可以管理大量的句柄，但事件却只能是有限的几种，一个EPOLL句柄只能算一个观察者。
在现实生活中的网络购物，在购物平台下单后，物流会自动配送。在到达后，快递小哥会通知我们，不需要我们随时候着【阻塞模式】，或者定期打电话问到了没有【轮询模式】，正常要干嘛还是干嘛去。一年一度的购物狂欢节双11马上要到了，我们会在多个店铺购物，甚至每个店铺都可能下多个订单，完全看心情。在我们接到快递小哥通知时，就是多个事件。这个事件的数量依赖于我们的购物疯狂程度。与此同时，每个网店乃至于每个热销商品，又可能被无数个购物者关注。
我们知道，在真实的场景中，事件源、事件、观察者他们之间是天然的多对多关系。一个事件源可以触发多种事件，比如某个明星的花边八卦；而每个事件源又可以被多个观察者关注，比如近期关于李咏和金庸先生逝世的消息；同样，对于一个观察者来说，也可能会同时关注多个事件，如近期的房价涨跌，或者孩子的教育资讯。
如上所述，在传统的事件模型中，对事件的数量进行限制，限定一个观察者，这样简化了整个模型实现，但与真实场景不符，就限制了它的应用范围。特别是上层应用在处理，依然需要进行二次分发，而这些分发的处理逻辑其实和底层分发是一致。这在技术上，是一种浪费。
事件矩阵基于EPOLL的原理，将事件数量扩大为无限制，而不止32位，同时允许多个观察者。因此，事件和句柄就构成了一个对应矩阵 M(atrix) = E(vent) * H(handle)，这个对应矩阵是一个固定的对应矩阵，意味着每个句柄能够触发的事件是已知的，但每个句柄之间可以触发不同的事件。这一点和传统的事件模型是不同的。而事件矩阵的每个节点可以挂接多个观察者，每个观察者又可以关注多个事件源。于是，整个矩阵就形成一个复杂而巨大的矩阵M(atrix) = E(vent) * H(handle) * W(atcher)。幸好，通常这些关联是稀疏矩阵。
数据亲和架构为了更好更快地管理数据，需要及时有效的监控到多种数据的变化，并予以统一调度，因此事件矩阵作为基础技术支撑。不单于此，事件矩阵更贴近于真实场景需求，因此可以将事件模型推广到更大的应用场景。
