PRF:20171003 Streams a new general purpose data structure in Redis.md

终校。整体来说，这篇经过两次翻译、三次校对，已经质量非常令我满意了。可能这篇或许会比较艰深，不过这种精品才是最有价值的，辛苦两位了！

translated/tech/20171003 Streams a new general purpose data structure in Redis.md

@@ -3,13 +3,13 @@ Streams：一个新的 Redis 通用数据结构
 
 直到几个月以前，对于我来说，在消息传递的环境中，<ruby>流<rt>streams</rt></ruby>只是一个有趣且相对简单的概念。这个概念在 Kafka 流行之后，我主要研究它们在 Disque 案例中的应用，Disque 是一个消息队列，它将在 Redis 4.2 中被转换为 Redis 的一个模块。后来我决定让 Disque 都用 AP 消息[1]，也就是说，它将在不需要客户端过多参与的情况下实现容错和可用性，这样一来，我更加确定地认为流的概念在那种情况下并不适用。
 
-然而在那时 Redis 有个问题，那就是缺省情况下导出数据结构并不轻松。它在 Redis <ruby>列表<rt>list</rt></ruby>、<ruby>有序集合<rt>sorted list</rt></ruby>、<ruby>发布/订阅<rt>Pub/Sub</rt></ruby>功能之间有某些缺陷。你可以权衡使用这些工具对一个消息或事件建模。
+然而在那时 Redis 有个问题，那就是缺省情况下导出数据结构并不轻松。它在 Redis <ruby>列表<rt>list</rt></ruby>、<ruby>有序集<rt>sorted list</rt></ruby>、<ruby>发布/订阅<rt>Pub/Sub</rt></ruby>功能之间有某些缺陷。你可以权衡使用这些工具对一系列消息或事件建模。
 
-排序集合是内存消耗大户，那自然就不能对投递相同消息进行一次又一次的建模，客户端不能阻塞新消息。因为有序集合并不是一个序列化的数据结构，它是一个元素可以根据它们量的变化而移动的集合：所以它不像时序性的数据那样。
+有序集是内存消耗大户，那自然就不能对投递的相同消息进行一次又一次的建模，客户端不能阻塞新消息。因为有序集并不是一个序列化的数据结构，它是一个元素可以根据它们量的变化而移动的集合：所以它不像时序性的数据那样。
 
-列表有另外的问题，它在某些特定的用例中产生类似的适用性问题：你无法浏览列表中间的内容，因为在那种情况下，访问时间是线性的。此外，没有任何指定输出的功能，列表上的阻塞操作仅为单个客户端提供单个元素。列表中没有固定的元素标识，也就是说，不能指定从哪个元素开始给我提供内容。
+列表有另外的问题，它在某些特定的用例中会产生类似的适用性问题：你无法浏览列表中间的内容，因为在那种情况下，访问时间是线性的。此外，没有任何指定输出的功能，列表上的阻塞操作仅为单个客户端提供单个元素。列表中没有固定的元素标识，也就是说，不能指定从哪个元素开始给我提供内容。
 
-对于一对多的工作任务，有发布/订阅机制，它在大多数情况下是非常好的，但是，对于某些不想<ruby>“即发即弃”<rt>fire-and-forget</rt></ruby>的东西：保留一个历史是很重要的，不只是因为是断开之后重新获得消息，也因为某些如时序性的消息列表，用范围查询浏览是非常重要的：在这 10 秒范围内温度读数是多少？
+对于一对多的工作任务，有发布/订阅机制，它在大多数情况下是非常好的，但是，对于某些不想<ruby>“即发即弃”<rt>fire-and-forget</rt></ruby>的东西：保留一个历史是很重要的，不只是因为是断开之后会重新获得消息，也因为某些如时序性的消息列表，用范围查询浏览是非常重要的：比如在这 10 秒范围内温度读数是多少？
 
 我试图解决上述问题，我想规划一个通用的有序集合，并列入一个独特的、更灵活的数据结构，然而，我的设计尝试最终以生成一个比当前的数据结构更加矫揉造作的结果而告终。Redis 有个好处，它的数据结构导出更像自然的计算机科学的数据结构，而不是 “Salvatore 发明的 API”。因此，我最终停止了我的尝试，并且说，“ok，这是我们目前能提供的”，或许我会为发布/订阅增加一些历史信息，或者为列表访问增加一些更灵活的方式。然而，每次在会议上有用户对我说 “你如何在 Redis 中模拟时间系列” 或者类似的问题时，我的脸就绿了。
 
@@ -22,7 +22,7 @@ Streams：一个新的 Redis 通用数据结构
 
 他的思路启发了我。我想了几天，并且意识到这可能是我们马上同时解决上面所有问题的契机。我需要去重新构思 “日志” 的概念是什么。日志是个基本的编程元素，每个人都使用过它，因为它只是简单地以追加模式打开一个文件，并以一定的格式写入数据。然而 Redis 数据结构必须是抽象的。它们在内存中，并且我们使用内存并不是因为我们懒，而是因为使用一些指针，我们可以概念化数据结构并把它们抽象，以使它们摆脱明确的限制。例如，一般来说日志有几个问题：偏移不是逻辑化的，而是真实的字节偏移，如果你想要与条目插入的时间相关的逻辑偏移应该怎么办？我们有范围查询可用。同样，日志通常很难进行垃圾回收：在一个只能进行追加操作的数据结构中怎么去删除旧的元素？好吧，在我们理想的日志中，我们只需要说，我想要数字最大的那个条目，而旧的元素一个也不要，等等。
 
-当我从 Timothy 的想法中受到启发，去尝试着写一个规范的时候，我使用了 Redis 集群中的 radix 树去实现，优化了它内部的某些部分。这为实现一个有效利用空间的日志提供了基础，而且仍然可以用<ruby>对数时间<rt>logarithmic time</rt></ruby>来访问范围。同时，我开始去读关于 Kafka 流以获得另外的灵感，它也非常适合我的设计，最后借鉴了 Kafka <ruby>消费群体<rt>consumer groups</rt></ruby>的概念，并且再次针对 Redis 进行优化，以适用于 Redis 在内存中使用的情况。然而，该规范仅停留在纸面上，在一段时间后我几乎把它从头到尾重写了一遍，以便将我与别人讨论的所得到的许多建议一起增加到 Redis 升级中。我希望 Redis 流能成为对于时间序列有用的特性，而不仅是一个常见的事件和消息类的应用程序。
+当我从 Timothy 的想法中受到启发，去尝试着写一个规范的时候，我使用了 Redis 集群中的 radix 树去实现，优化了它内部的某些部分。这为实现一个有效利用空间的日志提供了基础，而且仍然有可能在<ruby>对数时间<rt>logarithmic time</rt></ruby>内访问范围。同时，我开始去读关于 Kafka 的流相关的内容以获得另外的灵感，它也非常适合我的设计，最后借鉴了 Kafka <ruby>消费组<rt>consumer groups</rt></ruby>的概念，并且再次针对 Redis 进行优化，以适用于 Redis 在内存中使用的情况。然而，该规范仅停留在纸面上，在一段时间后我几乎把它从头到尾重写了一遍，以便将我与别人讨论的所得到的许多建议一起增加到 Redis 升级中。我希望 Redis 流能成为对于时间序列有用的特性，而不仅是一个常见的事件和消息类的应用程序。
 
 ### 让我们写一些代码吧
 
@@ -159,7 +159,7 @@ QUEUED
 
 ### 内存使用和节省加载时间
 
-因为用来建模 Redis 流的设计，内存使用率是非常低的。这取决于它们的字段、值的数量和长度，对于简单的消息，每使用 100MB 内存可以有几百万条消息。此外，格式设想为需要极少的序列化：listpack 块以 radix 树节点方式存储，在磁盘上和内存中都以相同方式表示的，因此它们可以很轻松地存储和读取。例如，Redis 可以在 0.3 秒内从 RDB 文件中读取 500 万个条目。这使流的复制和持久存储非常高效。
+因为用来建模 Redis 流的设计，内存使用率是非常低的。这取决于它们的字段、值的数量和长度，对于简单的消息，每使用 100MB 内存可以有几百万条消息。此外，该格式设想为需要极少的序列化：listpack 块以 radix 树节点方式存储，在磁盘上和内存中都以相同方式表示的，因此它们可以很轻松地存储和读取。例如，Redis 可以在 0.3 秒内从 RDB 文件中读取 500 万个条目。这使流的复制和持久存储非常高效。
 
 我还计划允许从条目中间进行部分删除。现在仅实现了一部分，策略是在条目在标记中标识条目为已删除，并且，当已删除条目占全部条目的比例达到指定值时，这个块将被回收重写，如果需要，它将被连到相邻的另一个块上，以避免碎片化。
 
@@ -175,7 +175,7 @@ via: http://antirez.com/news/114
 
 作者：[antirez][a]
 译者：[qhwdw](https://github.com/qhwdw)
-校对：[wxy](https://github.com/wxy)、[pityonline](https://github.com/pityonline)
+校对：[wxy](https://github.com/wxy), [pityonline](https://github.com/pityonline)
 
 本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出