背景描述：这一篇说到指挥平台基本都是统计，大部分统计都是前一天的数据，也有一些统计是要求实.时的，今日动态就是实时统计中的一种：显示一些业务新增的记录数和记录信息
设计分为两部分，一部分是提供数据，一部分是查询数据
提供数据：通过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比较判断当前事件是否需要更新
这个过程挺复杂的，如果要自己设计，照葫芦画瓢或许可以，但核心是设计思路和为什么要这么设计，现在是别人实现了去看，自己设计并实现的过程中肯定会遇到很多问题，这也是必须要经历的过程。
以上思考都是个人观点，也主要是给自己看看，有疑问的朋友欢迎一起讨论。
