曾经参与的数据实时提醒的一种设计回顾

背景描述：这一篇说到指挥平台基本都是统计，大部分统计都是前一天的数据，也有一些统计是要求实.时的，今日动态就是实时统计中的一种：显示一些业务新增的记录数和记录信息

设计分为两部分，一部分是提供数据，一部分是查询数据

提供数据：通过Schedule线程池定时调度各业务查询实现，查询新增的数据，然后插入实时数据中间表

查询数据：维持一个SseEmitter连接

由一个线程通过EventStream实时向前端推送

SseEmitter发送数据

 

1.提供数据大概的实现过程

大概过程是各业务实现事件抽取接口，查询新增的数据，由一个抽取器调用，向Redis写数据，然后再从Redis里面拿数据向实时数据表写入

1.1 业务事件抽取器

抽取指定范围内的业务事件

1.2 事件Poll器

Scheduled线程池定时抽取

初始化Bean后，afterPropertiesSet 

获取所有实现的抽取器

然后分桶，通过线程池定时调度。map的key是桶号，value是对应的抽取器集合 

对于每一个抽取器，通过线程池调度

ExtractJob实现Runnable方法

 

 run方法

下面就执行抽取

1.3 从redis将动态消息抽取到实时数据表

也是维护了一个Scheduled线程池

afterPropertiesSet设置这个线程池

从Redis读取

2.查询数据大概的实现过程

大概过程是这样

2.1 维护客户端队列和数据提供器无界队列

2.2 数据提供器supplier查询数据 

 

 2.3 向客户端推送

 SseEmitter.event的数据由SseEmitterHolder提供，在初始化客户端时调用init方法，调用supplier的方法

思考和讨论：

1.这里用到了Scheduled线程池线程池，什么时候可以用Scheduled线程池？

在需要定时调度的场景下可以考虑Scheduled线程池，并且是要可以自己接管的。咱们说的分布式调度框架一般不能自己接管调用过程、结果等。这是我的思考。

2.为什么提供数据和查询数据要分开

这个我觉得要实现数据实时展示其实是一个复杂的过程，首先要确定数据来源再是数据如何展示，将提供数据和查询数据分开也是一种解耦，出问题时可以从两个方面去排查，如果在一个过程连续完成，局面有点太大了，就有点面向结构化(过程)的设计了，不太符合面向对象的设计。

3.为什么数据要先放到Redis

我觉得主要是因为要展示的数据格式和查询出的数据要做转换，Redis作为缓存或内存数据库，在这里起到内存数据库的作用，是一个中间层，起到承上启下的作用。

4.hash code不和保证唯一性

这里是通过Hashing.murmur3_128实现，不是很了解

这里的目的是为了比较事件间的hash值来增量添加而不是全量添加，这一块没有深入debug过，感觉是那么回事但不是很确定。通过事件的hash和redis记录的hash比较判断当前事件是否需要更新

这个过程挺复杂的，如果要自己设计，照葫芦画瓢或许可以，但核心是设计思路和为什么要这么设计，现在是别人实现了去看，自己设计并实现的过程中肯定会遇到很多问题，这也是必须要经历的过程。

以上思考都是个人观点，也主要是给自己看看，有疑问的朋友欢迎一起讨论。