From e6c7090529181b0071775907dbf79b1b3500936f Mon Sep 17 00:00:00 2001 From: wxy Date: Wed, 29 Nov 2017 05:02:44 +0800 Subject: [PATCH] PRF:20171003 Streams a new general purpose data structure in Redis.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 部分校对 --- ... a new general purpose data structure in Redis.md | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/translated/tech/20171003 Streams a new general purpose data structure in Redis.md b/translated/tech/20171003 Streams a new general purpose data structure in Redis.md index bb21a1bd93..39da54d0cf 100644 --- a/translated/tech/20171003 Streams a new general purpose data structure in Redis.md +++ b/translated/tech/20171003 Streams a new general purpose data structure in Redis.md @@ -1,15 +1,13 @@ -[Streams：Redis中新的一个通用数据结构][1] +streams：一个新的 Redis 通用数据结构 ================================== +直到几个月以前，对于我来说，在消息传递的环境中，streams 只是一个有趣且相对简单的概念。在 Kafka 流行这个概念之后，我主要研究它们在 Disque 实例中的用途。Disque 是一个将会转化为 Redis 4.2 的模块的消息队列。后来我发现 Disque 全都是 AP 消息，它将在不需要客户端过多参与的情况下实现容错和保证送达，因此，我认为 streams 的概念在那种情况下并不适用。 -直到几个月以前，对于我来说，在消息传递的环境中，streams 只是一个有趣且相对简单的概念。在 Kafka 概念普及之后，我主要研究他们在 Disque 实例中的效能。Disque 是一个将被转化到 Redis 4.2 模块中的消息队列。后来我明白 Disque 将是关于 AP 消息的全部，它将在不需要客户端过多参与的情况下实现容错和保证送达，因此，我认为 streams 的概念在那种情况下并不适用。 +但是，在 Redis 中有一个问题，那就是缺省情况下导出数据结构并不轻松。它在 Redis 列表、排序集和发布/订阅（Pub/Sub）能力上有某些缺陷。你可以合适地使用这些工具去模拟一个消息或事件的序列，而有所权衡。排序集是大量耗费内存的，不能自然的模拟一次又一次的相同消息的传递，客户端不能阻塞新消息。因为一个排序集并不是一个序列化的数据结构，它是一个根据它们量的变化而移动的元素集：它不是很像时间系列一样的东西。列表有另外的问题，它在某些特定的用例中产生类似的适用性问题：你无法浏览列表中部是什么，因为在那种情况下，访问时间是线性的。此外，没有任何的指定输出功能，列表上的阻塞操作仅为单个客户端提供单个元素。列表中没有固定的元素标识，也就是说，不能指定从哪个元素开始给我提供内容。对于一到多的工作负载，这里有发布/订阅，它在大多数情况下是非常好的，但是，对于某些不想“即发即弃”的东西：保留一个历史是很重要的，而不是断开之后重新获得消息，也因为某些消息列表，像时间系列，在用范围查询浏览时，是非常重要的：在这 10 秒范围内我的温度读数是多少？ -但是，在 Redis 中有一个问题，那就是从缺省导出数据结构并不轻松。它在 Redis 列表、排序集和发布/订阅（Pub/Sub）能力上有某些缺陷，你可以权衡差异，友好地使用这些工具去模拟一个消息或事件的序列。排序集是大量耗费内存的，不能用相同的消息模型一次又一次的传递，客户端不能阻塞新消息。因为一个排序集并不是一个序列化的数据结构，它是一个根据他们量的变化而变化的元素集：它不是像时间系列一样很适合的东西。列表有另外的问题，它在某些用户案例中产生适用性问题：你无法浏览列表中是什么，因为在那种情况下，访问时间是线性的。此外，没有任何输出，列表上的阻塞操作仅为单个客户端提供单个元素。比如说：从那个元素开始给我提供内容，列表中也没有固定的元素标识。对于一到多的工作负载，这里有发布/订阅，它在大多数情况下是非常好的，但是，对于某些不想“即发即弃”的东西：去保留一个历史是很重要的，而不是断开之后重新获得消息，也因为某些消息列表，像时间系列，在用范围查询浏览时，是非常重要的：在这 10 秒范围内我的温度读数是多少？ +这有一种方法可以尝试处理上面的问题，我计划对排序集进行通用化，并列入一个唯一的、更灵活的数据结构，然而，我的设计尝试最终以生成一个比当前的数据结构更加矫揉造作的结果而结束。一个关于 Redis 数据结构导出的更好的想法是，让它更像天然的计算机科学的数据结构，而不是，“Salvatore 发明的 API”。因此，在最后我停止了我的尝试，并且说，“ok，这是我们目前能提供的”，或许，我将为发布/订阅增加一些历史信息，或者将来对列表访问增加一些更灵活的方式。然而，每次在会议上有用户对我说“你如何在 Redis 中模拟时间系列” 或者类似的问题时，我的脸就绿了。 -这有一种方法可以尝试处理上面的问题，计划对排序集进行通用化，并列入一个唯一的更灵活的数据结构，然而，我的设计尝试最终以生成一个相对当前的人造的数据结构的结果结束，一个关于 Redis 数据结构导出的更好的想法是，让它更像天然的计算机科学的数据结构。而不是, “Salvatore 发明的 API”。因此，在最后我停止了我的尝试，并且说，“ok，这是我们目前能提供的”，或许，我将为发布/订阅增加一些历史，或者将来对列表访问增加一些更灵活的方式。然而，每次在会议上有用户对我说“你如何在 Redis 中模拟时间系列” 或者类似的问题时，我的脸变绿了。 - -起源 -======= +### 起源 在将 Redis 4.0 中的模块介绍完之后，用户开始去看他们自己怎么去修复这些问题。他们之一，Timothy Downs，通过 IRC 写信给我：