diff --git "a/content/posts/\346\227\266\345\272\217\346\225\260\346\215\256\350\247\204\345\210\231\345\274\225\346\223\216\350\256\276\350\256\241\346\200\235\350\267\257.md" "b/content/posts/\346\227\266\345\272\217\346\225\260\346\215\256\350\247\204\345\210\231\345\274\225\346\223\216\350\256\276\350\256\241\346\200\235\350\267\257.md"
index 04122384..53ce9f54 100644
--- "a/content/posts/\346\227\266\345\272\217\346\225\260\346\215\256\350\247\204\345\210\231\345\274\225\346\223\216\350\256\276\350\256\241\346\200\235\350\267\257.md"
+++ "b/content/posts/\346\227\266\345\272\217\346\225\260\346\215\256\350\247\204\345\210\231\345\274\225\346\223\216\350\256\276\350\256\241\346\200\235\350\267\257.md"
@@ -13,7 +13,21 @@ featuredImage:
 draft: false
 ---
 
-在物联网数据、日志收集等场景中，基于时序数据来做一些规则的需求一直存在，最简单的比如告警、通知等。实现思路也有很多，大致记载一下。
+规则引擎的大致组成包括：
+
+1. 触发条件：如某个设备某种消息在某个时间点内到达；或周期性，每隔多久触发一次；
+2. 触发响应：即触发条件后要做什么，一般是告警、通知、联动其他设备、联动其他系统等；
+3. 边界情况：重复触发如何处理、回调频率控制等细节；
+
+实现思路大致包括以下几种：
+
+## 基于消息回调
+
+即在消息到达服务器时，执行指定回调。常见的有webhook、执行脚本文件（如js）、或执行java的jar包等等。
+
+**该方案在消息频繁触达时性能较差**，并且容易造成重复计算，但是理论上也能满足一般的计算需求。回调方可以调用数据接口查询相关的数据做任意运算，再根据结果来触发告警或其他行为。
+
+目前墨斗平台内置的规则引擎即基于此架构，不过触发响应是写死的几种，还不包括上面这些更灵活的方式。**理论上来说**，客户基于rabbitmq自己订阅消息来实现对应的逻辑也是一样的。
 
 ## 基于周期性计算
 
@@ -29,19 +43,15 @@ draft: false
 
 此外，这种方式计算的数据并不会入库。当然如果是时序数据，可以基于ts定时计算后再入库，因为时序数据是不变的。如果是一般的数据，需要计算入库就必须用流式计算来进行了。
 
-## 基于物化视图
-
-部分时序数据库（如TDEngine、Clickhouse）支持类似物化视图的技术，可以在输入写入库时，直接基于物化视图计算出需要的值。不过这个只能用于规则引擎输出统计值时，如果想要告警，还是需要订阅物化视图的数据变更，然后回调。
-
 ## 基于实时流计算
 
 即类似FlinkCDC的思路来做。thingsboard的规则引擎是基于消息到来时进行触发，但是只能处理单条消息，没有使用时间窗口技术，所以是个半成品。真正的流计算必须使用类似Flink的时间窗口技术，并允许跨多条消息进行处理。
 
-这种情况下，平台应提供允许客户自行上传jar包，或者脚本的方式来写处理逻辑。每当有数据到来时，如果满足用户自己设置的规则条件，则回调用户自己写的处理逻辑即可。该方案对使用者的要求较高，必须是开发者才能正确处理。
+与基于消息回调不同，实时流计算可以将需要计算的数据缓存在内存中，通过时间窗口来维护变量的生命周期，其性能比回调时去查询数据库要高的多。
 
 ## 建议实施步骤
 
-基于单条数据的实时处理最为简单，可以优先实现，满足5成以上的需求；
+基于单条数据的实时处理、或回调触发最为简单，可以优先实现，满足5成以上的需求；
 
 基于周期性计算的规则引擎更容易图形化，实现起来也相对简单（但是要采用一种DSL），非即时计算的场景可以采用该方案；