PRF: 修正空白使用，标题及分割线标记风格

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

@@ -1,5 +1,5 @@
 Streams：一个新的 Redis 通用数据结构
-==================================
+======
 
 直到几个月以前，对于我来说，在消息传递的环境中，streams 只是一个有趣且相对简单的概念。这个概念在 Kafka 流行之后，我主要研究它们在 Disque 案例中的效能。Disque 是一个消息队列，它将在 Redis 4.2 中被转换为 Redis 的一个模块。后来我决定用 Disque 来做全部的 AP 消息，也就是说，它将在不需要客户端过多参与的情况下实现容错和保证送达，这样一来，我更加确定地认为 streams 的概念在那种情况下并不适用。
 
@@ -28,7 +28,7 @@ Streams：一个新的 Redis 通用数据结构
 
 从 Redis 大会回来后，在那个夏天，我实现了一个称为 “listpack” 的库。这个库是 `ziplist.c` 的继任者，它是表示在单个分配中的字符串元素列表的一个数据结构。它是一个非常专业的序列化格式，其特点在于也能够以逆序（从右到左）进行解析：在所有的案例中是用于代替 ziplists 所做的事情。
 
-结合 radix 树和 listpacks 的特性，它可以很容易地去构建一个空间高效的日志，并且还是索引化的，这意味着允许通过 ID 和时间进行随机访问。自从这些准备就绪后，我开始去写一些代码以实现流数据结构。我最终完成了该实现，不管怎样，现在，Redis 在 Github 上的 “streams” 分支里面，它已经可以跑的很好了。我并没有声称那个 API 是 100% 的最终版本，但是，这有两个有趣的事实：一是，在那时，只有消费组是不行的，再加上一些不那么重要的命令去操作流，但是，所有的大的方面都已经实现了。二是，一旦各个方面比较稳定了之后 ，决定大概用两个月的时间将所有的流的工作<ruby>回迁<rt>backport</rt></ruby>到 4.0 分支。这意味着 Redis 用户为了使用 streams，不用等到 Redis 4.2 发布，它们在生产环境中马上就可以使用了。这是可能的，因为作为一个新的数据结构，几乎所有的代码改变都出现在新的代码里面。除了阻塞列表操作之外：该代码被重构了，我们对于 streams 和列表阻塞操作共享了相同的代码，从而极大地简化了 Redis 内部。
+结合 radix 树和 listpacks 的特性，它可以很容易地去构建一个空间高效的日志，并且还是索引化的，这意味着允许通过 ID 和时间进行随机访问。自从这些准备就绪后，我开始去写一些代码以实现流数据结构。我最终完成了该实现，不管怎样，现在，Redis 在 Github 上的 “streams” 分支里面，它已经可以跑的很好了。我并没有声称那个 API 是 100% 的最终版本，但是，这有两个有趣的事实：一是，在那时，只有消费组是不行的，再加上一些不那么重要的命令去操作流，但是，所有的大的方面都已经实现了。二是，一旦各个方面比较稳定了之后，决定大概用两个月的时间将所有的流的工作<ruby>回迁<rt>backport</rt></ruby>到 4.0 分支。这意味着 Redis 用户为了使用 streams，不用等到 Redis 4.2 发布，它们在生产环境中马上就可以使用了。这是可能的，因为作为一个新的数据结构，几乎所有的代码改变都出现在新的代码里面。除了阻塞列表操作之外：该代码被重构了，我们对于 streams 和列表阻塞操作共享了相同的代码，从而极大地简化了 Redis 内部。
 
 ### 教程：欢迎使用 Redis 的 streams
 
@@ -57,7 +57,7 @@ QUEUED
 2) 1506872463535.1
 ```
 
-在上面的示例中，也展示了无需指定任何初始<ruby>模式<rt>schema</rt></ruby>的情况下，对不同的条目使用不同的字段。会发生什么呢？就像前面提到的一样，只有每个块（它通常包含 50 - 150 个消息内容）的第一个信息被使用。并且，相同字段的连续条目都使用了一个标志进行了压缩，这个标志表示与“它们与这个块中的第一个条目的字段相同”。因此，对于使用了相同字段的连续消息可以节省许多内存，即使是字段集随着时间发生缓慢变化的情况下也很节省内存。
+在上面的示例中，也展示了无需指定任何初始<ruby>模式<rt>schema</rt></ruby>的情况下，对不同的条目使用不同的字段。会发生什么呢？就像前面提到的一样，只有每个块（它通常包含 50-150 个消息内容）的第一个信息被使用。并且，相同字段的连续条目都使用了一个标志进行了压缩，这个标志表示与“它们与这个块中的第一个条目的字段相同”。因此，对于使用了相同字段的连续消息可以节省许多内存，即使是字段集随着时间发生缓慢变化的情况下也很节省内存。
 
 为了从流中检索数据，这里有两种方法：范围查询，它是通过 `XRANGE` 命令实现的；和<ruby>流播<rt>streaming</rt></ruby>，它是通过 XREAD 命令实现的。`XRANGE` 命令仅取得包括从开始到停止范围内的全部条目。因此，举例来说，如果我知道它的 ID，我可以使用如下的命名取得单个条目：
 
@@ -151,23 +151,23 @@ QUEUED
 
 ### 消费组（开发中）
 
-这是第一个 Redis 中尚未实现而在开发中的特性。它也是来自 Kafka 的灵感，尽管在这里以不同的方式去实现的。重点是使用了 `XREAD`，客户端也可以增加一个 `GROUP <name>` 选项。 在相同组的所有客户端，将自动地得到*不同的*消息。当然，同一个流可以被多个组读取。在这种情况下，所有的组将收到流中到达的消息的相同副本。但是，在每个组内，消息是不会重复的。
+这是第一个 Redis 中尚未实现而在开发中的特性。它也是来自 Kafka 的灵感，尽管在这里以不同的方式去实现的。重点是使用了 `XREAD`，客户端也可以增加一个 `GROUP <name>` 选项。在相同组的所有客户端，将自动地得到*不同的*消息。当然，同一个流可以被多个组读取。在这种情况下，所有的组将收到流中到达的消息的相同副本。但是，在每个组内，消息是不会重复的。
 
 当指定组时，能够指定一个 “RETRY <milliseconds>” 选项去扩展组：在这种情况下，如果消息没有使用 XACK 去进行确认，它将在指定的毫秒数后进行再次投递。这将为消息投递提供更佳的可靠性，这种情况下，客户端没有私有的方法将消息标记为已处理。这一部分也正在开发中。
 
 ### 内存使用和加载时间节省
 
-因为设计用来建模 Redis 的 streams，内存使用是非常低的。这取决于它们的字段、值的数量和它们的长度，对于简单的消息，每使用 100 MB 内存可以有几百万条消息，此外，格式设想为需要极少的序列化：listpack 块以 radix 树节点方式存储，在磁盘上和内存中都以相同方式表示的，因此，它们可以很轻松地存储和读取。例如，Redis 可以在 0.3 秒内从 RDB 文件中读取 500 万个条目。这使得 streams 的复制和持久存储非常高效。
+因为设计用来建模 Redis 的 streams，内存使用是非常低的。这取决于它们的字段、值的数量和它们的长度，对于简单的消息，每使用 100MB 内存可以有几百万条消息，此外，格式设想为需要极少的序列化：listpack 块以 radix 树节点方式存储，在磁盘上和内存中都以相同方式表示的，因此，它们可以很轻松地存储和读取。例如，Redis 可以在 0.3 秒内从 RDB 文件中读取 500 万个条目。这使得 streams 的复制和持久存储非常高效。
 
 也计划允许从条目中间进行部分删除。现在仅实现了一部分，策略是在条目在标记中标识为已删除条目，并且，当已删除条目占全部条目的比率达到给定值时，这个块将被回收重写，并且，如果需要，它将被连到相邻的另一个块上，以避免碎片化。
 
 ### 关于最终发布时间的结论
 
-Redis 的 streams 将包含在年底前（LCTT 译注：本文原文发布于 2017 年 10 月）推出的 Redis 4.0 系列的稳定版中。我认为这个通用的数据结构将为 Redis 提供一个巨大的补丁，以用于解决很多现在很难去解决的情况：那意味着你（之前）需要创造性地滥用当前提供的数据结构去解决那些问题。一个非常重要的使用案例是时间序列，但是，我的感觉是，对于其它用例来说，通过 `TREAD` 来流播消息将是非常有趣的，因为对于那些需要更高可靠性的应用程序，可以使用发布/订阅模式来替换“即用即弃”，还有其它全新的使用案例。现在，如果你想在你的有问题环境中评估新数据结构的能力，可以在 GitHub 上去获得 “streams” 分支，开始去玩吧。欢迎向我们报告所有的 bug 。 :-)
+Redis 的 streams 将包含在年底前（LCTT 译注：本文原文发布于 2017 年 10 月）推出的 Redis 4.0 系列的稳定版中。我认为这个通用的数据结构将为 Redis 提供一个巨大的补丁，以用于解决很多现在很难去解决的情况：那意味着你（之前）需要创造性地滥用当前提供的数据结构去解决那些问题。一个非常重要的使用案例是时间序列，但是，我的感觉是，对于其它用例来说，通过 `TREAD` 来流播消息将是非常有趣的，因为对于那些需要更高可靠性的应用程序，可以使用发布/订阅模式来替换“即用即弃”，还有其它全新的使用案例。现在，如果你想在你的有问题环境中评估新数据结构的能力，可以在 GitHub 上去获得 “streams” 分支，开始去玩吧。欢迎向我们报告所有的 bug。:-)
 
-如果你喜欢这个视频，展示这个 streams 的实时会话在这里： https://www.youtube.com/watch?v=ELDzy9lCFHQ
+如果你喜欢这个视频，展示这个 streams 的实时会话在这里：https://www.youtube.com/watch?v=ELDzy9lCFHQ
 
---------------------------------------------------------------------------------
+---
 
 via: http://antirez.com/news/114
 
@@ -177,7 +177,7 @@ via: http://antirez.com/news/114
 
 本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
 
-[a]:http://antirez.com/
-[1]:http://antirez.com/news/114
-[2]:http://antirez.com/user/antirez
-[3]:https://www.youtube.com/watch?v=ELDzy9lCFHQ
+[a]: http://antirez.com/
+[1]: http://antirez.com/news/114
+[2]: http://antirez.com/user/antirez
+[3]: https://www.youtube.com/watch?v=ELDzy9lCFHQ