前阵子因为工作上的一个需求, 撸了个类似 IFTTT 的触发器的玩意儿. 既然是个触发器, 就应该还有后续的动作. 问题是对于一个被动触发的这么一个响应式的系统, 后续的动作应该是 Non-blocking 的, 而且最好没有副作用, 纯函数. 但是加了这么个限制之后吧, 这个动作能做的事情就实在是太少了. 这, 是遇到的这个问题的前提.
先放个图介绍一下大体的一个触发逻辑 (Mermaid 渲染的, 将就看, 后面换 Ant Design Charts 画一个).
设计上, 每个触发器和随后的行为都是链式的, 进入触发器的事件会被传给行为, 行为又会把自己的输出传给下个行为或者触发器. 在一个没有副作用的世界里, 这当然是好的. 但是当不得不执行一个很耗时的行为的时候, 让后续的行为去等显然不是个好选择.
当然, 这个问题也好解决. 把链上余下的行为和触发器, 做成一个新的一次性的触发器, 挂在 Root 底下就好了. 行为继续执行, 直到成功后发送个能且仅能被之前新建的触发器触发的事件就好了.
但这又引入了新的问题... 过量的顶层触发器显然会大幅影响整个系统的性能. 毕竟 Root 下的这些并列的触发器, 是通过遍历去测试是否应该触发的.
直到今天摸鱼的时候跟朋友提到了这个问题. 突然想到, 也许这个事情不是不能解决. 假设有这么一个算法可以大幅减少需要遍历的触发器的数量, 那么上面的问题也就缓解很多了.
具象化一下这么个想法的话, 就是去计算进入系统的事件, 离他可能遇到的触发器的距离, 对这个距离设置一个合适的阈值, 就能大幅降低所需要的资源了.
想象事件是从高维进入一个铺满触发器的平面. 每个触发器的的条件都是从原点如何到达他所在的位置. 既然触发器的位置已经确定了, 那么对于每个进入系统的事件, 计算他大致的落点, 就可以在一个很有限的范围去遍历触发器了.
当然, 这只是个很粗浅的想法. 具体实现上, 完全没有头绪. 鉴于输入的事件只需要是一个合法的 JSON , 可能的变数太多. 预先计算触发器位置的做法也完全有可能行不通.
也许这想法本身就不靠谱. 嗐, 管他呢, 总之先把想法记下来, 免得过两天又忘了...
