doc: 阅读redis stream文档

中间件/redis/redis.md

@@ -123,6 +123,9 @@
       - [removing single items from a stream](#removing-single-items-from-a-stream)
         - [XDEL](#xdel)
         - [Enhanced deletion with XDELEX](#enhanced-deletion-with-xdelex)
+      - [zero length streams](#zero-length-streams)
+      - [Total latency of consuming a message](#total-latency-of-consuming-a-message)
+      - [The model redis uses in order to route stream messages](#the-model-redis-uses-in-order-to-route-stream-messages)
 
 
 # redis
@@ -2179,7 +2182,37 @@ stream同样支持`removing items from the middle of a stream`，尽管stream为
 ```redis-cli
 XDELEX mystream ACKED IDS 2 1692633198206-0 1692633208557-0
 ```
-- 在使用`ACKED`模式时，仅在entries已经被所有consumer groups都acknowledged之后，才能够对entries进行删除
+- 在使用`ACKED`模式时，仅在指定entries已经被所有consumer groups都acknowledged之后，才能够对entries进行删除
-- 在使用`DELREF`时，会删除所有的consumer group reference
+- 在使用`DELREF`模式时，会移除指定entries，并清除所有consumer groups' PEL中的指定entries
-- 在使用`KEEPREF`时，
+- 在使用`KEEPREF`模式时，会移除指定entries，并对consumer groups' PEL中的entries引用进行保留 
+
+> 对于通过KEEPREF模式移除entries的场景，如果entries从stream中被移除，但是PEL中仍然存在entries references，`此时XCLAIM操作并无法对该类entries进行认领`
+
+#### zero length streams
+redis stream数据类型和redis的其他数据结构存在差别，
+- 当其他数据结构中不再包含任何元素时，作为`calling commands that remove elements`的副作用，该key本身也会被自动移除
+  - 例如，当通过`ZREM`命令移除zset中的最后一个元素时，该zset本身也会被彻底移除
+- 而redis stream类型的数据则是允许`stay at zero elements`，即使通过`MAXLEN` option或是`XDEL`调用令stream类型数据的entries数量为0，该stream也不会被自动移除
+
+目前，即使当stream没有对应的consumer groups，当某command导致stream中的entries数量为0时，stream也不会被删除
+
+#### Total latency of consuming a message
+对于非阻塞命令（例如`XRANGE, XREAD, XREADGROUP without BLOCK option`）redis是同步对其进行处理的，其处理同其他的一般redis命令相同，对于这类commands并不需要讨论其latency。
+
+但是，对于`delay of processing a message`，其拥有如下定义：
+- `in the context of blocking consumers in a consumer group, from the moment the message is produced via XADD to the moment the message is obtained by the consumer because XREADGROUP returned with the message`
+
+#### The model redis uses in order to route stream messages
+redis通过如下方式来管理`blocking operation waiting for data`：
+- 对于blocked client，其会在hash table中被引用。hash table中的key其对应的blocking consumers至少存在一个，而hash table中的value则是`a list of consumers that are waiting for such key`。
+  - 通过上述管理方式，如果一个key接收到消息，则可以解析所有等待该data的clients
+- 当发生写操作，例如`XADD`时，其会调用`signalKeyAsReady`方法。该方法会将key添加到`a list of keys that need to be processed`，该list中的key对于blocked consumers存在新的数据，被称为`ready keys`
+  - `ready keys`后续会被处理，故而在相同的event loop cycle中，该key可能还会接收到其他的写操作(XADD)
+- 在返回event loop之前，`ready keys`最终被处理，对于每一个key，`the list of clients waiting for data`都会被扫描，如果适用，那么client将会接收到new data。
+
+如上述描述所示，在返回到event loop之前，对`调用XADD的client`和`clients blocked to consume messages`其reply都会出现在ouput buffers中。故而，`caller of XADD`收到reply的时间将会和`blocked clients`接收到新消息的时间几乎相同
+
+上述model是push-based的，将消息添加到consumer buffers的操作将直接由`XADD`调用来执行。
+
+