|
关于 XRANGE 必要留意的最重要的工作是，假设我们在回覆中收到 ID，随后持续的 ID 只是增进了序号部门，以是可以行使 XRANGE 遍历整个流，吸取每个挪用的指定个数的元素。Redis 中的*SCAN 系列呼吁应承迭代 Redis 数据布局，尽量究竟上它们不是为迭代计划的，但这样可以停止再犯沟通的错误。
行使 XREAD 处理赏罚流播：阻塞新的数据
当我们想通过 ID 或时刻去会见流中的一个范畴可能是通过 ID 去获取单个元素时，行使 XRANGE 长短常美满的。然而，在行使流的案例中，当数据达到时，它必需由差异的客户端来斲丧时，这就不是一个很好的办理方案，这必要某种情势的汇聚池。（对付 某些 应用措施来说，这也许是个好主意，由于它们仅是无意毗连查询的）
XREAD 呼吁是为读取计划的，在统一个时刻，从多个流中仅指定我们从该流中获得的最后条目标 ID。另外，假如没稀有据可用，我们可以要求阻塞，当数据达到时，就扫除阻塞。相同于阻塞列表操纵发生的结果，可是这里并没有斲丧从流中获得的数据，而且多个客户端可以同时会见统一份数据。
这里有一个典范的 XREAD 挪用示例：
> XREAD BLOCK 5000 STREAMS mystream otherstream $ $
它的意思是：从 mystream 和 otherstream 取得数据。假如没稀有据可用，阻塞客户端 5000 毫秒。在 STREAMS 选项之后指定我们想要监听的要害字，最后的是指定想要监听的 ID，指定的 ID 为 $ 的意思是：假设我此刻必要流中的全部元素，因此，只必要从下一个达到的元素开始给我。
假如我从另一个客户端发送这样的呼吁：
> XADD otherstream * message “Hi There”
在 XREAD 侧会呈现什么环境呢？
1) 1) "otherstream" 2) 1) 1) 1506935385635.0 2) 1) "message" 2) "Hi There"
与收到的数据一路，我们也获得了数据的要害字。在下次挪用中，我们将行使吸取到的最新动静的 ID：
> XREAD BLOCK 5000 STREAMS mystream otherstream $ 1506935385635.0
依次类推。然而必要留意的是行使方法，客户端有也许在一个很是大的耽误之后再次毗连（由于它处理赏罚动静必要时刻，可能其余什么缘故起因）。在这种环境下，时代会有许多动静会萃，为了确保客户端不被动静沉没，以及处事器不会由于给单个客户端提供大量动静而挥霍太多的时刻，行使 XREAD 的 COUNT 选项长短常明智的。
流封顶
今朝看起来还不错……然而，有些时辰，流必要删除一些旧的动静。荣幸的是，这可以行使 XADD 呼吁的 MAXLEN 选项去做：
> XADD mystream MAXLEN 1000000 * field1 value1 field2 value2
它是根基意思是，假如在流中添加新元素后发明动静数目高出了 1000000 个，那么就删除旧的动静，以便于元素总量从头回到 1000000 以内。它很像是在列表中行使的 RPUSH + LTRIM，可是，这次我们是行使了一个内置机制去完成的。然而，必要留意的是，上面的意思是每次我们增进一个新的动静时，我们还必要其它的事变去从流中删除旧的动静。这将耗损一些 CPU 资源，以是在计较 MAXLEN 之前，尽也许行使 ~ 标记，以表白我们不要求很是 准确 的 1000000 个动静，就是轻微多一些也不是大题目：
> XADD mystream MAXLEN ~ 1000000 * foo bar
这种方法的 XADD 仅当它可以删除整个节点的时辰才会删除动静。对比平凡的 XADD，这种方法险些可以自由地对流举办封顶。
斲丧组（开拓中）
这是第一个 Redis 中尚未实现而在开拓中的特征。灵感也是来自 Kafka，尽量在这里是以差异的方法实现的。重点是行使了 XREAD，客户端也可以增进一个 GROUP <name> 选项。沟通组的全部客户端将自动获得 差异的 动静。虽然，统一个流可以被多个组读取。在这种环境下，全部的组将收到流中达到的动静的沟通副本。可是，在每个组内，动静是不会一再的。
当指定组时，可以或许指定一个 RETRY <milliseconds> 选项去扩展组：在这种环境下，假如动静没有通过 XACK 举办确认，它将在指定的毫秒数后举办再次投递。这将为动静投递提供更佳的靠得住性，这种环境下，客户端没有私有的要领将动静标志为已处理赏罚。这一部门也正在开拓中。
内存行使和节减加载时刻 （编辑：湖南网）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
|
