{ "version": "https://jsonfeed.org/version/1", "title": "Hulk Dev Blog Blog", "home_page_url": "https://hulkdev.com/", "description": "Hulk Dev Blog Blog", "items": [ { "id": "posts-writing-by-notes", "content_html": "

乍看书名以为是关于如何做笔记的工具书，后面发现重点是讲写作思维方式，整体内容上比看之前的预期好很多。卡片盒写作法是卢曼杰出学术成就的生产力来源，他在长达 30 多年的研究中出版了 58 本著作以及数百篇文章。书中主要是论述如何通过卡片笔记的方法进行写作，也顺便解答了我的几个问题:

这本书对于我自己最大的帮助在于阅读思维的变化， 也促使我写下了第一篇读书笔记。当然，能否真正带来写作上的改变，需要留给时间来回答。我十分喜欢里面关于读书的观点: 「读书不是为了积累知识而是形成自己的思维框架，并使用新观点和事实对过往的经验提出质疑」。我们不是复读机，不必为了可以背出某个名人的语句而读书，而应该是纯粹为了形成自己的思考方式。具备自己的思考和辨别能力，而不是受某种权威或者舆论的引导。以下是个人认为值得分享的几个观点。

写作很重要​

书中引用卢曼的: 「不写，就无法思考」 来说明写作的重要性。很多人都意识到了写作表达的重要性，但能够坚持践行的人并不多。主要是过往教授的写作方式包含很多写作指南书籍都是至上而下，习惯于围绕着某个主题展开论述，缺少了最关键的论据收集以及积累的过程。以至于需要从容量有限的大脑里搜索和提取观点，将写作变成痛苦的脑暴过程。而卢曼的卡片笔记写作法核心则是相反，提出写作不应该是空白纸开始，而是通过大量阅读以及积累观点这种自下而上的过程。遇到有价值的观点，用自己的语言写下来思考，写作时只需将这些过往的观点聚合到一起。反过来，要想要讨论某个话题，重要的是收集相关材料进行阅读和思考，而不是写作的过程或者工具。另外，书中举了很多次费曼的例子来强调关联的重要性，零散的知识点很难记住，而关联之后更加容易。也可以同时复盘之前哪些观点是一致或者相悖，写作就是关联的过程，可以通过写作不断更新自己的理解和思考。

确认偏差​

在保持开放心态的章节里面提到了 确认偏差 这个概念，大体的意思是人潜意识会被熟悉或感觉良好的事物所吸引，剔除那些有违我们认知的事物。确认偏差会让我们无意识自动进入搜集周围有利于结论的数据，从而干扰学习和思考。写作也是一样，在寻找论据时需要克服确认偏差的干扰，避免无意识只收集对论点有利的证据。 对于写作来说，克服的方式可以将寻找证实性的事实变成收集所有相关信息，而不管它支持什么论点。书中也引用了 Charles Darwin 如何处理确认偏差的方式: 遇到与自己结论相反的事实或者观点时立即把它们记下来，因为这些事实和观点更加容易被忽略。

在 「亚马逊反向工作法」 书中的招聘章节也提到这个概念，由于确认偏差导致招聘者倾向于关注他人确认的正面信息，而忽略负面和矛盾的信息，最终导致 \"群体思维\"。举的例子就是面试官之间交流一旦给予正面反馈，会导致后续面试过程中无意识尝试寻找候选人这些优点，从而忽略了候选人存在的缺陷。很多公司的招聘流程上都存在类似的问题，只是可能没有意识到而已，一旦意识到之后改变就变得很容易。

总结​

写作最重要都是个人的理解和思考，不管多好的工具都是为了更系统化的思考。受限于人脑的存储容量，需要通过笔记的方式将记忆 offloading 到外部存储以减少知识遗忘。卡片笔记写作法本身并没有魔法，如果有，应当所有看过这本书的人都能够变成长期的写作者，它最重要的作用是改变了写作思维，让我们意识到写作不应该从零开始而是日常的理解和思考。另外，对于专题写作(比如论文)也是一样，写作过程不是重点，而是围绕专题阅读资料过程中个人的理解和思考。当然，最为重要的还是实践，只有真正到水里才能学会游泳。

欢迎扫码关注 hulk 个人微信公众号，一起学习和交流:

\"img\"

", "url": "https://hulkdev.com/posts-writing-by-notes", "title": "卡片笔记写作法 - 读书笔记", "summary": "乍看书名以为是关于如何做笔记的工具书，后面发现重点是讲写作思维方式，整体内容上比看之前的预期好很多。卡片盒写作法是卢曼杰出学术成就的生产力来源，他在长达 30 多年的研究中出版了 58 本著作以及数百篇文章。书中主要是论述如何通过卡片笔记的方法进行写作，也顺便解答了我的几个问题:", "date_modified": "2022-09-12T00:00:00.000Z", "author": { "name": "hulk" }, "tags": [ "读书" ] }, { "id": "monitoring-go-apps-with-distributed-tracing-and-opentelemetry", "content_html": "

This article gives a brief introduction into monitoring Go applications using OpenTelemetry and Uptrace.

What is OpenTelemetry?​

OpenTelemetry is an open source and vendor-neutral API for distributed tracing (including logs and errors) and OpenTelemetry metrics.

It specifies how to collect and export telemetry data in a vendor agnostic way. With OpenTelemetry, you can instrument your application once and then add or change vendors without changing the instrumentation, for example, many open source tracing tools already support OpenTelemetry.

By being vendor-neutral, OpenTelemetry makes it possible to try different products with minimal efforts and avoid being stuck with a vendor forever.

OpenTelemetry also enables different companies to work together on maintaining a single framework instead of duplicating efforts in proprietary projects which benefits everyone. It also means that OpenTelemetry works almost everywhere and you can trace requests across different languages, platforms, and even clouds.

How to use OpenTelemetry?​

The easiest way to get started with OpenTelemetry is to pick an OpenTelemetry backend (vendor) and follow the documentation. Most vendors provide pre-configured OpenTelemetry distros that allow you to skip some steps and can significantly improve your experience.

If you are looking for an open source solution, Jaeger is historically the default choice, but Uptrace provides more features and might be a better choice nowadays.

Uptrace is an open source APM for OpenTelemetry that uses ClickHouse database to store traces, metrics, and logs. You can use it to monitor applications and set up automatic alerts to receive notifications via email, Slack, Telegram, and more.

What is tracing?​

Distributed tracing allows to observe requests as they propagate through distributed systems, especially those built using a microservices architecture.

Tracing provides insights into your app performance along with any errors and logs. You immediately see what conditions cause errors and how particular error affects app performance.

\"image\"

Using tracing, you can break down requests into spans. Span is an operation (unit of work) your app performs handling a request, for example, a database query or a network call.

Trace is a tree of spans that shows the path that a request makes through an app. Root span is the first span in a trace.

\"image\"

To learn more about tracing, see Distributed tracing using OpenTelemetry.

OpenTelemetry API​

OpenTelemetry API is a programming interface that you can use to instrument code to collect telemetry data such as traces, metrics, and logs.

You can create spans using OpenTelemetry API for Go like this:

import \"go.opentelemetry.io/otel\"

var tracer = otel.Tracer(\"app_or_package_name\")

func someFunc(ctx context.Context) error {
    ctx, span := tracer.Start(ctx, \"some-func\")
    defer span.End()

    // the code you are measuring

    return nil
}

You can also record attributes and errors:

func someFunc(ctx context.Context) error {
    ctx, span := tracer.Start(ctx, \"some-func\")
    defer span.End()

    if span.IsRecording() {
        span.SetAttributes(
            attribute.Int64(\"enduser.id\", userID),
            attribute.String(\"enduser.email\", userEmail),
        )
    }

    if err := someOtherFunc(ctx); err != nil {
        span.RecordError(err)
        span.SetStatus(codes.Error, err.Error())
    }

    return nil
}

See OpenTelemetry Go API for details.

What is Uptrace?​

Uptrace is an open source APM with an intuitive query builder, rich dashboards, automatic alerts, and integrations for most languages and frameworks.

Uptrace accepts data from OpenTelemetry and stores it in a ClickHouse database. ClickHouse is a columnar database that is much more efficient for traces and logs than, for example, Elastic Search. On the same hardware, ClickHouse can store 10x more traces and, at the same time, provide much better performance.

You can install Uptrace by downloading a DEB/RPM package or a pre-compiled binary.

\"image\"

Metrics monitoring​

Uptrace also allows you to monitor metrics using Prometheus-like alerting rules. For example, the following monitor uses the group by node expression to create an alert whenever an individual Redis shard is down:

monitors:
  - name: Redis shard is down
    metrics:
      - redis_up as $redis_up
    query:
      - group by cluster # monitor each cluster,
      - group by bdb # each database,
      - group by node # and each shard
      - $redis_up
    min_allowed_value: 1
    # shard should be down for 5 minutes to trigger an alert
    for_duration: 5m

You can also create queries with more complex expressions. For example, the following rules create an alert when the keyspace hit rate is lower than 75% or memory fragmentation is too high:

monitors:
  - name: Redis read hit rate < 75%
    metrics:
      - redis_keyspace_read_hits as $hits
      - redis_keyspace_read_misses as $misses
    query:
      - group by cluster
      - group by bdb
      - group by node
      - $hits / ($hits + $misses) as hit_rate
    min_allowed_value: 0.75
    for_duration: 5m

See Alerting and Notifications for details.

What's next?​

Next, you can continue exploring OpenTelemetry or start instrumenting your app using popular instrumentations:

", "url": "https://hulkdev.com/monitoring-go-apps-with-distributed-tracing-and-opentelemetry", "title": "Monitoring Go apps with Distributed Tracing and OpenTelemetry", "summary": "This article gives a brief introduction into monitoring Go applications using OpenTelemetry and Uptrace.", "date_modified": "2022-04-18T00:00:00.000Z", "author": { "name": "Vladimir Mihailenco" }, "tags": [ "Uptrace", "OpenTelemetry" ] }, { "id": "posts-how-to-impl-bitmap-on-disk-kv", "content_html": "

大部分开发对 Bitmap 应该都不陌生，除了作为 Bloom Filter 实现的存储之外，许多数据库也有提供 Bitmap 类型的索引。对于内存型的存储来说，Bitmap 只是一个特殊类型(bit)的稀疏数组，操作内存不会带来读写放大问题(指的是物理读写的数据量远大于逻辑的数据量), Redis 就是在字符串类型上支持 bit 的相关操作，而对于 Kvrocks 这种基于磁盘 KV 实现的存储则会是比较大挑战，本篇文章主要讨论的其实是「基于磁盘 KV 实现 Bitmap 要如何减少磁盘读写放大」

为什么会产生读写放大​

读写放大的主要是来源于两方面:

硬件层面一般是由于最小读写单元带来的读写放大，以 SSD 为例，读写的最小单位是页(一般是 4KiB/8KiB/16KiB)。即使应用层只写入一个字节，在磁盘上实际会写入一个页，这也就是我们所说的写放大，反之读也是一样。另外，SSD 修改数据不是在页内位置原地修改而是 Read-Modify-Write 的方式，修改时需要将原来的数据读出来，修改之后再写到新页，老的磁盘页由 GC 进行回收。所以，即使对同一页的一小块数据反复修改也会由于硬件本身机制而造成写放大。类似于如下:

\"image\"

由此可见，大量随机小 io 读写对于 SSD 磁盘来说是很不友好的，除了在性能方面有比较大的影响之外，频繁擦写也会严重导致 SSD 的寿命(随机读写对 HDD 同样不友好，需要不断寻道和寻址)。LSM-Tree 就是通过将随机写入变成顺序批量写入来缓解这类问题。

软件层面的读写放大主要来自于数据组织方式，不同的存储组织方式所带来的读写放大程度也会有很大的差异。这里以 RocksDB 为例，RocksDB 是 Facebook 基于 Google LevelDB 之上实现了多线程，Backup 以及 Compaction 等诸多很实用的功能。RocksDB 的数据组织方式是 LSM-Tree，在解决磁盘写入方法问题，本身的数据存储也带来了一些空间放大问题。下面可以简单看一下 LSM-Tree 是如何组织数据:

\"image\"

LSM-Tree 每次写入都会产生一条记录，比如上图 x 先后写了 4 次，分别是 0，1，2，3。如果单看 x 这个变量，这里相当于有 4 倍的空间放大，这些重复的记录会在 compaction 的时候进行回收。同样，删除也是通过插入一条 value 为空的记录来实现。 LSM-Tree 每一层空间大小是逐层递增，当容量大小当层最大时会触发 compaction 合并到下一层，以此类推。假设 Level 0 最大存储大小是 M Bytes，逐层按照 10 倍增长且最大 7 层，理论上空间放大的大约是 1.111111 倍。计算公式如下:

空间放大率 = (1 + 10 + 100 +1000 + 10000 + 100000 + 1000000) * M / (1000000 * M)

但在实际场景中，由于最后一层一般无法达到最大值，所以放大空间率比这个理论值大不少，具体在 RocksDB 的文档里面也有提过，具体见: https://rocksdb.org/blog/2015/07/23/dynamic-level.html

另外，由于 RocksDB 读写都是以 KV 为单位，Value 越大带来的读写放大就可能越大。举个例子，假设有一个 Value 为 10 MiB 的 JSON，如果要修改这个 key 中的一个字段，那么需要把整个 JSON 读出来，修改后再重新写回去，就会导致巨大的读写放大。有一篇 paper「WiscKey: Separating Keys from Values in SSD-conscious Storage」就是通过 Key/Value 分离的方式来优化 LSM-Tree 大 KV 的来减少 Compaction 时带来写放大的问题。TiKV 里面的 titan 就是基于 Wiskey 论文优化 RocksDB 在大 KV 场景的写放大问题，RocksDB 也在社区版本里面实现这个功能，不过还是实验性的阶段。

基于磁盘 KV 实现 Bitmap​

Kvrocks 是基于 RocksDB 之上实现的兼容 Redis 协议的磁盘存储， 需要支持 Bitmap 功能，所以就需要在磁盘 KV 之上实现 Bitmap 的功能。而大部分使用 Bitmap 的场景都是作为稀疏数组来用，意味着第一次写入的 offset 为 1，下次的 offset 可能就是 1000000000 甚至更大，所以在实现 Bitmap 就会面临上述读写和空间放大问题。

一种最简单的实现方式是仍然把整个 Bitmap 作为一个 Value，读写时将 Value 读取到内存中再回写。这种实现虽然很简单，但一不小心可能导致 value 巨大，单个 Value 大小上 GiB 都是可能的。除了存在有效空间利用率问题之外，可能会直接导致整个服务不可用(需要读写整个 Value)。Pika 里面的 Bitmap 就是这种实现，但限制最大的 Value 为 128 KiB，限制 Value 大小虽然避免上述的极端情况，但会大大限制 Bitmap 的使用场景，甚至是无法使用。

既然知道核心问题是由于单个 KV 过大导致， 那么最直接的方式就是将 Bitmap 拆分成多个 KV，然后控制单个 KV 大小在合理范围之内， 那么读写带来的放大也是相对可控。在当前 Kvrocks 的实现里面是按照每个 KV 为 1 KiB 来划分，相当于每个 value 可以存放 8192 bits。算法示意图如下:

\"image\"

以 setbit foo 8192002 1 为例，实现的步骤如下:

  1. 计算 8192002 这个 offset 对应所在的 key, 因为 Kvrocks 是按照 1 KiB 一个 value，那么所在 key 的编号就是 8192002/(1024*8) = 1000，所以就可以知道这个 offset 应该写到 \"foo\" + 1000 这个 key 对应的 value 里面
  2. 接着从 RocksDB 里面去获取这个 key 对应的 value
  3. 计算这个 offset 在分段里面的偏移，8192002%8291 等于 2，然后把 value 中偏移为 2 的 bit 位设置为 1
  4. 最后将 value 回写到 RocksDB

这种实现比较关键的一个特点是 Bitmap 对应的 KV 只在有写入的时候才会真正写到 RocksDB 里面。假设我们只执行过两次 setbit ，分别是 setbit foo 1 1 和 setbit foo 8192002 1 ，那么 RocksDB 里面只会有 foo:0 和 foo:1000 这两个 key，实际的写入 KV 总共也只有 2 KiB。刚好也可以完美适应 Bitmap 这种稀疏数组的场景，不会因为稀疏写入而带来空间放大的问题。

这个想法也和 Linux 的虚拟内存/物理内存映射策略类似，比如我们 malloc 申请了 1GiB 的内存，操作系统也只是分配一片虚拟内存地址空间，只有在真正写入的时候才会触发缺页中断去分配物理内存(目前正常内存页大小是 4KiB)。也就是如果内存页没有被写过，只读也不会产生物理内存分配。

GetBit 也是类似，先计算 offset 所在的 key，然后从 RocksDB 读取这个 key, 如果不存在则说明这段没有被写过，直接返回 0。如果存在则读取 Value，返回对应 bit 的值。另外，在实现上也单个 KV 实际存储大小也是由目前写入最大的 offset 决定，并不是有写入就会分配 1024 KiB，这样也可以一定程度优化单个 KV 内的读写放大问题。实现可参考: https://github.com/KvrocksLabs/kvrocks/blob/unstable/src/redis_bitmap.cc

总结​

可以看到基于内存和磁盘之上去实现同一个功能，除了不同类型存储介质本身的速度差异之外，问题和挑战是完全不一样的。对于磁盘类型的服务，需要不断去优化随机读写和空间放大问题，除了对于软件本身熟悉之外，同样需要了解硬件设备。

另外，Kvrocks 作为基于磁盘 KV 之上兼容 Redis 协议存储服务，最经常被问到是跟其他功能类似的服务有什么区别？简单来说，最大的差异在于不同项目维护者在功能设计上的差异，不同设计会让功能看似一样的服务在表现上完全不一样。所以，最好的方式就是通过代码去了解项目的设计和问题。

欢迎大家扫码关注 「Kvrocks 官方社区」公众号并回复: 进群，来加入我们的微信群！

\"image\"

References​

[1][https://rocksdb.org/blog/2015/07/23/dynamic-level.html](https://rocksdb.org/blog/2015/07/23/dynamic-level.html)

[2][https://www.usenix.org/system/files/conference/fast16/fast16-papers-lu.pdf](https://www.usenix.org/system/files/conference/fast16/fast16-papers-lu.pdf)

[3][https://github.com/KvrocksLabs/kvrocks](https://github.com/KvrocksLabs/kvrocks)

[4][https://github.com/facebook/rocksdb](https://github.com/facebook/rocksdb)

[5][https://github.com/tikv/titan](https://github.com/tikv/titan)

", "url": "https://hulkdev.com/posts-how-to-impl-bitmap-on-disk-kv", "title": "如何基于磁盘 KV 实现 Bitmap", "summary": "大部分开发对 Bitmap 应该都不陌生，除了作为 Bloom Filter 实现的存储之外，许多数据库也有提供 Bitmap 类型的索引。对于内存型的存储来说，Bitmap 只是一个特殊类型(bit)的稀疏数组，操作内存不会带来读写放大问题(指的是物理读写的数据量远大于逻辑的数据量), Redis 就是在字符串类型上支持 bit 的相关操作，而对于 Kvrocks 这种基于磁盘 KV 实现的存储则会是比较大挑战，本篇文章主要讨论的其实是「基于磁盘 KV 实现 Bitmap 要如何减少磁盘读写放大」", "date_modified": "2021-07-27T00:00:00.000Z", "author": { "name": "hulk" }, "tags": [ "Redis", "Bitmap", "Storage" ] }, { "id": "intro-opensource-kvrocks", "content_html": "

Kvrocks 是基于 RocksDB 之上兼容 Redis 协议的 NoSQL 存储服务，设计目标是提供一个低成本以及大容量的 Redis 服务，作为 Redis 在大数据量场景的互补服务，选择兼容 Redis 协议是因为简单易用且业务迁移成本低。目前线上使用的公司包含: 美图、携程、百度以及白山云等，在线上经过两年多大规模实例的验证。

项目核心功能包含:

GitHub地址：https://github.com/bitleak/kvrocks

实现方案对比​

除了 Kvrocks 之外，社区也有一些类似的基于磁盘存储兼容 Redis 协议的开源产品，从存储设计来看可以分为几类:

  1. 基于磁盘 KV 存储引擎(比如 RocksDB/LevelDB) 实现 Redis 协议
  2. 基于 Redis 存储之上将冷数据交换到磁盘(类似早期 Redis VM 的方案)
  3. 基于分布式 KV(比如 TiKV) 实现 Redis 协议代理，本地不做存储

\"image\"

方案 1: 是基于磁盘 KV 之上兼容 Redis 协议，绝大多数的本地磁盘 KV 只提供最简单的 Get/Set/Delete 方法，对于 Hash/Set/ZSet/List/Bitmap 等数据结构需要基于磁盘 KV 之上去实现。优点是可以规避下面方案 2 里提到的大 Key 问题，缺点是实现工作量大一些。

方案 2: 基于 Redis 把冷数据交换磁盘是以 Key 作为最小单元，在大 Key 的场景下会有比较大的挑战。交换大 Key 到磁盘会有严重读写放大，如果是读可能会导致整个服务不可用，所以这种实现只能限制 Value 大小，优点在于实现简单且可按照 Key 维度来做冷热数据分离。

方案 3: 是基于分布式 KV 之上实现 Redis 协议，最大的区别在于所以的操作都是通过网络。这种实现方式最大优点是只需要实现 Redis 协议的部分，服务本身是无状态的，无须考虑数据复制以及扩展性的问题。缺点也比较明显，因为所有的命令都是通过网络 IO，对于非 String 类型的读写一般都是需要多次网络 IO 且需要通过事务来保证原子，从而在延时和性能上都会比方案 1 和 2 差不少。

Kvrocks 设计的初衷是作为 Redis 场景的互补，低成本、低延时和高吞吐是最重要的设计目标。基于 Redis 实现冷热数据交换的方式在大 Key 场景下可能导致不可用，从而需要限制单个 Key 大小，这个对于我们想实现一个通用的 NoSQL 存储服务是无法接受的。而对于方案 3 这种远程存储的方案，延时和吞吐一定是无法满足预期，所以我们最终选择的方案 1 这种基于磁盘 KV 之上实现 Redis 协议以及复制。除了数据存储方式之外， Kvrocks 并没有淘汰策略，所以一般是作为存储服务而不是缓存，当写入的数据量达到实例最大容量或者磁盘容量不足时会写入失败。

性能​

需要注意的是以下提供的性能数据是基于特定的配置进行压测，不同配置会有比较大的差异。压测的硬件以及 Kvrocks 配置说明可参考: https://github.com/bitleak/kvrocks#performance

\"image\"

这里提供性能数据只是为了给读者更加直观了解 Kvrocks 的性能情况，大部分命令由于可多线程并行执行，从 QPS 的维度来看会比 Redis 更好一些，但延时肯定会比 Redis 略差。

功能​

Kvrocks 支持 Redis String、 List、 Hash、Set、 ZSet 五种基本数据类型， 以及 Bitmap、Geo 和自定义的 Sorted Int 类型。当前支持大多数命令，也支持 Pub/Sub、事务以及备份等功能。

具体可参考：https://github.com/bitleak/kvrocks/blob/unstable/docs/support-commands.md

快速体验​

可以使用 Docker 的方式来启动 Kvrocks:

docker run -it -p 6666:6666 bitleak/kvrocks

接着可以跟使用 Redis 一样使用:

➜  ~ redis-cli -p 6666

127.0.0.1:6666> set foo bar
OK
127.0.0.1:6666> get foo
\"bar\"

整体设计​

\"image\"

Kvrocks 主要有两类线程:

下面以 Hash 为例来说明 Kvrocks 是如何将复杂的数据结构转为 RocksDB 对应的 KV?

最简单的方式是将 Hash 所有的字段进行序列化之后写到同一个 Key 里面，每次修改都需要将整个 Value 读出来之后修改再写入，当 Value 比较大时会导致严重的读写方法问题。所以我们参考 blackwidow 的实现，把 Hash 拆分成 Metadata 和 Subkey 两个部分，Hash 里面的每个字段都是独立的 KV，再使用 Metadata 来找到这些 Subkey:

        +----------+------------+-----------+-----------+
key =>  |  flags   |  expire    |  version  |  size     |
        | (1byte)  | (4byte)    |  (8byte)  | (8byte)   |
        +----------+------------+-----------+-----------+
                            (hash metadata)

                     +---------------+
key|version|field => |     value     |
                     +---------------+
              (hash subkey)

里面的 flags 目前是来标识当前 Value 的类型，比如是 Hash/Set/List 等。expire 是 Key 的过期时间，size 是这个 Key 包含的字段数量，这两个比较好理解。version 是在 Key 创建时自动生成的单调递增的 id，每个 Subkey 前缀会关联上 version。当 Metadata 本删除时，这个 version 就无法被找到，也意味着关联这个 version 的全部 Subkey 也无法找到，从而实现快速删除，而这些无法找到的 Subkey 会在后台 Compact 的时候进行回收。

以 HSET 命令为例，伪代码如下:

HSET key, field, value:
  // 先根据 hash key 找到对应的 metadata 并判断是否过期
  // 如果不存在或者过期则创建一个新的 metadata
  metadata = rocksdb.Get(key)
  if metadata == nil || metadata.Expired() {
     metadata = createNewMetadata();
  }
  // 根据 metadata 里面的版本组成 subkey
  subkey = key + metadata.version+field
    if rocksdb.Get(subkey) == nil {
     metadata.size += 1
  }
  // 写入 subkey 以及更新 metadata
    rocksdb.Set(subkey, value)
  rocksdb.Set(key, metadata)

更多的数据结构设计可以参考: https://github.com/bitleak/kvrocks/blob/unstable/docs/metadata-design.md

Kvrocks 是如何进行数据复制?

Kvocks 的定位是作为大数据量场景下 Redis 的替代方案，提供与 Redis 一样的数据最终一致性保证，采用了类似 Redis 的主从异步复制模型。考虑到需要应对更多的业务场景，后续会支持半同步复制模型。在实现上，全量复制利用 RocksDB 的 CheckPoint 特性，增量复制采用直接发送 WAL 的方式，从库接收到WAL直接操作后端引擎，相比于 Binlog 复制方式（回放从客户端接收到的命令），省去了命令解析和处理的开销，复制速度大幅提升，这样也就解决了其它采用 Binlog 复制方式的存储服务所存在的复制延迟问题。

Kvrocks 是如何实现分布式集群？

业界常用Redis集群方案主要有两类：类似 Codis 中心化的集群架构和社区 Redis Cluster 去中心化的集群架构。Kvrocks 集群方案选择了类似 Codis 中心化的架构，集群元数据存储在配置中心，但不依赖代理层，配置中心为存储节点推送元数据，对外提供 Redis Cluster 集群协议支持，对于使用 Redis Cluster SDK 或者 Proxy 的用户不需要做任何修改。同时也可以避免类似Redis Cluster 受限于 Gossip 通信的开销而导致集群规模不能太大的问题。另外，单机版的 Kvrocks 和 Redis 一样可以直接支持 Twmeproxy，通过Sentinel实现高可用，对于 Codis 通过简单的适配也能够比较快的支持。目前集群方案处在测试阶段，预计7月份发布，待正式发布后会给大家详细介绍，这里不过多展开。

对于分布式集群来说，弹性伸缩的能力是必不可少的，Kvrocks 是如何实现弹性伸缩的？

整个扩缩容拆分为迁移全量数据、迁移增量数据、变更拓扑三个阶段。迁移全量数据利用 RocksDB的 Snapshot 特性，生成 Snapshot 迭代数据发送到目标节点。同时，为了加快迭代效率数据编码上Key 增加 SlotID 前缀。迁移增量数据阶段直接发送 WAL。当待迁移的增量 WAL 小于设定的阈值则开始阻写，等发送完剩余的 WAL 切换拓扑之后解除阻写，这个过程通常是毫秒级的。

优化点​

相比内存型服务来说，最常见的问题是磁盘的吞吐和延时带来的毛刺点问题。除了通过慢日志命令来确认是否有慢请求产生之外，还提供了 perflog 命令用来定位 RocksDB 访问慢的问题，使用方式如下:

# 第一条命令设定只对 SET 命令收集 profiling 日志
# 第二条命令设定随机采样的比例
# 第三条命令设定超过多长时间的命令才写到 perf 日志里面(如果是为了验证功能可以设置为 0)
127.0.0.1:6666> config set profiling-sample-commands set
OK
127.0.0.1:6666> config set profiling-sample-ratio 100
OK
127.0.0.1:6666> config set profiling-sample-record-threshold-ms 1
OK

# 执行 Set 命令，在去看 perflog 命令就可以看到对应的耗时点
127.0.0.1:6666> set a 1
OK
127.0.0.1:6666> perflog get 2
1) 1) (integer) 1
   2) (integer) 1623123739
   3) \"set\"
   4) (integer) 411
   5) \"user_key_comparison_count = 7, write_wal_time = 122300, write_pre_and_post_process_time = 91867, write_memtable_time = 47349, write_scheduling_flushes_compactions_time = 13028\"
   6) \"thread_pool_id = 4, bytes_written = 45, write_nanos = 46030, prepare_write_nanos = 21605\"

之前通过这种方式发现了一些 RocksDB 参数配置不合理的问题，比如之前 SST 文件大小默认是 256MiB，当业务的 KV 比较小的时候可能会导致一个 SST 文件里面可能有百万级别的 KV，从而导致 index 数据块过大(几十 MiB)，每次从磁盘读取数据需要耗费几十 ms。但线上不同业务的 KV 大小可能会差异比较大，通过 DBA 手动调整的方式肯定不合理，所以有了根据写入 KV 大小在线自动调整 SST 和 Block Size 的功能，具体描述见: https://github.com/bitleak/kvrocks/issues/118

另外一个就是 RocksDB 的全量 Compact 导致磁盘 IO 从而造成业务访问的毛刺点问题，之前策略是每天凌晨低峰时段进行一次，过于频繁会导致访问毛刺点，频率过低会导致磁盘空间回收不及时。所以增加另外一种部分 Compact 策略，优先对那些比较老以及无效 KV 比较多的 SST进行 Compact。开启只需要在配置文件里面增加一行，那么则会在凌晨 0 到 7 点之间去检查这些 SST 文件并做 Compact

compaction-checker-range 0-7

总结​

在设计和实现上，Kvrocks 更注重简洁高效、稳定可靠、易于使用和问题定位。目前 Kvrocks 已经在线上大规模运行两年之久，基本功能已充分验证，大家可以放心使用。如遇到问题，大家可以在微信群，Slack(见 GitHub README)，Issue 上反馈和交流，我们也欢迎提 PR 来一起完善 Kvrocks。

在社区维护上，希望可以有更加开放的交流氛围，而不只是把代码放到 GitHub 的开源。不管是功能设计还是代码开发，都会尽量把相关细节都在 GitHub 里面公开去讨论。

另外，2.0 版本预计在 7-8 月份会完成全部功能的开发，大家可以期待一下（具体进展见: https://github.com/bitleak/kvrocks/projects/

欢迎大家扫码关注 「Kvrocks 官方社区」公众号并回复: 进群，来加入我们的微信群！

\"image\"

", "url": "https://hulkdev.com/intro-opensource-kvrocks", "title": "Kvrocks 一款开源的企业级磁盘KV存储服务", "summary": "Kvrocks 是基于 RocksDB 之上兼容 Redis 协议的 NoSQL 存储服务，设计目标是提供一个低成本以及大容量的 Redis 服务，作为 Redis 在大数据量场景的互补服务，选择兼容 Redis 协议是因为简单易用且业务迁移成本低。目前线上使用的公司包含: 美图、携程、百度以及白山云等，在线上经过两年多大规模实例的验证。", "date_modified": "2021-06-16T00:00:00.000Z", "tags": [ "Redis", "SSD", "Storage" ] }, { "id": "posts-holes-in-php-memcached", "content_html": "

美图 PHP 业务团队在使用 php-memcached 扩展陆陆续续遇到一些隐蔽的 ”坑”，而这些坑在 php-memcached 也是比较容易踩到。其中有如 TCP_NODELAY 这类常见的坑，也有一些 php-memcached 本身设计带来的问题。这里分享出来希望可以给遇到类似问题或者正在坑里的同学带来一些帮助。

1. TCP_NODELAY 导致 40ms 延时​

先说问题，php-memcached 在开启二进制协议和未开启 TCP_NODELAY(默认关闭)时会导致 Get 命令在 cache miss 场景下的内网延时会到达 40ms 左右。这个是由于 TCP_NODELAY 和 TCP Delay ACK 的综合效果带来的，相信大家应该多多少少都有遇到类似的问题，下面会具体解释原因。

重现代码：

<?php

$memc = new Memcached();
$memc->addServer(\"127.0.0.1\", 11211);
$memc->setOption(Memcached::OPT_BINARY_PROTOCOL, true);

for ($i = 0; $i < 2; $i++) {
    $start = microtime();
    $memc->get(\"foo\"); // key `foo` wasn't exists
    var_dump(microtime()-$start);
}

代码逻辑开启了二进制协议并两次 Get 不存在的 key，输出如下:

float(0.00018799999999997)
float(0.039426)

第一次的请求的延时是 0.18 ms 而第二次则是 40ms，这里有两个问题:

  1. 为什么第二个请求需要 40ms？
  2. 第一次请求为什么没有问题？

我们从数据包的角度来分析第一个 40 ms 的问题:

\"image\"

可以看到 GET 命令在 php-memcached 里面的首先并不是直接发送 GET 命令， 而是由 GetKQ 和 NOOP 两个命令组成。GetKQ 和 GET 的区别是在 key 不存在时不会返回数据，所以客户端依赖的 noop 请求来确定 GetKQ 是否是 cache miss，这是因为 memcached 处理请求在连接内是串行的，如果 noop 请求返回了而 GetKQ 没有返回则说明是 key 不存在。

另外，上面的第一条和第二条数据包可以看到由于 TCP Delay ACK 机制导致了 GetKQ 请求数据包 ACK 被延时了 40ms，而刚好 TCP_NODELAY 默认不开启，触发了 negla 算法（因为未发送数据包未满 MSS 大小）从而导致 NOOP 命令延时到 ACK 回来，最终整个请求耗时到达 40 ms。

至于为什么要使用 GetKQ 和 NOOP 组合请求来替代 GET 请求？主要是因为这种方式在大量 Get Miss 的场景下可以节省很多没用的 Not Found 返回，这个在 Memcached Binary Wiki 里面有提到。 如果对于 TCP_NODELAY 和 TCP Delay ACK 不熟悉的同学可以参考:

接着可以回过头来看第二个问题，为什么第一个 Get 请求延时是正常的呢？这个需要从 TCP ack 逻辑来看：

// 代码文件: net/ipv4/tcp_input.c 

static void tcp_event_data_recv(struct sock *sk, struct sk_buff *skb) {
   ... // 省略逻辑不相关代码
   if (!icsk->icsk_ack.ato) {
        /* 
         * 第一次收到数据包则马上返回 ACK，并把 ato 设置为 TCP_ATO_MIN,
         * TCP_ATO_MIN 默认最小值是 40ms
         */
        tcp_incr_quickack(sk);
        icsk->icsk_ack.ato = TCP_ATO_MIN;
    } else {
            // 重新计算 ato
      ...
    }
}

TCP 协议栈在第一个数据包到来时不触发 delay ACK 机制的主要原因是因为，TCP 在刚建立完连接之后会进入 slow start 阶段，slow start 允许发送未 ACK 的窗口大小取决于之前的 ACK 数量，所以为了避免 slow start 阶段过慢，第一个数据包不触发 delay ack 逻辑。

问题修复也比较简单，如果开启二进制协议的时候，需要手动把 TCP_NODELAY 也开起来。

2. 不合理的默认重试策略​

在一次配合业务定位 php memcached 读写超时不符合预期发现了 SET 命令在超时的场景下会自动进行两次重试，后面通过代码发现 store_retry_count 默认值为 2， 也就是 SET/ SET Multi/ INCR/ DECR 这几个命令在失败的场景会自动重试 2 次，具体代码见: php_memcached.c 的 s_memc_write_zval 函数实现，这里不再贴代码。

对于一个通用的基础库来说，这种隐式的重试策略在类似 incr/decr 这类非幂等的操作可能会出现预期之外的不一致问题，应该留给用户显示去设置重试。这块已经提了 PR: #452 ，应该在下一个 release 版本会合并。

3. 错误的代码姿势导致长连接失效​

这个问题也是相当简单但隐蔽，php-memcached 的依赖库 libmemcached 在反复去设置一些 option（比如设置 OPT_BINARY_PROTOCOL），即使在 option 没有修改的场景下也会导致把老连接关闭重连。理论上，如果 option 没有的话是没有必要去关闭老连接，应该从 libmemcached 修复这个问题。不过，libmemcached 迭代比较慢，从兼容性的角度来说，在 php-memcached 里面修复也没什么问题，具体 PR: #451

总结​

作为基础库来说，出现第二点提到默认重试策略这个坑其实是不太应该的，基础库可以实现重试功能，但默认行为是什么应该考虑请求。TCP_NODELAY 这个属于常见问题(其实也是 libmemcached 实现的问题)，之前也有人反馈过，maintainer 自己也开过相关 PR 修复但最终不知道什么原因没有合并。第三点也是 libmemcached 的问题，不过也需要在 php-memcached 做一些简单的兼容性修复。虽然 php-memcached 有不少问题，但整体属于瑕不掩瑜。

", "url": "https://hulkdev.com/posts-holes-in-php-memcached", "title": "php-memcached 的一些坑", "summary": "美图 PHP 业务团队在使用 php-memcached 扩展陆陆续续遇到一些隐蔽的 ”坑”，而这些坑在 php-memcached 也是比较容易踩到。其中有如 TCP_NODELAY 这类常见的坑，也有一些 php-memcached 本身设计带来的问题。这里分享出来希望可以给遇到类似问题或者正在坑里的同学带来一些帮助。", "date_modified": "2020-03-17T00:00:00.000Z", "tags": [ "tcp", "linux", "php", "memcached" ] }, { "id": "posts-tcpkit-improvement", "content_html": "

tcpkit 是支持用 lua 脚本分析网络数据包的工具，附带简单协议解析(Redis/Memcached)和延时统计。最早开发 tcpkit 主要原因是经常需要通过网络包来分析资源慢请求问题，在数据包量比较大的场景下人肉分析会浪费比较时间，所以希望可以通过编码的方式来分析这类问题。从开发至今已经帮助我们团队以及美图 DBA 定位无数的线上问题，之前甚至通过 tcpkit 找到了 BCM 网卡驱动到 kernel 偶发产生几百毫秒延时问题。

Github 地址: https://github.com/git-hulk/tcpkit

第一个版本存在的主要问题是过于参数复杂导致使用很不友好，使用者明确告诉 tcpkit 当前是跑在客户端还是资源端，最近想到通过 syn 包自动分析的方式，周末花了两天时间重新实现了一版。这个版本另外一个改进点是 tcpkit 参数和 tcpdump 基本一致，可以减少上手的学习成本，同时也支持了分析多个端口的功能。

下面主要是 tcpkit 使用到几种场景:

case 1. 如何分析 Redis/Memcached 延时​

通过网络包来分析资源慢请求一般只会用在偶发且没有规律的场景，如果是大面积慢请求应该先通过资源监控来快速定位是否到达瓶颈。对于只有个别业务机器出现慢请求的场景则优先去查看业务端问题(比如对应时刻是否有长时间 GC，php/python 这类引用计数的就不用看了)。对于无规律偶发的场景，可以把 tcpkit 同时跑在客户端和业务端进行抓包分析，在客户端执行如下命令:

sudo tcpkit -i any tcp port 6379 -p redis

那么 tcpkit 会监听端口 6379 的数据包并使用 Redis 协议进行解析:

2020-03-08 19:23:06.258761 192.168.0.1:51137 => 192.168.0.2:6379 | 1.102 ms | set foo bared

意思是从客户端发出 SET 命令数据包到 Redis 返回响应总共耗时 1.102 ms， 这个延时包含了内网 RTT。

如果是在资源端(如 Redis) 也是执行上面的命令，会输出类似如下的数据包:

2020-03-08 19:23:06.258761 127.0.0.1:51137 => 127.0.0.1:6379 | 0.059 ms | set foo bared

意思是从收到 SET 命令数据包到处理完响应总共耗时 0.059 ms， 这个延时是不包含内网 RTT，所以推断内网的延时大概是 1ms 左右。

这个例子里面是正常的请求，对于慢请求通过对比客户端的延时和资源处理时间，大部分都可以推断慢请求到底是业务端、服务端还是中间链路问题。另外，在定位问题的时候一般只希望输出耗时比较长的请求，这个可以通过加上 -t 参数指定打印延时超过这个阀值的请求。

case 2. 作为延时统计监控工具​

除了之外实时分析工具之外，tcpkit 还可以作为常驻进程和资源部署在一起，作为资源延时监控的手段，输出资源的延时分布情(默认监听 33333 端口)，输出是 json 格式:

➜  ~ telnet 127.0.0.1 33333
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.

{
    \"127.0.0.1:6379\":   {
        \"requests\": 1700,
        \"request_bytes\":    184100,
        \"responses\":    1700,
        \"response_bytes\":   1413764,
        \"latency\":  [{
                \"<0.1ms\":   326
            }, {
                \"0.1ms~0.2ms\":  371
            }, {
                \"0.2~0.5ms\":    589
            }, {
                \"0.5ms~1ms\":    291
            }, {
                \"1ms~5ms\":  123
            }]
    }
}

case 3. 自定义分析脚本​

除此之外，对于一些个性化的分析需求可以通过定义 Lua 脚本来分析，-S 用来指定 lua 脚本文件的位置，tcpkit 在数据包产生时会回调脚本文件里面的 process 函数， 例子见: scripts/example.lua

function process(packet)
    if packet.size ~= 0 then -- skip the syn and ack
        local time_str = os.date('%Y-%m-%d %H:%M:%S', packet.tv_sec)..\".\"..packet.tv_usec
        print(string.format(\"%s %s:%d=>%s:%d %s %u %u %d %u %s\",
            time_str,
            packet.sip, -- source ip
            packet.sport, -- source port
            packet.dip, -- destination ip
            packet.dport, -- destination port
            type, -- request or response packet
            packet.seq, -- sequence number
            packet.ack, -- ack number
            packet.flags, -- flags, e.g. syn|ack|psh..
            packet.size, -- payload size
            packet.payload -- payload
        ))
    end
end

再比如我们想看看 TCP 建连耗时以及是否有 syn 包重传，几十行 Lua 脚本就搞定了，见示例代码: scripts/tcp-connect.lua

最后​

tcpkit 可以做的还有很多，比如默认支持更多协议如 gRPC, memcached 二进制协议，kafka 协议等等。因为作为 side project ，能分配的精力和时间有限会推进慢一些，欢迎大家多多使用和返回，更加欢迎 PR 或者建设性的意见。

Github 地址: https://github.com/git-hulk/tcpkit

", "url": "https://hulkdev.com/posts-tcpkit-improvement", "title": "tcpkit 一些改进", "summary": "tcpkit 是支持用 lua 脚本分析网络数据包的工具，附带简单协议解析(Redis/Memcached)和延时统计。最早开发 tcpkit 主要原因是经常需要通过网络包来分析资源慢请求问题，在数据包量比较大的场景下人肉分析会浪费比较时间，所以希望可以通过编码的方式来分析这类问题。从开发至今已经帮助我们团队以及美图 DBA 定位无数的线上问题，之前甚至通过 tcpkit 找到了 BCM 网卡驱动到 kernel 偶发产生几百毫秒延时问题。", "date_modified": "2020-03-09T00:00:00.000Z", "tags": [ "TCPKIT", "TCP" ] }, { "id": "posts-meitu-opensource-task-queue", "content_html": "

lmstfy(Let Me Schedule Task For You) 是美图架构基础服务团队在 2018 年初基于 Redis 实现的简单任务队列(Task Queue)服务，目前在美图多个线上产品使用接近两年的时间。主要提供以下特性:

Github 项目地址: https://github.com/meitu/lmstfy

使用场景​

任务队列跟消息队列在使用场景上最大的区别是： 任务之间是没有顺序约束而消息要求顺序(FIFO)，且可能会对任务的状态更新而消息一般只会消费不会更新。 类似 Kafka 利用消息 FIFO 和不需要更新(不需要对消息做索引)的特性来设计消息存储，将消息读写变成磁盘的顺序读写来实现比较好的性能。而任务队列需要能够任务状态进行更新则需要对每个消息进行索引，所以如果把两者放到一起实现则很难实在现功能和性能上兼得。

我们在以下几种场景会使用任务队列:

  1. 定时任务，如每天早上 8 点开始推送消息，定期删除过期数据等
  2. 任务流，如自动创建 Redis 流程由资源创建，资源配置，DNS 修改等部分组成，使用任务队列可以简化整体的设计和重试流程
  3. 重试任务，典型场景如离线图片处理

目标与调研​

在自研任务队列之前，我们基于以下几个要求作为约束调研了现有一些开源方案:

第一种方案是 Redis 作者开源的分布式内存队列 (disque)[https://github.com/antirez/disque]。disque 采用和 Redis Cluster 类似无中心设计，所有节点都可以写入并复制到其他节点。不管是从功能上、设计还是可靠性都是比较好的选择。我们在 2017 年也引入 disque 在部分业务使用过一段时间，后面遇到 bug 在内部修复后想反馈到社区，发现 Redis 作者决定不再维护这个项目(要把 disque 功能作为 redis module 来维护，应该是会伴随 Redis 6 发布)。最终我们也放弃了 disque 方案，将数据迁移到我们自研任务队列服务。

第二种方案是 2007 年就开源的 (beanstalkd)[https://github.com/beanstalkd/beanstalkd]，现在仍然还是在维护状态。beanstalkd 是类 memcached 协议全内存任务队列，断电或者重启时通过 WAL 文件来恢复数据。但 benstalkd 不支持复制功能，服务存在单点问题且数据可靠性也无法满足。当时也有考虑基于 beanstalkd 去做二次开发，但看完代码之后觉得需要改造的点不只是复制，还有类似内存控制等等，所以没有选择 beanstalkd 二次开发的方案。

也考虑过类似基于 kafka/rocketmq 等消息队列作为存储的方案，最后从存储设计模型和团队技术栈等原因决定选择基于 redis 作为存储来实现任务队列的功能。

设计和实现​

基础概念​

数据存储​

lmstfy 的 redis 存储由四部分组成:

  1. timer(sorted set) - 用来实现延迟任务的排序，再由后台线程定期将到期的任务写入到 Ready Queue 里面
  2. ready queue (list) - 无延时或者已到期任务的队列
  3. deadletter (list) - 消费失败(重试次数到达上限)的任务，可以手动重新放回队列
  4. job pool(string) - 存储消息内容的池子

支持延迟的任务队列本质上是两个数据结构的结合: FIFO 和 sorted set。sorted set 用来实现延时的部分，将任务按照到期时间戳升序存储，然后定期将到期的任务迁移至 FIFO(ready queue)。任务的具体内容只会存储一份在 job pool 里面，其他的像 ready queue，timer，deadletter 只是存储 job id，这样可以节省一些内存空间。

以下是整体设计:

\"img\"

任务写入​

任务在写入时会先产生一个 job id，目前 job id (16bytes) 包含写入时间戳、 随机数和延迟秒数， 然后写入 key 为 j:{namespace}/{queue}/{ID} 的任务到任务池 (pool) 里面。之后根据延时时间来决定这个 job id 应该到 ready queue 还是 timer 里面:

timer 的实现是利用 zset 根据绝对时间戳进行排序，再由旁路线程定期轮询将到期的任务通过 redis lua script 来将数据原子地转移到 ready queue 里面。

任务消费​

之前提到任务在消费失败之后预期能够重试，所以必须知道什么时候可认为任务消费失败？业务在消费时需要携带 ttr(time to run) 参数，用来表示业务预期任务最长执行时间，如果在 ttr 时间内没有收到业务主动回复 ACK 消息则会认为任务失败(类似 tcp 的重传 timer)。

\"img\"

消费时从 ready queue 中 (B)RPOP 出任务的 job id，然后根据 job id 从 pool 中将任务内容发送给消费者。同时对 tries 减一，根据消费的 ttr(time to run) 参数, 将任务放入 timer 中。如果 tries 为零, 在 ttr 时间到期后该 job id 会被放入 dead letter 队列中(表示任务执行失败)。

同步任务模型​

lmstfy 除了可以用来实现异步和延时任务模型之外，因为 namespace 下面的队列是动态创建且 job id 全局唯一，还可以用来实现同步任务模型 (producer 等到任务执行成功之后返回)。大概如下:

  1. producer 写入任务之后拿到 job id, 然后监听(consume)以 job id 为名的队列
  2. consumer 消费任务成功后，写回复消息到同样以 job id 为名的队列中
  3. producer 如果规定时间内能读到回复消息则认为消费成功，等待超时则认为任务失败

如何实现横向扩展​

lmstfy 本身是无状态的服务可以很简单的实现横向扩展，这里的横向扩展主要是存储(目前只支持 Redis)的横向扩展。设计也比较简单，主要通过通过 namespace 对应的 token 路由来实现， 比如我们当前配置两组 Redis 资源: default 和 meipai:

[Pool]
[Pool.default]
Addr = \"1.1.1.1:6379\"
[Pool.meipai]
Addr = \"2.2.2.2:6389\"

在创建 namespace 时可以指定资源池，token 里面会携带资源池名字作为前缀。比指定美拍资源池，那么 token 类似: meipai:01DT8EZ1N6XT ，后续在处理请求时就可以根据 token 里面携带的资源池名称来进行路由数据。不过这种设计实现队列级别的扩展，如果单队列存储消息量超过 Redis 内存上限则需要其他手段来解决(后面会支持磁盘类型存储)。

如何使用​

# 创建 namespace 和 token, 注意这里使用管理端口
$ ./scripts/token-cli -c -n test_ns -p default -D \"test ns apply by @hulk\" 127.0.0.1:7778

{
    \"token\": \"01DT9323JACNBQ9JESV80G0000\"
}

# 写入内容为 value 的任务
$ curl -XPUT -d \"value\" -i \"http://127.0.0.1:7777/api/test_ns/q1?tries=3&delay=1&token=01DT931XGSPKNB7E2XFKPY3ZPB\"

{\"job_id\":\"01DT9323JACNBQ9JESV80G0000\",\"msg\":\"published\"}

# 消费任务
$ curl -i \"http://127.0.0.1:7777/api/test_ns/q1?ttr=30&timeout=3&&token=01DT931XGSPKNB7E2XFKPY3ZPB\"

{\"data\":\"value\",\"elapsed_ms\":272612,\"job_id\":\"01DT9323JACNBQ9JESV80G0000\",\"msg\":\"new job\",\"namespace\":\"test_ns\",\"queue\":\"q1\",\"ttl\":86127}

# ACK 任务 id，表示消费成功不再重新下发改任务
curl -i -XDELETE \"http://127.0.0.1:7777/api/test_ns/q1/job/01DT9323JACNBQ9JESV80G0000?token=01DT931XGSPKNB7E2XFKPY3ZPB\"

更详细 API 说明见项目 README，目前我们提供了 PHP/Golang 两种语言 SDK，其他语言可以直接基于 HTTP 库封装即可。

监控指标​

lmstfy 任务队列的另外一个设计目标是提供足够多的监控指标，除了作为监控报警之外，也可以为类似 k8s 的 scheduler 提供反馈指标，以当前队列堆积情况指导系统进行动态缩扩容。

业务指标:

性能相关指标:

未来计划​

在我们当前的使用场景下, 一个 2G 的 redis 实例就能够支撑千万级左右的延迟任务量。但类似对象存储的生命周期管理(对象存储的 TTL)这种量大且延时间长的场景，使用 Redis 存储成本比较高。后续会考虑基于本地文件或者以 kvrocks (自研的 SSD Redis KV) 作为存储，将数据落到磁盘。kvrocks 目前也是开源状态，美图内部线上已经部署接近 100 个实例，外部也有一些类似白山云等公司在使用，后面也会输出相关设计和实现文章。欢迎大家去关注和使用，更加欢迎 issue 和 PR。

kvrocks Github 项目地址: https://github.com/meitu/kvrocks

lmsty 的 Github 项目地址: https://github.com/meitu/lmstfy

如有更多技术问题想要交流可以发邮件给我: hulk.website@gmail.com

", "url": "https://hulkdev.com/posts-meitu-opensource-task-queue", "title": "美图开源任务队列 - LMSTFY", "summary": "lmstfy(Let Me Schedule Task For You) 是美图架构基础服务团队在 2018 年初基于 Redis 实现的简单任务队列(Task Queue)服务，目前在美图多个线上产品使用接近两年的时间。主要提供以下特性:", "date_modified": "2019-11-28T00:00:00.000Z", "tags": [ "LMSTFY", "Queue", "Redis" ] }, { "id": "posts-redis-thread-io", "content_html": "

前天晚上不经意间在 youtube 上面看到 Redis 作者 Salvatore 在 RedisConf 2019 分享，其中一段展示了 Redis 6 引入的多线程 IO 特性对性能提升至少是一倍以上，内心很是激动，迫不及待地去看了一下相关的代码实现。

目前对于单线程 Redis 来说，性能瓶颈主要在于网络的 IO 消耗, 优化主要有两个方向:

  1. 提高网络 IO 性能，典型的实现像使用 DPDK 来替代内核网络栈的方式
  2. 使用多线程充分利用多核，典型的实现像 Memcached

协议栈优化的这种方式跟 Redis 关系不大，多线程特性在社区也被反复提了很久后终于在 Redis 6 加入多线程，Salvatore 在自己的博客 An update about Redis developments in 2019 也有简单的说明。但跟 Memcached 这种从 IO 处理到数据访问多线程的实现模式有些差异。Redis 的多线程部分只是用来处理网络数据的读写和协议解析，执行命令仍然是单线程。之所以这么设计是不想因为多线程而变得复杂，需要去控制 key、lua、事务，LPUSH/LPOP 等等的并发问题。整体的设计大体如下:

\"img\"

代码实现​

多线程 IO 的读(请求)和写(响应)在实现流程是一样的，只是执行读还是写操作的差异。同时这些 IO 线程在同一时刻全部是读或者写，不会部分读或部分写的情况，所以下面以读流程作为例子。分析过程中的代码只是为了辅助理解，所以只会覆盖核心逻辑而不是全部细节。如果想完全理解细节，建议看完之后再次看一次源码实现。

加入多线程 IO 之后，整体的读流程如下:

  1. 主线程负责接收建连请求，读事件到来(收到请求)则放到一个全局等待读处理队列
  2. 主线程处理完读事件之后，通过 RR(Round Robin) 将这些连接分配给这些 IO 线程，然后主线程忙等待(spinlock 的效果)状态
  3. IO 线程将请求数据读取并解析完成(这里只是读数据和解析并不执行)
  4. 主线程执行所有命令并清空整个请求等待读处理队列(执行部分串行)

上面的这个过程是完全无锁的，因为在 IO 线程处理的时主线程会等待全部的 IO 线程完成，所以不会出现 data race 的场景。

注意：如果对于代码实现没有兴趣的可以直接跳过下面内容，对了解 Redis 性能提升并没有伤害。

下面的代码分析和上面流程是对应的，当主线程收到请求的时候会回调 network.c 里面的 readQueryFromClient 函数:

void readQueryFromClient(aeEventLoop *el, int fd, void *privdata, int mask) {
    /* Check if we want to read from the client later when exiting from
     * the event loop. This is the case if threaded I/O is enabled. */
    if (postponeClientRead(c)) return;
    ...
}

readQueryFromClient 之前的实现是负责读取和解析请求并执行命令，加入多线程 IO 之后加入了上面的这行代码，postponeClientRead 实现如下：

int postponeClientRead(client *c) {
    if (io_threads_active &&   // 多线程 IO 是否在开启状态，在待处理请求较少时会停止 IO 
    多线程
        server.io_threads_do_reads && // 读是否开启多线程 IO
        !(c->flags & (CLIENT_MASTER|CLIENT_SLAVE|CLIENT_PENDING_READ)))  // 主从库复制请求不使用多线程 IO
    {
        // 连接标识为 CLIENT_PENDING_READ 来控制不会反复被加队列,
        // 这个标识作用在后面会再次提到
        c->flags |= CLIENT_PENDING_READ;
        // 连接加入到等待读处理队列
        listAddNodeHead(server.clients_pending_read,c);
        return 1;
    } else {
        return 0;
    }
}

postponeClientRead 判断如果开启多线程 IO 且不是主从复制连接的话就放到队列然后返回 1，在 readQueryFromClient 函数会直接返回不进行命令解析和执行。接着主线程在处理完读事件(注意是读事件不是读数据)之后将这些连接通过 RR 的方式分配给这些 IO 线程:

int handleClientsWithPendingReadsUsingThreads(void) {
  ...
    // 将等待处理队列的连接按照 RR 的方式分配给多个 IO 线程
    listRewind(server.clients_pending_read,&li);
    int item_id = 0;
    while((ln = listNext(&li))) {
        client *c = listNodeValue(ln);
        int target_id = item_id % server.io_threads_num;
        listAddNodeTail(io_threads_list[target_id],c);
        item_id++;
    }
    ...
    
    // 一直忙等待直到所有的连接请求都被 IO 线程处理完
    while(1) {
        unsigned long pending = 0;
        for (int j = 0; j < server.io_threads_num; j++)
            pending += io_threads_pending[j];
        if (pending == 0) break;
    }

代码里面的 io_threads_list 用来存储每个 IO 线程对应需要处理的连接，然后主线程将这些连接通过 RR 的方式分配给这些 IO 线程后进入忙等待状态(相当于主线程 blocking 住)。IO 处理线程入口是 IOThreadMain 函数:

void *IOThreadMain(void *myid) {
  while(1) {
        // 遍历线程 id 获取线程对应的待处理连接列表
        listRewind(io_threads_list[id],&li);
        while((ln = listNext(&li))) {
            client *c = listNodeValue(ln);
            // 通过 io_threads_op 控制线程要处理的是读还是写请求
            if (io_threads_op == IO_THREADS_OP_WRITE) {
                writeToClient(c->fd,c,0);
            } else if (io_threads_op == IO_THREADS_OP_READ) {
                readQueryFromClient(NULL,c->fd,c,0);
            } else {
                serverPanic(\"io_threads_op value is unknown\");
            }
        }
        listEmpty(io_threads_list[id]);
        io_threads_pending[id] = 0;
  }
}

IO 线程处理根据全局 io_threads_op 状态来控制当前 IO 线程应该处理读还是写事件，这也是上面提到的全部 IO 线程同一时刻只会执行读或者写。另外，心细的同学可能注意到处理线程会调用 readQueryFromClient 函数，而连接就是由这个回调函数加到队列的，那不就死循环了？ 这个的答案在 postponeClientRead 函数，已经加到等待处理队列的连接会被设置 CLIENT_PENDING_READ 标识。postponeClientRead 函数不会把连接再次加到队列，那么 readQueryFromClient 会继续执行读取和解析请求。readQueryFromClient 函数读取请求数据并调用 processInputBuffer 函数进行解析命令，processInputBuffer 会判断当前连接是否来自 IO 线程，如果是的话就只解析不执行命令，代码就不贴了。

大家去看 IOThreadMain 实现会发现这些 io 线程是没有任何 sleep 机制，在空闲状态也会导致每个线程的 CPU 跑到 100%，但简单 sleep 则会导致读写处理不及时而导致性能更差。Redis 当前的解决方式是通过在等待处理连接比较少的时候关闭这些 IO 线程。为什么不适用条件变量来控制呢？我也没想明白，后面可以到社区提问。

性能对比​

压测配置:​

Redis Server: 阿里云 Ubuntu 18.04，8 CPU 2.5 GHZ, 8G 内存，主机型号 ecs.ic5.2xlarge
Redis Benchmark Client: 阿里云 Ubuntu 18.04，8 2.5 GHZ CPU, 8G 内存，主机型号 ecs.ic5.2xlarge

多线程 IO 版本刚合并到 unstable 分支一段时间，所以只能使用 unstable 分支来测试多线程 IO，单线程版本是 Redis 5.0.5。多线程 IO 版本需要新增以下配置:

io-threads 4 # 开启 4 个 IO 线程
io-threads-do-reads yes # 请求解析也是用 IO 线程

压测命令: redis-benchmark -h 192.168.0.49 -a foobared -t set,get -n 1000000 -r 100000000 --threads 4 -d ${datasize} -c 256

\"img\"

\"img\"

从上面可以看到 GET/SET 命令在 4 线程 IO 时性能相比单线程是几乎是翻倍了。另外，这些数据只是为了简单验证多线程 IO 是否真正带来性能优化，并没有针对严谨的延时控制和不同并发的场景进行压测。数据仅供验证参考而不能作为线上指标，且只是目前的 unstble 分支的性能，不排除后续发布的正式版本的性能会更好。

注意: Redis Benchmark 除了 unstable 分支之外都是单线程，对于多线程 IO 版本来说，压测发包性能会成为瓶颈，务必自己编译 unstable 分支的 redis-benchmark 来压测，并配置 --threads 开启多线程压测。另外，如果发现编译失败也莫慌，这是因为 Redis 用了 Atomic_ 特性，更新版本的编译工具才支持，比如 GCC 5.0 以上版本。

总结​

Redis 6.0 预计会在 2019 年底发布，将在性能、协议以及权限控制都会有很大的改进。Salvatore 今年全身心投入在优化 Redis 和集群的功能，特别值得期待。另外，今年年底社区也会同时发布第一个版本 redis cluster proxy 来解决多语言 SDK 兼容的问题，期待在具备 proxy 功能之后 cluster 能在国内有更加广泛的应用。

", "url": "https://hulkdev.com/posts-redis-thread-io", "title": "Redis 6 多线程 IO", "summary": "前天晚上不经意间在 youtube 上面看到 Redis 作者 Salvatore 在 RedisConf 2019 分享，其中一段展示了 Redis 6 引入的多线程 IO 特性对性能提升至少是一倍以上，内心很是激动，迫不及待地去看了一下相关的代码实现。", "date_modified": "2019-08-08T00:00:00.000Z", "tags": [ "Redis" ] }, { "id": "posts-meitu-opensource-twemproxy", "content_html": "

美图在 2017 年下半年开始计划做 Redis/Memcached 资源 PaaS 平台，而 PaaS 化之后面临一个问题是如何实现资源缩容/扩容对业务无感，为了解决这个问题，美图技术团队于 17 年 11 月引入 twemproxy 作为资源网关。

但是长期的实践中，其开源版本不能完全适应美图的实际情况，其主要存在单线程模型无法利用多核，性能不佳；配置无法在线 Reload ；Redis 不支持主从模式；无延时指标等问题，所以美图技术团队对其进行了相应的改造。我们基于之上实现了多进程以及配置在线更新的功能，同时增加了一些延时的相关监控指标。

本文将为大家详细讲解 twemproxy 实现以及相应地改造，希望能给其他的技术团队提供一些可以借鉴的经验。

为什么要选择 twemproxy​

wemproxy 是一款由 twitter 开源的 Redis/Memcached 代理，主要目标是减少后端资源的连接数以及为缓存横向扩展能力。 twemproxy 支持多种 hash 分片算法，同时具备失败节点自动剔除的功能。除此之外，其他比较成熟的开源解决方案还有 codis，codis 具备在线的 auto-scale 以及友好的后台管理，但整体的功能更接近于 Redis Cluster，而不是代理。美图这边需要的是一个 Redis 和 Memcached 协议类 PaaS 服务的代理(网关)，所以我们最终选择了 twemproxy。

twemproxy 实现​

twemproxy 主要的功能是解析用户请求后转发到后端的缓存资源，成功后在把响应转发回客户端。

代码实现的核心是三种连接对象:

  1. proxy connection， 用来监听用户建立连接的请求，建立连接成功后会对应产生一个客户端连接
  2. client connection，由建连成功后产生，用户读写数据都是通过 client connection 解析请求后，根据 key 和哈希规则选择一个 server 进行转发
  3. server connection，转发用户请求到缓存资源并接收和解析响应数据转回 client connection，client connection 将响应返回到用户

三种连接的数据流向如下图：

\"img\"\n(上图的 client connection 之所以没有 imsgq 是因为请求解析完可以直接进入 server 的 imsgq)

  1. 用户通过 proxy connection 建立连接，产生一个 client connection
  2. client connection 开始读取用户的请求数据，并将完整的请求根据 key 和设置的哈希规则选择 server, 然后将这个请求存放到 server 的 imsgq
  3. 接着 server connection 发送 imsgq 请求到远程资源，发送完成之后(写 tcp buffer) 就会将 msg 从 imsgq 迁移到 omsgq，响应回来之后从 omsgq 队列里面找到这个对应的 msg 以及 client connection
  4. 最后将响应内容放到 client connection 的 omsgq，由 client connection 将数据发送回客户端。

上面提到的用户请求和资源响应的数据都是在解析之后放到内存的 buf 里面，在 client 和 server 两种连接的内部流转也只是指针的拷贝(官网 README 里面提到的 Zero Copy)。这也是 twemproxy 单线程模型在小包场景能够达到 10w qps 的原因之一，几乎不拷贝内存。

但对于我们来说，当前开源版本存在几个问题:

多进程版本​

针对以上的几个问题，美图的开源版本都做了一些修改，最核心的功能是多进程和配置在线 reload。改造后整体进程模型类似 Nginx， 简单示意图如下:

\"img\"

master 的功能就是管理 worker 进程，不接收和处理用户请求。如果 worker 进程异常退出，那么 master 则会自动拉起新的进程来替代挂掉的老进程。除此之外，master 还会接收来自用户的几种信号:

同时还增加了几个全局配置: 

global:
  worker_processes: auto      # num of workers, fallback to single process model while worker_processes is 0
  max_openfiles: 102400       # max num of open files in every worker process
  user: nobody                # user of worker's process, master process should be setup with root
  group: nobody               # group of worker's process
  worker_shutdown_timeout: 30 # terminate the old worker after worker_shutdown_timeout, unit is second

除了 worker_shutdown_timeout 其他几个配置应该比较好理解。worker_shutdown_timeout 是配置老 worker 在收到退出信号后多长时间退出。这个配置是跟多进程实现相关的参数，我们是通过启动新进程替代老进程的方式来实现配置以及进程数目的在线修改，所以这个配置就是用来指定老进程的保留时间。

Reuse Port​

在 reuse port 之前，多线程/进程服务监听建连请求一般有两种方式:

  1. 由一个线程负责接收所有的新连接，其他线程服务只负责建立连接之后的处理。这种方式的问题是在短连接场景下，这个 accept 线程很容易成为瓶颈(单核我们这边测试一般是在 4w+/s 左右)
  2. 所有的线程/进程都同时 accept 同一个监听的文件句柄。 这种方式的问题是在高负载的场景下，不同线程/进程的唤醒会不均匀，另外会有惊群的效果(accept/epoll 在新版本内核中也有解决惊群问题)

reuse port 的主要作用就是允许多个 socket 同时监听同一个端口，同时不会存在建立连接不均匀的问题。 使用 reuse port 也相当简单，只需要把监听通过一个端口的 socket 都设置上 reuse port 标识即可。

int
nc_set_reuseport(int sd)
{
#ifdef NC_HAVE_REUSEPORT
    int reuse;
    socklen_t len;

    reuse = 1;
    len = sizeof(reuse);

    return setsockopt(sd, SOL_SOCKET, SO_REUSEPORT, &reuse, len);
#else
    return 0;
#endif
}

虽然 reuse port 是在 linux 3.9 才被合并进来，但很多发行版的 OS 都有 backport 到更早之前的版本（至少我们在使用的 centos6 的 kernel 2.6.32 是有的），很多博客在这点上有些误导。另外，在 reload 时候也不能简单将老的监听关闭，会导致 tcp backlog 里面这些三次握手成功但未 accept 的连接丢失，业务在这些连接上发送数据则会收到 rst 包。

我们解决这个问题的方式是让监听连接都在 master 进程上面创建和维护，worker 进程只是在 fork 之后直接继承监听的连接，所以在 reload 的时候 master 就可以将老 worker 里面的监听连接迁移到新的 worker， 来保证 tcp backlog 里面的数据不会丢失。

具体代码见: nc_process.c#L172, 这种方式能够在进程数不变或者增多的场景下保证 backlog 里面的数据不会丢，进程数缩减时还是会丢失一些

Redis 主从模式​

在原生的 twemproxy 里面是不支持 Redis 主从模式的，这个应该主要是因为 twemproxy 把 Redis/Memcached 当做是缓存而不是存储，所以这种主从结构实际上是没有必要的，运维也比较简单。但是对于我们内部业务来说，有些并不是全部都是作为缓存，所以就需要这种主从结构。配置也比较简单:

    servers:
        -  127.0.0.1:6379:1 master
        - 127.0.0.1:6380:1

如果检测到 server 的名字为 master 则认为该实例为主，一个池子里面只允许一个主，否则认为配置不合法。

统计指标​

个人觉得 twemproxy 存在的另外一个问题是延时指标完全缺失，这个对于排查问题以及监控报警是比较不利的。针对这个问题，我们增加了两种延时指标

  1. request latency, 指的是客户端请求到返回的延时, 包含 twemproxy 内部以及 server 的耗时，这个指标更加接近业务的耗时
  2. server latency, 指的是 twemproxy 请求 server 的耗时，这个可以理解为 Redis/Memcached server 的耗时

在偶发问题的场景下，根据两种延时可以定位是 twemproxy、server 还是客户端的问题(比如 GC)导致慢请求，另外也可以慢请求的比例进行监控报警。这两种指标是通过 bucket 的方式来记录的，比如 <1ms 的数目，<10ms 的数目等等。

仍然存在的问题​

  1. 在 worker 数目减少的场景下，被销毁的老 Worker 的 tcp backlog 会丢失会导致一些连接超时
  2. unix socket 没有 reuse port 类似的机制，所以实际上还是单进程但可以支持在线 reload
  3. 不支持 Memcached 二进制协议，几年前有人提供相关 PR 但一直都没有进入 master
  4. 客户端的最大连接数有配置但实际上不生效，这个功能我们后续会加上
  5. 命令支持不全(主要是没有 key 以及一些 blocking 的指令)
  6. reload 期间新老进程的配置不一致会可能会导致脏数据

性能压测​

以下数据是在长连接小包场景下压测得出，主要是验证多进程版本是否跟预期的一致。没有其他硬件到达瓶颈之前，性能可以随着 CPU 核数线性增长。

压测环境如下:

\"img\"

单个 worker 场景和 twemproxy 改造之前的性能差不多，在 10w 左右。随着 worker 数目增加，后面性能和 worker 基本是保持线上增长，符合预期。8 核以上的瓶颈是 bond0 模式下包接收不均匀导致单网卡性能达到瓶颈，数据无法作为参考。上面的数据也是我们自己环境的压测数据，大家可以自行验证。如果是多网卡需要注意绑定中断或者多队列到多个 CPU, 避免 CPU0 软中断处理成为瓶颈。

最后​

多进程版本的 twemproxy 实现上算是比较简单，但过程中发现并修复不少 twemproxy 细节问题(一部分是使用方报告)，比如 mbuf 一旦分配就不会收缩导致内存上涨之后不再下降的问题等等。很多功能细节我们也在不断优化，我们也只维护 Github 上的一个版本。

代码地址: https://github.com/meitu/twemproxy

除此之外，我们团队目前也开源其他一些项目:

后续还会开源更多的东西，欢迎大家多多关注~

", "url": "https://hulkdev.com/posts-meitu-opensource-twemproxy", "title": "美图多线程 twemproxy 实现", "summary": "美图在 2017 年下半年开始计划做 Redis/Memcached 资源 PaaS 平台，而 PaaS 化之后面临一个问题是如何实现资源缩容/扩容对业务无感，为了解决这个问题，美图技术团队于 17 年 11 月引入 twemproxy 作为资源网关。", "date_modified": "2018-10-10T00:00:00.000Z", "tags": [ "Twemproxy", "Redis", "Memcached" ] }, { "id": "posts-redis-async-delete", "content_html": "

对于 Redis 这种单线程模型的服务来说，一些耗时的命令阻塞其他请求是个头痛的问题。典型的命令如 KEYS/FLUSHALL/FLUSHDB 等等，一般线上也会禁用这些会遍历整个库的命令。而像 DEL/LRANGE/HGETALL 这些可能导致阻塞的命令经常被工程师忽视，这些命令在 value 比较大的时候跟 KEYS 这些并没有本质区别。

Redis 4.0 开始针对 DEL/FLUSHALL/FLUSHDB 做了一些优化。

1) DEL/FLUSHALL/FLUSHDB 异步化​

FLUSHALL/FLUSHDB 清除库的时候因为要对每个 kv 进行遍历会比较耗时。同理对于 DEL 命令也是，如 VALUE 是链表，集合或者字典，同样要遍历删除。在 Redis 4.0 针对这三个命令引入了异步化处理，避免阻塞其他请求。FLUSHALL/FLUSHDB 加了一个 ASYNC 参数，同时新增 UNLINK 来表示异步化的删除命令。

为什么 DEL 也不使用类似 FLUSHALL/FLUSHDB 命令加个参数的方式？

调皮的作者是这么说的:

There are reasons why UNLINK is not the default for DEL. I know things… I can’t talk (**).

意思大概就是: 「原因我知道但不告诉你...」

不过我猜主要原因是因为 DEL 命令是支持不定参数，如果加个 ASYNC 参数没办法判断到底这个是 key 还是异步删除的选项。

2) DEL 异步化的实现​

我们可以直接来看 UNLINK 命令的实现:

void unlinkCommand(client *c) {
    // lazy 参数设置 1，表示异步删除
    delGenericCommand(c,1);
}

void delGenericCommand(client *c, int lazy) {
    int numdel = 0, j;

    for (j = 1; j < c->argc; j++) {
        expireIfNeeded(c->db,c->argv[j]);
        // 如果是异步删除调用 dbAsyncDelete
        int deleted  = lazy ? dbAsyncDelete(c->db,c->argv[j]) :
                              dbSyncDelete(c->db,c->argv[j]);
        ...
    }    
    addReplyLongLong(c,numdel);
}

我们可看到 unlink 命令会调用 dbAsyncDelete 来实现异步调用。

#define LAZYFREE_THRESHOLD 64
int dbAsyncDelete(redisDb *db, robj *key) {
    // 先把 key 从过期时间字典里面删除
    if (dictSize(db->expires) > 0) dictDelete(db->expires,key->ptr);
    // 把 kv 从字典里面摘除但不是删除 value，后续命令就查询不到
    dictEntry *de = dictUnlink(db->dict,key->ptr);
    if (de) {
        robj *val = dictGetVal(de);
        // 不是所有的 key 都会走异步化删除，如果 value 比较小会直接删除
        // 如果 value 是字典/链表/集合且不能是压缩的返回对应的元素数目，其他都返回 1
        size_t free_effort = lazyfreeGetFreeEffort(val);

        // 只有计算出来的 free_effort 大于 LAZYFREE_THRESHOLD(64) 才会进入异步处理
        if (free_effort > LAZYFREE_THRESHOLD) {
            atomicIncr(lazyfree_objects,1,lazyfree_objects_mutex);
            // 创建 BIO_LAZY_FREE 任务，放到异步队列
            bioCreateBackgroundJob(BIO_LAZY_FREE,val,NULL,NULL);
            dictSetVal(db->dict,de,NULL);
        }
    }

    if (de) {// 如果 key 存在，释放字典里面结构
        dictFreeUnlinkedEntry(db->dict,de);
        if (server.cluster_enabled) slotToKeyDel(key);
        return 1;
    } else {
        return 0;
    }
}

unlink 命令处理上并不是所有的 kv 都会走异步化删除，而是会根据 value 的大小进行评分后筛选，超过阀值的才会走异步化删除。这个计算函数是 lazyfreeGetFreeEffort。

同时 Redis 4.0 专门多开了一个后台线程专门来异步处理 DEL, FLUSHALL 和 FLUSHDB 这三个命令。

        } else if (type == BIO_LAZY_FREE) {
            if (job->arg1) // 处理 DEL 过来的 key
                lazyfreeFreeObjectFromBioThread(job->arg1);
            else if (job->arg2 && job->arg3) //  处理 flush 命令 
                lazyfreeFreeDatabaseFromBioThread(job->arg2,job->arg3);
            else if (job->arg3)
                lazyfreeFreeSlotsMapFromBioThread(job->arg3);
        }

3) FLUSHALL/FLUSHDB​

这两个命令也是比较类似，Redis 会先检查这两个命令是否有带 async:

int getFlushCommandFlags(client *c, int *flags) {
    if (c->argc > 1) { 
        // 判断第二个参数是否为 async
        if (c->argc > 2 || strcasecmp(c->argv[1]->ptr,\"async\")) {
            addReply(c,shared.syntaxerr);
            return C_ERR;
        }    
        *flags = EMPTYDB_ASYNC;
    } else {
        *flags = EMPTYDB_NO_FLAGS;
    }    
    return C_OK;
}

接着在 emptyDb 判断是异步清数据，如果是异步清除则会调用 emptyDbAsync:

void emptyDbAsync(redisDb *db) {
    // 保留老的数据库指针并重新创建新的数据库
    dict *oldht1 = db->dict, *oldht2 = db->expires;
    db->dict = dictCreate(&dbDictType,NULL);
    db->expires = dictCreate(&keyptrDictType,NULL);
    atomicIncr(lazyfree_objects,dictSize(oldht1),
        lazyfree_objects_mutex);
    // 把要清空的 db 作为一个 job 添加到后台的处理队列
    bioCreateBackgroundJob(BIO_LAZY_FREE,NULL,oldht1,oldht2);
}

4) 总结​

FLUSHALL/FLUSHDB 这种命令线上环境基本都会禁用，大家犯错的概率比较小。而像 DEL 这种命令属于高频的操作，删除大 value 导致的阻塞问题容易被忽视，异步化删除可以一定程度上规避这种问题。

参考连接: http://antirez.com/news/110

", "url": "https://hulkdev.com/posts-redis-async-delete", "title": "Redis 4.0 非阻塞删除", "summary": "对于 Redis 这种单线程模型的服务来说，一些耗时的命令阻塞其他请求是个头痛的问题。典型的命令如 KEYS/FLUSHALL/FLUSHDB 等等，一般线上也会禁用这些会遍历整个库的命令。而像 DEL/LRANGE/HGETALL 这些可能导致阻塞的命令经常被工程师忽视，这些命令在 value 比较大的时候跟 KEYS 这些并没有本质区别。", "date_modified": "2017-01-24T00:00:00.000Z", "tags": [ "Redis" ] }, { "id": "posts-redis-mixed-format", "content_html": "

Redis 当前支持 aof 和 rdb 这两种持久化方式。 有些对 Redis 不是特别的了解同学误解持久化是读写数据也会到磁盘。这里辟谣一下:

Redis 读写都是全内存的, 持久化数据只是作为磁盘备份, 实例重启或者机器断电的时候可以从磁盘加载到内存

由于本篇博客主要是为了分析 4.0 版本的 rdb 和 aof 混合存储的实现，所以不会详细介绍 rdb 和 aof。如果有想进一步了解可参考 《Redis 设计与实现》 一书。

1) aof 和 rdb​

1.1) rdb 简介​

rdb 是某一个时刻的内存镜像数据写入到磁盘文件，之后的写入数据会丢失。 rdb 持久化方式的优点是持久化后的文件比较小(只有某一个时刻的数据且会压缩)，实例重启时加载会更快。缺点是如果实例重启，备份时刻之后的写入数据会丢失。

1.2) aof 简介​

aof 是将 Redis 写入命令写入追加到磁盘文件。根据配置的刷盘策略不同，实例重启丢掉的数据量也不一样。现在有下面三种方式:

aof 持久化方式的优点就是重启丢失的数据会比 rdb 少。缺点因为写入命令追加写入的方式，在写入比较多的场景下会导致重启加载数据太慢。举个例子，如果对 key 做 1000 次 incr, 则 aof 文件则会记录 1000 次 incr，而 rdb 只存储 1000 这个值即可。不过 aof 允许 rewrite, 比如把例子里面的 1000 次 incr a 变成一次 incr a 1000 命令，这个是另外一个话题了。

2) 混合写入​

上面已经说明了 rdb 和 aof 各自的优缺点，Redis 4.0 开始支持 rdb 和 aof 的混合持久化(默认关闭)。如果把混合持久化打开，aof rewrite 的时候就直接把 rdb 的内容写到 aof 文件开头。aof 文件内容会变成如下:

             +------------------------+
             |                        |   
             |                        |   
             |          RDB           |   
             |         FORMAT         |   
             |                        |   
             |                        |   
             |                        |   
             +------------------------+
             |                        |   
             |        AOF             |   
             |       FORMAT           |   
             +------------------------+

这样做的好处是可以结合 rdb 和 aof 的优点, 快速加载同时避免丢失过多的数据。当然缺点也是有的， aof 里面的 rdb 部分就是压缩格式不再是 aof 格式，可读性差。

2.1) 混合持久化实现​

下面是 aof.c 里面在做 aof 文件写入的代码，具体函数 rewriteAppendOnlyFile :

    // aof_use_rdb_preamble = 1 表示打开混合存储模式
    if (server.aof_use_rdb_preamble) {
        int error;
        // aof 文件前面部分就是直接写入 rdb 文件
        if (rdbSaveRio(&aof,&error,RDB_SAVE_AOF_PREAMBLE,NULL) == C_ERR) {
            errno = error;
            goto werr;
        }    
    } else {
            // 如果是关闭混合存储和之前一样，保持 aof 格式
        if (rewriteAppendOnlyFileRio(&aof) == C_ERR) goto werr;
    }

2.2) 混合 aof 加载​

开启混合存储模式后 aof 文件加载的流程如下:

  1. aof 文件开头是 rdb 的格式, 先加载 rdb 内容再加载剩余的 aof
  2. aof 文件开头不是 rdb 的格式，直接以 aof 格式加载整个文件
    char sig[5]; /* \"REDIS\" */
    if (fread(sig,1,5,fp) != 5 || memcmp(sig,\"REDIS\",5) != 0) { 
            // 前部分内容不是 rdb 格式，不是混合持久化的方式
        if (fseek(fp,0,SEEK_SET) == -1) goto readerr;
    } else {
        rio rdb; 

        serverLog(LL_NOTICE,\"Reading RDB preamble from AOF file...\");
        if (fseek(fp,0,SEEK_SET) == -1) goto readerr;
        rioInitWithFile(&rdb,fp);
        // 前面部分是 rdb 格式说明是混合持久化，先加载 rdb 后面逻辑再加载 aof
        if (rdbLoadRio(&rdb,NULL) != C_OK) {
            serverLog(LL_WARNING,\"Error reading the RDB preamble of the AOF file, AOF loading aborted\");
            goto readerr;
        } else {
            serverLog(LL_NOTICE,\"Reading the remaining AOF tail...\");
        }    
    } 
    ...
    // 加载 aof 格式的数据

判断 aof 文件的前面部分是否为 rdb 格式，只需要判断前 5 个字符是否是 REDIS。这个是因为 rdb 持久化开头就是 REDIS, 同时 aof 命令开头一定不会是 REDIS（命令开头都是 *）。

", "url": "https://hulkdev.com/posts-redis-mixed-format", "title": "Redis 4.0 RDB 和 AOF 混合存储", "summary": "Redis 当前支持 aof 和 rdb 这两种持久化方式。 有些对 Redis 不是特别的了解同学误解持久化是读写数据也会到磁盘。这里辟谣一下:", "date_modified": "2017-01-23T00:00:00.000Z", "tags": [ "Redis" ] }, { "id": "posts-redis-new-sync", "content_html": "

上一篇介绍了 <Redis-4.0 module实现>，同时也提到 redis 4.0 一个比较大的改动就是 psync 优化, 本篇会介绍这个优化的部分。

在 2.8 版本之前 redis 没有增量同步的功能，主从只要重连就必须全量同步数据。如果实例数据量比较大的情况下，网络轻轻一抖就会把主从的网卡跑满从而影响正常服务，这是一个蛋疼的问题。2.8 为了解决这个问题引入了 psync (partial sync)功能，顾名思义就是增量同步。

1) 2.8 版本的 psync 机制​

2.8 引入 psync 之后的同步机制:

redis 判断是否允许 psync 有两个条件:

NOTE: 主库的 runid 是在主库进程启动之后生成的唯一标识(由进程id加上随机数组成), 在第一次全量同步的时候发送给从库，上面有看到 FULLSYNC 返回带有 runid 和 offset, 从库会在内存缓存这个 runid 和 offset 信息

    if (strcasecmp(master_runid, server.runid)) {
        if (master_runid[0] != '?') {
            redisLog(REDIS_NOTICE,\"Partial resynchronization not accepted: \"
                \"Runid mismatch (Client asked for '%s', I'm '%s')\",
                master_runid, server.runid);
        } else {
            redisLog(REDIS_NOTICE,\"Full resync requested by slave %s\",
                replicationGetSlaveName(c));
        }    
        goto need_full_resync;
    }

NOTE: backlog 是一个固定大小(默认1M)的环形缓冲区，用来缓存主从同步的数据。如果 offset 超过这个范围说明中间有一段数据已经丢失，需要全量同步。

    if (!server.repl_backlog ||
        psync_offset < server.repl_backlog_off ||
        psync_offset > (server.repl_backlog_off + server.repl_backlog_histlen))
    {    
        redisLog(REDIS_NOTICE,
            \"Unable to partial resync with slave %s for lack of backlog (Slave request was: %lld).\", replicationGetSlaveName(c), psync_offset);
        if (psync_offset > server.master_repl_offset) {
            redisLog(REDIS_WARNING,
                \"Warning: slave %s tried to PSYNC with an offset that is greater than the master replication offset.\", replicationGetSlaveName(c));
        }
        goto need_full_resync;
    }

有了 psync 之后主从短时间断掉重连就可以不用全量同步数据。前提也是这段时间的写入不能超过缓冲区。如果写入量比较大的，也建议稍微调大这个缓冲区。

2) 问题​

虽然 2.8 引入的 psync 可以解决短时间主从同步断掉重连问题，但以下几个场景仍然是需要全量同步:

  1. 主库/从库有重启过。因为 runnid 重启后就会丢失，所以当前机制无法做增量同步。
  2. 从库提升为主库。其他从库切到新主库全部要全量不同数据，因为新主库的 runnid 跟老的主库是不一样的。

这两个应该是我们比较常见的场景。主库切换或者重启都需要全量同步数据在从库实例比较大或者多的场景下，那内网网络带宽和服务都会有很大的影响。所以 redis 4.0 对 psync 优化之后可以一定程度上规避这些问题。

3）新版 psync 机制​

为了解决主从角色切换导致的重新全量同步，redis 4.0 引入多另外一个变量 replid2 来存放同步过的主库的 replid，同时 replid 在不同角色意义也有写变化。replid 在主库的意义和之前 replid 仍然是一样的，但对于从库来说，replid 表示当前正在同步的主库的 replid 而不再是本身的 replid。replid2 则表示前一个主库的 replid，这个在主从角色切换的时候会用到。

struct redisServer {
    ...
    /* Replication (master) */                                        
    char replid[CONFIG_RUN_ID_SIZE+1];  /* My current replication ID. */
    char replid2[CONFIG_RUN_ID_SIZE+1]; /* replid inherited from master*/

在主库判断是否允许 psync 的判断条件也有了一些变化：

    // 从库发送过来的 replid 是当前实例的 replid, 说明之前就是这个实例的从库
    // 或者和该主库曾经属于同一主库可以但同步进度不能比当前主库还快
    if (strcasecmp(master_replid, server.replid) &&                        
        (strcasecmp(master_replid, server.replid2) ||                           
         psync_offset > server.second_replid_offset))                                {
        ...
            goto need_full_resync;
    ｝
    
    // 判断同步进度是否已经超过范围
    if (!server.repl_backlog ||                                                        
        psync_offset < server.repl_backlog_off ||                                      
        psync_offset > (server.repl_backlog_off + server.repl_backlog_histlen))        
    {                                                                                  
        serverLog(LL_NOTICE,                                                           
            \"Unable to partial resync with slave %s for lack of backlog (Slave request was: %lld).\", replicationGetSlaveName(c), psync_offset);
        if (psync_offset > server.master_repl_offset) {
            serverLog(LL_WARNING,
                \"Warning: slave %s tried to PSYNC with an offset that is greater than the master replication offset.\", replicationGetSlaveName(c));
        }       
        goto need_full_resync;
    }

从代码可以看到，主库判断条件相比之前版本多了一个 replid2 的判断。如果之前这两个曾经属于同一个主库(多级也允许)， 那么新主库的 replid2 就是之前主库的 replid。只要之前是同一主库且新主库的同步进度比这个从库还快就允许增量同步。当然前提也是新主从的写入落后不能超过 backlog 大小。

举个栗子，假设 A <- B <- C 这种部署结构来说， A 是 B 的主库，B 是 C 的主库。如果把 C 提成新的主库，C <- A 以及 C <- B 都可以增量同步，因为切换后 C 的 replid2 其实就是 A。

另外一方面，在做 rdb 备份的时候 replid 和 offset 会被持久化到 rdb 文件，也就是说甚至是服务重启了也可以进行增量同步，具体见 rdbSaveInfoAuxFields 函数实现。

4）总结​

在主库有问题的时候想要把其中的一个从库提为主库，只要这个从库是这批从库之中同步最快的就其他从库切过来不需要全量同步数据。同时 rdb 里面还对 replid 和 offset 进行持久化，即使实例重启也可以做增量同步。有了这个优化之后之后切换的成本就大大降低了，服务也会更加平滑。

NOTE: 博客这是记录自己当前阶段一些想法, 不保证完全正确。如果有误的地方，你倒是来打我啊?

", "url": "https://hulkdev.com/posts-redis-new-sync", "title": "Redis 4.0 psync 优化", "summary": "上一篇介绍了 ，同时也提到 redis 4.0 一个比较大的改动就是 psync 优化, 本篇会介绍这个优化的部分。", "date_modified": "2017-01-21T00:00:00.000Z", "tags": [ "Redis" ] }, { "id": "posts-redis-module", "content_html": "

直到今天为止 (2017-01-17) Redis 4.0 已经发布了两个 rc 版本, 相比于上个版本(3.2)，这个版本的改动应该说是巨大的。主要有以下几个点:

每个功能都很值得期待，本篇博客会重点来介绍 Redis 的模块功能。

1) 为什么引入模块​

下面是引用 Redis 作者的一段说明:

「At the same time, years of experience with scripting, demonstrated that scripting is a way to “compose” existing features, but not a way to extend the capabilities of a system towards use cases it was not designed to cover.」

当前虽然支持 lua 脚本来作为扩展但更多的只是功能的组合，也就是说从设计上 lua 脚本的方式并不能满足扩展的需求，如我们想加个数据结构或者命令之类。

2) 模块内部实现​

2.1）模块加载​

Redis 通过 module load 命令来加载模块， 格式如下:

MODULE LOAD <path> [args...]

加载时指定模块(so文件)的路径以及加载的参数列表, 没有参数可以忽略。

我们来看看这个命令内部的实现模块加载的功能(module.c):

int moduleLoad(const char *path, void **module_argv, int module_argc) {
    int (*onload)(void *, void **, int);
    void *handle;
    RedisModuleCtx ctx = REDISMODULE_CTX_INIT;

    // 加载指定路径的动态库
    handle = dlopen(path,RTLD_NOW|RTLD_LOCAL);
    if (handle == NULL) {
        serverLog(LL_WARNING, \"Module %s failed to load: %s\", path, dlerror());
        return C_ERR;
    }
    // 检查是否有实现 RedisModule_OnLoad 函数
    onload = (int (*)(void *, void **, int))(unsigned long) dlsym(handle,\"RedisModule_OnLoad\");
    if (onload == NULL) {
        serverLog(LL_WARNING,
            \"Module %s does not export RedisModule_OnLoad() \"
            \"symbol. Module not loaded.\",path);
        return C_ERR;
    }
    // 回调用户自定义的 RedisModule_OnLoad 函数
    if (onload((void*)&ctx,module_argv,module_argc) == REDISMODULE_ERR) {
        if (ctx.module) moduleFreeModuleStructure(ctx.module);
        dlclose(handle);
        serverLog(LL_WARNING,
            \"Module %s initialization failed. Module not loaded\",path);
        return C_ERR;
    }    

    // 把模块注册到模块列表，主要是方便后面卸载
    dictAdd(modules,ctx.module->name,ctx.module);
    ctx.module->handle = handle;
    serverLog(LL_NOTICE,\"Module '%s' loaded from %s\",ctx.module->name,path);
    moduleFreeContext(&ctx);
    return C_OK;
}

模块加载的实现很简单，主要逻辑就是加载动态库并回调指定的函数。其他比如添加数据结构和命令之类就可以在这个回调函数里面来实现。最后再把模块添加到已加载的模块列表中。

2.2） 自定义命令​

接着看一下如何往 Redis 新增用户命令或者数据结构。

我们以 modules/helloblock.c 模块为例，上面已经说到模块加载的时候会回调用户实现的 RedisModule_OnLoad, 下面是该模块的实现:

int RedisModule_OnLoad(RedisModuleCtx *ctx, RedisModuleString **argv, int argc) {
    REDISMODULE_NOT_USED(argv);
    REDISMODULE_NOT_USED(argc);

    // 模块初始化函数，每个模块都必须调用
    if (RedisModule_Init(ctx,\"helloblock\",1,REDISMODULE_APIVER_1)
        == REDISMODULE_ERR) return REDISMODULE_ERR;

    // 添加一个 hello.block 命令
    if (RedisModule_CreateCommand(ctx,\"hello.block\",
        HelloBlock_RedisCommand,\"\",0,0,0) == REDISMODULE_ERR)
        return REDISMODULE_ERR;

    return REDISMODULE_OK;
}

这个回调函数主要做了两个事情，一个是调用模块初始化函数, 这个函数会将 Redis 对外提供的接口暴露给模块来调用，每个模块加载时都必须调用。另外做一个事情就是我们这里要关心的，如何添加命令到 Redis。

int RM_CreateCommand(RedisModuleCtx *ctx, const char *name, RedisModuleCmdFunc cmdfunc, const char *strflags, int firstkey, int lastkey, int keystep) {
    struct redisCommand *rediscmd;
    RedisModuleCommandProxy *cp;
    ...
    // 忽略次要的代码路径

    cp = zmalloc(sizeof(*cp));
    cp->module = ctx->module;
    // 真正的处理函数
    cp->func = cmdfunc;
    cp->rediscmd = zmalloc(sizeof(*rediscmd));
    cp->rediscmd->name = cmdname;
    // 命令处理函数设置为 RedisModuleCommandDispatcher
    cp->rediscmd->proc = RedisModuleCommandDispatcher;
    cp->rediscmd->arity = -1;
    cp->rediscmd->flags = flags | CMD_MODULE;
    cp->rediscmd->getkeys_proc = (redisGetKeysProc*)(unsigned long)cp;
    cp->rediscmd->firstkey = firstkey;
    cp->rediscmd->lastkey = lastkey;
    cp->rediscmd->keystep = keystep;
    cp->rediscmd->microseconds = 0;
    cp->rediscmd->calls = 0;
    dictAdd(server.commands,sdsdup(cmdname),cp->rediscmd);
    dictAdd(server.orig_commands,sdsdup(cmdname),cp->rediscmd);
    return REDISMODULE_OK;

这个逻辑很简单，创建一个 RedisModuleCommandProxy 并把它的 rediscmd 作为命令的处理函数，也就是当有命令过来的时候会调用 RedisModuleCommandDispatcher, 然后它再来调用我们真正的处理函数。

void RedisModuleCommandDispatcher(client *c) {
    RedisModuleCommandProxy *cp = (void*)(unsigned long)c->cmd->getkeys_proc;
    RedisModuleCtx ctx = REDISMODULE_CTX_INIT;

    ctx.module = cp->module;
    ctx.client = c;
    // 调用真正的处理函数
    cp->func(&ctx,(void**)c->argv,c->argc);
    moduleHandlePropagationAfterCommandCallback(&ctx);
    moduleFreeContext(&ctx);
}

为什么不直接回调处理函数而要加一层代理? 这个留给你们自己思考吧...\n另外眼尖的小伙伴也可能注意到我们调用的是 RedisModule_CreateCommand, 为什么变成 RM_CreateCommand? 这是因为 Redis 做了一层重命名。内部实现上是 RM_ 开头, 对外暴露使用 RedisModule_, 这个是在 RedisModule_Init 里面做的。

2.3) 自定义数据结构​

我们也以具体模块(modules/hellotype.c)为例,

int RedisModule_OnLoad(RedisModuleCtx *ctx, RedisModuleString **argv, int argc) {
    REDISMODULE_NOT_USED(argv);
    REDISMODULE_NOT_USED(argc);

    if (RedisModule_Init(ctx,\"hellotype\",1,REDISMODULE_APIVER_1)
        == REDISMODULE_ERR) return REDISMODULE_ERR;

    RedisModuleTypeMethods tm = { 
        .version = REDISMODULE_TYPE_METHOD_VERSION,
        .rdb_load = HelloTypeRdbLoad,
        .rdb_save = HelloTypeRdbSave,
        .aof_rewrite = HelloTypeAofRewrite,
        .free = HelloTypeFree
    };  
    HelloType = RedisModule_CreateDataType(ctx,\"hellotype\",0,&tm);
    if (HelloType == NULL) return REDISMODULE_ERR
}

创建一个数据结构很简单，只要定义好几个回调函数即可。Redis 并不关心外部的数据是如何操作的(由命令决定)， 只需要关心数据要怎么来持久化以及释放即可。

更加详细的说明可以参照:

https://github.com/antirez/redis/blob/unstable/src/modules/TYPES.md

2.4) 其他​

其他一些东西由于篇幅没有细说。接口详细说明见:

https://github.com/antirez/redis/blob/unstable/src/modules/INTRO.md

3）总结​

我们可以看到 Redis 4.0 很简单就可以进行功能扩展，对 Redis 也没有侵入性。 同时模块是否稳定也直接影响到服务的质量。有了这个模块功能之后就可以支持很多不同业务的定制化数据结构，后面 Redis 的玩法也会越来越多。

另外除了模块功能之外，psync 优化，RDB-AOF 混合持久化以及一些命令的异步化还是很值得期待，接着也会来分析这几个新功能的实现。

参考链接:\nhttp://antirez.com/news/110\nhttp://antirez.com/news/106

", "url": "https://hulkdev.com/posts-redis-module", "title": "Redis 4.0 模块功能", "summary": "直到今天为止 (2017-01-17) Redis 4.0 已经发布了两个 rc 版本, 相比于上个版本(3.2)，这个版本的改动应该说是巨大的。主要有以下几个点:", "date_modified": "2017-01-19T00:00:00.000Z", "tags": [ "Redis" ] }, { "id": "posts-opensource-intro-consumergroup", "content_html": "

知道或者熟悉 kafka(不是写小说的那个卡夫卡)， 那么一定知道它有 producer 和 consumer 这两种角色。producer 用来生产消息，consumer 用来消费消息。

1) 可用性​

下面是来自维基百科的解释:

在一个给定的时间间隔内，对于一个功能个体来讲，总的可用时间所占的比例

比如我们以年为单位来量化一个服务的可用性。假设一年 365 天当中有 364 天服务是正常服务的，那么我们就说这个服务的可用性是 364/365(用计算器口算了一下约 99.72%)。

我们常用几个 9 来衡量一个服务的可用性，两个 9 就是 99.99%，三个 9 即 99.999%, 四个 9 即 99.9999% ... 以此类推。

可用性每年宕机时间
99.9%8 个小时
99.99%1 个小时
99.999%5 分钟
99.9999%30 秒

2）消费者的可用性​

一般来说 producer 是嵌入到业务程序，那么可用性就由业务程序来保证。而 consumer 一般就是以独立的程序存在，那么就要自己来保证。

所以想让 consumer 做到 99.99% 以上的可用性，意味着一年内服务挂掉的时间不能超过一个小时。假设我们没有实现一些高可用的机制，部分 consumer 在半夜挂了，而你(或者运维)刚好干完一些不可描述的事情之后倒头大睡而没有注意到报警，这个系统的可用性就达不到要求。

当前 scala, java, golang, c 版本的做法都是监听 group 的 consumer 列表，如果有 consumer 进入或者退出都会触发重新分配分区，把分区均衡到各个 consumer。所以理论上我们 php 版本也可以这样做。现在已有的开源里面有 kafka 和 zookeeper 的客户端扩展和依赖库，但没有实现自动平衡的逻辑（也可能是我没看到), 所以这部分需要自己来做。

3) 尴尬的 php​

这里必须先承认 php 是世界上最好的语言。

php 要实现 consumer 的高可用有三中选择:

第一种方案，因为我们线上 php 环境都是没有打开线程安全, 所以如果要使用这个扩展需要重新编译 php 核心代码并重启所有服务，这个基本是无法接受的。

第二种方案，可以不用重新编译 php, 性能好。但开发成本比较高，风险大。

第三种方案, 纯 php 实现，代码简单可控，但性能会比较差一些。

最后我们选择了第三种方案，单进程空跑(只拉消息不处理)的性能是 7w+/s， 这个是可以接受的。

4) 功能和代码说明​

github 地址: https://github.com/meitu/php-kafka-consumer

当前我们公司(美图)内部已经有不少业务已经在线上使用，当前版本已经比较稳定。

5）最后​

前一段时间发现线上 consumer 内存不断上升的情况，经排查，最终定位并验证是依赖库的 php-zookeeper 有内存泄漏。现在已经反馈以及合并到社区的 master, 具体见 pr。

如果使用 release(建议) 版本的 php-zookeeper, 需要手动 patch 这个 bug，否则会造成内存泄漏。

如果有问题或者任何意见，欢迎 issue 或者 pr。

", "url": "https://hulkdev.com/posts-opensource-intro-consumergroup", "title": "php consumergroup 介绍", "summary": "知道或者熟悉 kafka(不是写小说的那个卡夫卡)， 那么一定知道它有 producer 和 consumer 这两种角色。producer 用来生产消息，consumer 用来消费消息。", "date_modified": "2016-12-27T00:00:00.000Z", "tags": [ "PHP", "Kafka" ] }, { "id": "posts-intro-tcpkit", "content_html": "

一年即将过去，翻了一下博客发现更新频率比月经还来得稀疏，内疚到前列腺都萎缩了。

转入正题，本篇博客主要是分享一个自己日常用的比较多工具 tcpkit， 该工具用途主要是用来抓包和快速的分析数据包。

代码地址: git-hulk/tcpkit

1) 为什么要用它​

现在抓包不有 tcpdump 么? 分析包不是有很牛逼和方便的 wireshark 么? 当然我也不是闲到前列腺发炎，浪费时间造出这么个正方形的轮子。

造这个轮子的原因是这样，我们偶尔会遇到线上访问资源(redis, mc..) 出现耗时比较长的情况。如果是 tcpdump 可以用来抓包，但如果请求量很大又是偶发，我要这么知道哪个连接慢了? 这个时候 wireshark 也是帮不上忙的(因为它不知道哪个数据是请求，那个数据包是响应，也就没办法统计延时)。

这时候 tcpkit 就可以派上用场了。

2) 初见​

tcpkit 的初衷:「 让使用者可以想分析普通内存数据一样，可以写代码轻松的分析 udp/tcp 包 」

比如，我们默认的脚本就是 1 行 lua 代码就可以打印数据包内容，具体见 example.lua:

function process_packet(item)
    -- sync,ack 这种包长度为 0， 我们忽略掉
    if item.len > 0 then
        print(item.payload)
    end
end

每抓到一个数据包都会回调 process_packet, 然后把数据包内容传递进来，这样用户使用 lua 代码来定制分析的需求了。像上面的回调函数，就是什么都不分析就看看内容。

3) 上手​

那么问题来了，我要怎么玩这个东西呢。按照下面来就可以了...

$ git clone https://github.com/git-hulk/tcpkit.git /* 首先... 我得先拿到代码*/
$ cd tcpkit/src
$ make /* make install 是可选，要不要安装到标准的路径  */

本目录就生成了一个 tcpkit 的二进制文件，那么你就可以开始玩它了，姿势可以参考 README

主要的几个参数说明:

-i 指定抓包的网卡，默认是 any，就是所有网卡，但有些系统不支持

-p 指定抓包的端口

-s 如果是在客户端抓包，可以定向抓到某个服务的包

-S 指定处理脚本路径，固定回调 process_packet 这个函数

我们用 redis/mc 延时统计的脚本作为例子，要客户端看看请求 Redis 到返回耗时多长时间。

假设 redis ip: 192.168.1.1, 端口: 6379, 客户端: 192.168.1.2， 那么就就下面这样启动:

sudo ./tcpkit -s 192.168.1.1 -p 6379 -S ../scripts/redis_mc_monitor.lua

结果大概如下(ip端口是不对应的):

2020-02-06 23:01:39.706782 127.0.0.1:54484 => 127.0.0.1:6379 | 0.270 ms | GET test_key 
2020-02-06 23:01:39.712727 127.0.0.1:54540 => 127.0.0.1:6379 | 0.012 ms | PING 
2020-02-06 23:01:40.004345 127.0.0.1:54554 => 127.0.0.1:6379 | 0.187 ms | SET a b

第一列是响应的时刻，第二列和第三列分别是客户端和服务端连接的 ip 和端口，第三列是延时，最后一列是请求

如果跑在服务端，统计就是服务端处理的时间，耗时是包进来到出去的时间差。

NOTE: 在服务端，不需要指定 -s 这个 server ip, 只需要指定端口和脚本

4) 简单统计原理​

Q: 请求和响应要怎么对应起来?

A: 这个问题如果是变成怎么知道两个数据包是来自同一个连接就简单多了。

「 根据 tcp/ip 的ip和端口四元组就可以确定数据包是否同一个连接了 」

Q: 请求和响应怎么对应?

对于 Redis/mc 这种，对于同一个连接都是发出请求，然后必须等待响应才能下一个请求(不考虑 redis 的 pipeline)，那这个就好办了。

第一种情况: 在客户端抓包，如果源 ip 为本地ip, 那么说明这个数据包是发出去的，也就是请求数据包。反过来就是响应包。

第二种情况: 在服务端抓包，跟上面刚好相反，如果是源 ip 是本地 ip, 说明数据是出去的，也就是响应包。

那么只要知道是同一个连接，而且知道请求还是响应那么就可以统计延时了。上面说到如果是 redis pipeline 这种一来一往的数据包就要想其他方法了。

5) 脚本​

这个不需要深入了解 lua, 只要简单会应用就可以。tcpkit/scripts 目录提供了 rdis/mc/dns/kafka 的延时统计脚本，kafka 还有些问题，待修改。

如果是私有协议或者其他更多复杂的协议，需要自己实现。

6) END​

是否还有其他姿势？ 欢迎分享。

最后祝玩得开心。

代码地址: git-hulk/tcpkit

", "url": "https://hulkdev.com/posts-intro-tcpkit", "title": "tcpkit 介绍", "summary": "一年即将过去，翻了一下博客发现更新频率比月经还来得稀疏，内疚到前列腺都萎缩了。", "date_modified": "2016-11-17T00:00:00.000Z", "tags": [ "linux", "tool", "tcpkit" ] }, { "id": "posts-thinking-in-beanstalkd", "content_html": "

beanstalkd 是单机版本的任务队列服务, 任务队列跟消息队列在使用场景上最大的区别是： 任务之间是没有顺序约束而消息要求顺序(FIFO)，且可能会对任务的状态更新而消息一般只会消费不会更新。 类似 Kafka 利用消息 FIFO 和不需要更新(不需要对消息做索引)的特性来设计消息存储，将消息读写变成磁盘的顺序读写来实现比较好的性能。而任务队列需要能够任务状态进行更新则需要对每个消息进行索引，如果把两者放到一起实现则很难实现在功能和性能上兼得。在美图内部选型上，如果是异步消息模型一般会选择消息队列，比如类似日志上报，抢购等。而对于需要延时/定时下发或者修改状态任务则是使用任务队列。

比如在以下几种场景会使用任务队列:\n定时任务，如每天早上 8 点开始推送消息，定期删除过期数据等\n任务流，如自动创建 Redis 流程由资源创建，资源配置，DNS 修改等部分组成，使用任务队列可以简化整体的设计和重试流程\n重试任务，典型场景如离线图片处理

目前开源任务队列并不多, 比如原生支持任务队列语义比较知名只有类似 disque, beanstalkd。 公司部分场景比较适合引入任务队列，所以我们从整体上来看当前已有的一些开源产品的设计和实现。

1) 初识​

先从几个大的层面来看一下 beanstalkd，再来看内部的实现细节:

  1. 协议，类 Memcached 协议, 非二进制安全
  2. 全内存, 可开启 binlog, 断电从 binlog 恢复数据
  3. 单线程, 使用 epoll/kqueue 来实现事件机制

2) 几个概念​

3) 状态迁移​

一个 job 的状态可能是 DELAYED, READY, RESERVED, BURIED 其中之一，状态之间可以互相迁移。

   //------------------- 状态图来自官方文档 -------------------//
   
   put with delay               release with delay
  ----------------> [DELAYED] <------------.
                        |                   |
                 kick   | (time passes)     |
                        |                   |
   put                  v     reserve       |       delete
  -----------------> [READY] ---------> [RESERVED] --------> *poof*
                       ^  ^                |  |
                       |   \\  release      |  |
                       |    `-------------'   |
                       |                      |
                       | kick                 |
                       |                      |
                       |       bury           |
                    [BURIED] <---------------'
                       |
                       |  delete
                        `--------> *poof*

3.1 生产​

生产者通过 PUT 命令来产生一条消息, 命令格式如下:

put <pri> <delay> <ttr> <bytes>\\r\\n
<data>\\r\\n
  1. delay = 0，进入就绪(READY)队列, 可以直接被消费。
  2. dealy > 0, 进入延时队列(DELAYED), 等到延时时间到了之后自动迁移就绪队列。

3.2 消费​

消费者通过 RESERVE 命令从就绪队列取出一个任务, 格式如下:

reserve\\r\\n

任务状态会从 READY 变为 RESERVED(预定)，其他人就无法获取。 PUT 产生消息的时候，携带了 ttr(time to run)，如果这个时间内，消费者没有发送 delete, release 或者 buried 命令。 任务会自动回到 READY 状态，其他人可以继续获取。

我们从状态图中可以看到：

  1. 消费者返回 delete 命令，这个任务就从此消失
  2. 消费者返回 buried 命令, 这个任务就进入休眠状态
  3. 消费者返回 release 命令或者不返回，就回到 READY/DELAYED 状态，可以重新被消费

休眠(BURIED)状态的任务，可以通过 kick 命令让任务回到 READY 队列中去。

具体的协议请移步官方文档: https://github.com/kr/beanstalkd/blob/master/doc/protocol.txt

4) 内部实现​

4.1) tube​

上面说到 beanstalkd 可以根据消息类型或者业务拆分成多个通道(tube), 用户可以使用 use tube_name 来进行切换，如果没有这个 tube 就直接创建。beanstalkd 内部使用一个数组来保存所有的 tubes, 结构见 struct ms。

我们下面来看一下 tube 结构里面有哪些东西:

struct tube {
    uint refs;  // tube 当前被引用的次数                        
    char name[MAX_TUBE_NAME_LEN]; // tube 名称, 最长 200byte
    Heap ready; // 保存就绪队列的最小堆                        
    Heap delay; // 保存延时队列的最小堆                       
    struct ms waiting; // 正在使用 tube 的连接    
    struct stats stat; // tube 对应的统计项
    uint using_ct; // tube using 使用次数   
    uint watching_ct; // 被watch的次数
    int64 pause; // tube 是否整个被延时  
    int64 deadline_at; // tube 延时截止时间 
    struct job buried; // buried 队列
};

这里可以看到每个 tube 里面都包含了就绪, 延时和休眠三种队列。我们上面说了每个 job 的状态可能是 DELAYED/READY/RESERVED/BURIED， 那么 RESERVED 状态的 job 是保存在那里呢？ 每个连接结构里面会有一个 RESERVED 链表用来保存当前连接预取的所有 job。

其中 READY/DELAYED 队列实现都是最小堆，而 BURIED/RESERVED 是普通的链表，job 根据不同的状态会在这四个队列中迁移。

4.2) 最小堆​

READY/DELAYED 队列采用最小堆，下面分别是两个队列的比较方法:

int
job_pri_less(void *ax, void *bx)
{
    job a = ax, b = bx; 
    // 最小堆比较方法, 先比较优先级再比较 id
    if (a->r.pri < b->r.pri) return 1;
    if (a->r.pri > b->r.pri) return 0;
    return a->r.id < b->r.id;
}

先比较优先级，再比较 job id，所以当我们想实现优先级队列的时候，只需要设置优先级。pri 值越小优先级越高。如果我们想利用 beanstalkd 作为普通的先进先出队列，把优先级都设置为一样即可，消费的时候就会根据 job id 出队。

int
job_delay_less(void *ax, void *bx)
{
    job a = ax, b = bx; 
    if (a->r.deadline_at < b->r.deadline_at) return 1;
    if (a->r.deadline_at > b->r.deadline_at) return 0;
    return a->r.id < b->r.id;
}

先比较延时截止时间，再比较 job id。

4.3) 状态迁移​

再获取网络事件之前，都会调用 prottick 方法来做一些常规的的状态迁移。

void
srvserve(Server *s)
{
    ...
    for (;;) {
        // 实现一些状态迁移检查
        period = prottick(s);

        // 获取下一个处理的事件
        int rw = socknext(&sock, period);
        if (rw == -1) {
            twarnx(\"socknext\");
            exit(1);
        }

        // 回调处理
        if (rw) {
            sock->f(sock->x, rw);
        }
    }
    ...
}

int64
prottick(Server *s)
{
    ...
    // 这个循环检查延时队列是否有 job 截止时间到了，是的话迁移到就绪队列
    // 如果大量的 delay 变成ready 会导致其他请求得不到响应而超时
    now = nanoseconds();
    while ((j = delay_q_peek())) {
        d = j->r.deadline_at - now;
        if (d > 0) {
            period = min(period, d);
            break;
        }
        // 返回延时队列第一个
        j = delay_q_take();
        // job 进入就绪处理
        r = enqueue_job(s, j, 0, 0);
        // OOM?
        if (r < 1) bury_job(s, j, 0); /* out of memory, so bury it */
    }
    ...
}

prottick 里面除了检查延时队列，还检查整个 tube 的延时截止时间是否已经到以及连接是否等待超时等等。

4.3) job 查找​

为了快速查找一个 job, 内部采用 hashtable 来存放 job。

// 根据 id 查找对应的任务
job
job_find(uint64 job_id)
{
    job jh = NULL;
    // 根据job id 取模获取 bucket 下标
    int index = _get_job_hash_index(job_id);

    // 链表查找
    for (jh = all_jobs[index]; jh && jh->r.id != job_id; jh = jh->ht_next);

    return jh; 
}

当 hashtable 元素超过 bucket 的 4倍的时候，会进行 Rehash 来扩容。

static void
store_job(job j)
{
    ...
    /* accept a load factor of 4 */
    // 一次性 rehash 可能导致访问毛刺点
    if (all_jobs_used > (all_jobs_cap << 2)) rehash();
}

这里有两个问题:

  1. 当前只实现了扩容没有缩容，这个有人提了 pr, 后续版本应该会解决
  2. 一次性 rehash, hashtable 数据比较多的时候，迁移时间会比较久，产生访问毛刺点

5) 一些问题​

从代码层面来看，beanstalkd 通过几千行 C 代码实现了一个优先级/延时队列，这个实在是很 cool，但问题还是有不少。

  1. 无最大内存控制, 如果有消息堆积或者业务使用方式有误，而导致内存暴涨拖垮机器
  2. 上面说的 Rehash 导致访问变长，甚至产生大量连接超时
  3. 部分操作无时长控制，可能导致大量连接超时。 如事件查询之前的常规检查方法 prottick， 以及 kicked 命令无控制 count 大小。
  4. 不少代码不够精简， 比如回放时读取 job 的方法，两个不同版本读取方法实际上差别不大
  5. 跟 mc 类似，没有 master-slave 方式，需要自己解决单点问题

6) END​

如果是有优先级/延时任务的需求的话, beanstalkd 是个不错选择。如果作为常规的先进先出队列来说，以性能和稳定来说 kafka/redis 会是更好的选择，redis 本身也是全内存，队列操作 O(1), 而 benastalkd 是 log(n)。redis 也更加成熟和稳定，同时支持本地持久化和主从。

另外有一个加分项是 beanstalkd 作者本身比较活跃，之前提了一个 pr, 当天就得到回馈，这也是作为开源项目选择一个很重要的因素。

", "url": "https://hulkdev.com/posts-thinking-in-beanstalkd", "title": "beanstalkd 设计与实现", "summary": "beanstalkd 是单机版本的任务队列服务, 任务队列跟消息队列在使用场景上最大的区别是： 任务之间是没有顺序约束而消息要求顺序(FIFO)，且可能会对任务的状态更新而消息一般只会消费不会更新。 类似 Kafka 利用消息 FIFO 和不需要更新(不需要对消息做索引)的特性来设计消息存储，将消息读写变成磁盘的顺序读写来实现比较好的性能。而任务队列需要能够任务状态进行更新则需要对每个消息进行索引，如果把两者放到一起实现则很难实现在功能和性能上兼得。在美图内部选型上，如果是异步消息模型一般会选择消息队列，比如类似日志上报，抢购等。而对于需要延时/定时下发或者修改状态任务则是使用任务队列。", "date_modified": "2016-04-16T00:00:00.000Z", "tags": [ "Queue", "Beanstalkd" ] }, { "id": "posts-getaddressinfo-cause-unbalance", "content_html": "

DBA 发现同一组 Redis 从库中有实例 QPS 比较高，对比发现只是其中一个从库偏高而其他从库是正常的，分布如下:

\"image\"

那么问题就是: 「为什么会 QPS 不均匀?」, 由于我们先上 php 业务都是长连接，QPS 不均匀应该是连接数不均带来的。然后让运维大侠统计了一下四个实例的连接数，发现确实请求量跟连接数是成线性正相关的。

2) 连接数为何不均匀?​

因为这四个实例是通过域名来访问，理论上连接数应该是要比较均匀(DNS ip 轮循)。\n接着当然是统计多出来的连接数是来自哪些 ip。使用 lsof 或者 redis 的 client list 都可以得到。

为什么要统计 ip 呢​

  1. 确定是不是有业务有固定 ip 直连导致
  2. 确定是不是所有业务机器连接资源不均匀还是个别机器

统计完发现，第一个实例比其他实例多出来的 ip, 是来自部分业务机器。

192.168.7.213
192.168.7.218
192.168.7.217
192.168.7.216

而且发现这几个 ip 只连第一个实例。 这说明连接数不均匀是这几个 ip 固定连接第一个实例导致的。

后面就围绕 DNS 和 php 连接机制展开排查

3) 排查​

3.1) DNS 返回问题？​

第一件事情先排除是不是 DNS 返回结果不正确导致。使用 nslookup 查看，发现结果列表每次都会进行 ip 轮循，所以排除 DNS 返回不正确导致。那么就回到是不是 php 使用姿势的问题。

3.2) gethostbyname 导致的?​

既然 DNS 返回结果没有问题，那么很可能就是 php 内部通过域名转换 ip 时固定返回某一个 ip。因为没有去看 phpredis 的实现，所以先假设是通过 gethostbyname 来获取ip, 这个很容易验证。 通过执行下面代码，发现结果是会进行 ip 轮循。

php -r 'var_dump(gethostbyname(\"\"s2000.redis.com.cn.xxx\"))'

到这里因为 gethostbyname 没有问题，那么就猜测是不是使用其他的方式获取ip?

因为业务方在 phpredis 连接资源时，是直接使用域名。而 phpredis 会使用 php 源码的 php_stream_xport_create 进行建立连接。而这个函数在建立连接，是通过 php_network_getaddresses 来获取到 ip 列表, 然后拿到列表的第一个进行连接。

这个跟观察到的只会连接到同一个ip的规律是一致的，所以我们只要来看他是通过什么方法获取 ip 列表。

3.3) getaddrinfo 的锅?​

我们看到 php_network_getaddresses 实现是这样的(见php-src/main/network.c):

 PHPAPI int php_network_getaddresses(const char *host, int socktype, struct sockaddr ***sal, char **error_string TSRMLS_DC)
 ...
  #if HAVE_GETADDRINFO
    if ((n = getaddrinfo(host, NULL, &hints, &res))) {  
        ...
    }
  #else
    host_info = gethostbyname(host); 
    ...
  #endif

使用 HAVE_GETADDRINFO 来决定使用 getaddrinfo 还是 gethostbyname 来获取ip, 这个选项是在 configure 阶段，通过判断操作系统是否支持 getaddrinfo 来自动开启。因为我们线上机器都支持这个函数，而我们也验证过 gethostbyname 返回结果是正常的。

到了这里就是 getaddrinfo 背上了这个锅

这个验证也很简单，直接调用 getaddrinfo 看返回结果, 代码如下:

    n = getaddrinfo(\"s2000.zw.rediscounter.m.com\", NULL, &hints, &res);
    if (!res) return;
    
    do {
        if (res->ai_family == AF_INET)  {
            sinp = (struct sockaddr_in *)res->ai_addr;
            addr = inet_ntop(AF_INET, &(sinp->sin_addr), abuf,INET_ADDRSTRLEN);
            printf(\"%s\\n\", addr);
        }
    } while((res = res->ai_next) != NULL);

然后拿到有问题的机器跑了一下，果然取到的 ip 列表是固定的，然而在那批没问题的机器上拿到 ip 列表是会进行轮循。所以已经确定是 getaddrinfo 函数导致。

4) 尝试解决​

4.1) glibc 版本问题？​

现在的问题就是为什么同一函数在不同机器上面表现不一样，所以先检查内核版本和 glibc 版本是否一致。发现有问题的这批机器 glibc 版本比较低，所以有理由怀疑是否为老版本的 bug (后面万万没想到是否 feature..)。 所以就打算先升级一台有问题的机器来看看，然后再来仔细对比实现。

不幸的是升级后发现问题仍然存在。

\"image\"

4.2) rfc3484_sort 惹的祸​

实在没办法只能去翻 glibc 的代码, 发现这个函数确实是会对返回的 ip 列表进行排序，具体实现见 glibc-2.20/sysdeps/posix/getaddrinfo.c。

qsort_r (order, nresults, sizeof (order[0]), rfc3484_sort, &src);

排序算使用的是 rfc3484_sort, 内部比较方法应该是根据 rfc3484 的特定规则做比较，直接看会浪费时间，直接搜索找到对应 rfc 说明( http://www.ietf.org/rfc/rfc3484.txt)。

这个函数是为了解决 ipv6 多播地址绑定到单网卡的问题，函数会从 rules 1-10 逐条比较。rules 10 是保持 DNS 返回顺序，也就是我们希望的。 篇幅问题这里不在细说规则，返回结果因为算法固定，所以顺序也不会改变。

5) 真正解决​

  1. 业务连接资源使用 gethostbyname 获取ip, 而不是使用 php 源码实现的规则。
  2. 关闭 getaddrinfo 排序算法

因为第一种方案需要业务方修改代码(尽管只有一两行)， 所以我们选择第二种方案。因为从代码层面很难看出来哪个参数可以关闭。后面搜索找到相应的讨论(问题缩小就能快速找到解决方法)，快速的解决方法是关闭 ipv6, 当然前提是线上服务不能有使用到这个特性。

https://groups.google.com/forum/#!topic/consul-tool/AGgPjrrkw3g

到这里就回想到，为什么部分机器有问题而一部分没有问题，立即对比 ipv6 的配置。发现有问题的机器没有关闭 ipv6，而没有问题的机器是关闭的。通过跟运维也了解到，线上应该默认会关闭 ipv6, 而这批老机器漏了关闭。

6) 验证​

直接关闭这批机器的 ipv6 配置:

root$ echo 1 > /proc/sys/net/ipv6/conf/all/disable_ipv6

观察这批机器的 redis 资源连接，开始有连到其他 redis 资源。因为线上 php-fpm 使用长连接，所以需要等到进程重启才会重新连接，所以需要等一段时间才会完全均匀。

过了一会，多个 Redis 访问量和连接数终于恢复均匀，问题初步解决。

\"image\"

7）END​

现在虽然通过关闭 ipv6 解决这个问题，但后续可能也会使用到 ipv6 而再次踩坑。建议后续 php 连接资源采用 gethostbyname 手动获取ip。

另外还有一个细节还没完全深入的是 ipv6 选项如何影响 rfc3483_sort 算法的，需要进一步跟进，彻底搞定。

", "url": "https://hulkdev.com/posts-getaddressinfo-cause-unbalance", "title": "getaddressinfo 引发的血案", "summary": "DBA 发现同一组 Redis 从库中有实例 QPS 比较高，对比发现只是其中一个从库偏高而其他从库是正常的，分布如下:", "date_modified": "2016-03-27T00:00:00.000Z", "tags": [ "linux", "glibc" ] }, { "id": "posts-how-oom-killer-works", "content_html": "

作为一个不合格的开发人员多多少少都被 OOM(Out of memory) x 过，只是一般大家对于为什么被选中，可能没太考究。

简单来说之所以会出现 OOM, 就是已分配的虚拟内存大于物理内存和 Swap 分区大小，导致需要内存无法分配。如果 overcommit = 2, 在申请虚拟内存时，如果超过限制的内存比例 + Swap 空间会直接返回失败，只要分配虚拟内存不超过物理内存，也就不会有 OOM。

2) 进程选择​

既然无法分配内存，就有两种下面的两种选择:

  1. 向申请内存报告申请内存失败
  2. 选择一个杀掉其他的进程来释放内存

内核 2.4 版本之前是第一种做法(走在路上听别人说的), 后面的内核版本才采用第二种。我们这里要来看的是第二种，原因很简单，因为第一种做法没什么好看的...

下面的代码基于内核 2.6.32, 代码在 arch/不同型号/mm/fault.c 和 mm/oom_kill.c:

我们分配物理内存的时候是通过缺页中断来实现的，然后会调用 do_page_fault ，如果内存不足就会通过 mm_fault_error 来处理，调用链如下:

out_of_memory->pagefault_out_of_memory->__out_of_memory
->select_bad_process->badness

select_bad_process 调用 badness 来计算每个进程的得分（范围 0-1000），然后干掉 score 最高的进程。每个进程的 score 我们通过 /proc/pid/oom_score 来查看。我们下面来看这个 score 是如何计算，主要是下面几个纬度:

unsigned long badness(struct task_struct *p, unsigned long uptime)
{
    ...
    // 这个 oom_adj 值是从 /proc/pid/oom_adj 获取
    // 用户可以通过控制 oom_adj 来控制 score
    int oom_adj = p->signal->oom_adj;
    ...
    
    // 系统总内存大小作为基础分数
    points = mm->total_vm;
    
    if (p->flags & PF_OOM_ORIGIN)
        return ULONG_MAX;
    
    // 如果 fork 的进程子进程也太多子进程被选到的概率也比较大。
    list_for_each_entry(child, &p->children, sibling) {
        task_lock(child);
        if (child->mm != mm && child->mm)
            points += child->mm->total_vm/2 + 1;
        task_unlock(child);
    }
    
    thread_group_cputime(p, &task_time);
    // 进程用户空间消耗的 cpu 分片数
    utime = cputime_to_jiffies(task_time.utime);
    // 进程系统消耗的 cpu 分片数
    stime = cputime_to_jiffies(task_time.stime);
    cpu_time = (utime + stime) >> (SHIFT_HZ + 3);
    
    // 计算启动时间
    if (uptime >= p->start_time.tv_sec)
        run_time = (uptime - p->start_time.tv_sec) >> 10;
    else
        run_time = 0;
    
    // 消耗 CPU 越多的进程，降低 score
    if (cpu_time)
        points /= int_sqrt(cpu_time);
    // 根据启动时间降低 score, 所以最新启动的进程最可能被杀
    if (run_time)
        points /= int_sqrt(int_sqrt(run_time));
    
    // 降低 root 用户启动的进程的 score
    if (has_capability_noaudit(p, CAP_SYS_ADMIN) ||
        has_capability_noaudit(p, CAP_SYS_RESOURCE))
        points /= 4;
    
    if (!has_intersects_mems_allowed(p))
        points /= 8;
     
     if (oom_adj) {
        if (oom_adj > 0) {
            if (!points)
                points = 1;
            points <<= oom_adj;
        } else
            points >>= -(oom_adj);
    }
    return points;
}

3) 总结​

从整体来看，占用内存越大，非CPU消耗刑，非 Root 启动以及新启动的进程更加容易被选中。而用户可以通过调整 /proc/$pid/oom_adj 来调整进程的优先级。

", "url": "https://hulkdev.com/posts-how-oom-killer-works", "title": "oom killer 实现", "summary": "作为一个不合格的开发人员多多少少都被 OOM(Out of memory) x 过，只是一般大家对于为什么被选中，可能没太考究。", "date_modified": "2016-03-26T00:00:00.000Z", "tags": [ "linux", "mmeory" ] }, { "id": "posts-overcommit-memory", "content_html": "

春节前几天运维大侠说要扩容 Redis 从库但同步一直失败，看日志发现在做 bgsave 的时候一直失败。 日志如下:

[41738] 04 Feb 11:16:39.859 * Full resync requested by slave.
[41738] 04 Feb 11:16:39.859 * Starting BGSAVE for SYNC
[41738] 04 Feb 11:16:39.860 # Can't save in background: fork: Cannot allocate memory
[41738] 04 Feb 11:16:39.860 * Replication failed, can't BGSAVE

从日志可以看到 fork 的时候内存分配失败导致 bgsave 无法成功，那就是可用内存不足?

使用 info memory 看了一下实例使用内存， 差不多用了 8G:

used_memory:8045067888
used_memory_human:7.49G
used_memory_rss:8216522752
used_memory_peak:50615269608
used_memory_peak_human:47.14G

然后用 free -m 看到系统空闲页加上 pagecache 也有 21G，这个空闲内存远大于实例使用的 8G 呀，为什么会 fork 失败呢？

使用 top 发现这个 Redis 实例虚拟内存使用了 48.7G, 常驻内存使用是 7.6G。

\"img\"

2) 那么问题来了​

Q1. Redis 统计的虚拟内存为什么占用这么多?

从现象来看是峰值分配了这么多(见 peak_memory)。 但在内存释放的时候，物理内存释放而虚拟内存无法收缩。这个跟内存分配有关, 当前 Redis 默认是用的是 jemalloc。

在 github 上面提了一个 issue 说这个问题， Redis 作者也大概是这个意思。至于为什么虚拟内存无法收缩的原因，有待进一步研究。

Q2. fork 是根据虚拟内存来检查内存是否够用?

显然是的。因为如果是根据物理内存，fork 是可以成功的。那其实剩余的系统内存是足够的，而我需要的内存并没有这么大，有什么办法可以让进程继续 fork 么？ 答案就是把 vm.overcommit_memory 设置为 1。

3） 解决方案​

vm.overcommit_memory 用来控制在 fork 进程时用什么姿势来检查内存是否够用。 Redis 在实例启动的时候给出了提示信息。

WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. 
To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf 
and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.

vm.overcommit_memory 取值是 0, 1, 2, 默认是 0。 具体数值的意义可参考下面的文档，后面会结合代码来说明。

https://www.kernel.org/doc/Documentation/vm/overcommit-accounting

4) Overcommit memory​

我们具体从内核代码(Linux-2.6.32)来看这个参数如何在 fork 进程的时候进行内存校验。

#define OVERCOMMIT_GUESS        0
#define OVERCOMMIT_ALWAYS       1
#define OVERCOMMIT_NEVER        2

我们在程序执行 fork() 的时候，会通过系统调用中断切换到内核态，再调用 sys_fork。

下面是 fork 进程时，内核的系统调用链:

sys_fork -> copy_mm -> dup_mm -> dup_mmap -> 
security_vm_enough_memory -> cap_vm_enough_memory -> __vm_enough_memory

最后调用 __vm_enough_memory 进行内存检查，我们重点来看这个函数。

int __vm_enough_memory(struct mm_struct *mm, long pages, int cap_sys_admin) {
    ...
    /*    
     * Sometimes we want to use more memory than we have
     */
    // OVERCOMMIT_ALWAYS = 1, 什么都不检查直接返回
    if (sysctl_overcommit_memory == OVERCOMMIT_ALWAYS)
        return 0;
    if (sysctl_overcommit_memory == OVERCOMMIT_GUESS) {
        unsigned long n;
        
        // 剩余容量 = page cache使用的页 + 空闲swap + 可回收 slab + 系统空闲页
        free = global_page_state(NR_FILE_PAGES);
        free += nr_swap_pages;
        free += global_page_state(NR_SLAB_RECLAIMABLE);
        
        // root 如果是非 root 用户需要保留 3%
        if (!cap_sys_admin)
            free -= free / 32;
            
        // 如果空闲的页足够直接返回
        if (free > pages)
            return 0;
            
        // 计算系统空闲页比较耗时，所有上面 3 种空闲已经足够就不计算。
        n = nr_free_pages();
       
        // 去掉一些系统保留页
        if (n <= totalreserve_pages)
            goto error;
        else
            n -= totalreserve_pages;
        
        // root 如果是非 root 用户需要保留 3%
        if (!cap_sys_admin)
            n -= n / 32;
        free += n;
       
        if (free > pages)
            return 0;

        goto error;
    }
    
    // 上面两个分支分别是值为 1 和 0 的情况，下面则是值为 2 的判断条件
    // 因为我们计算的是 normal page, 所以计算允许使用的内存需要扣掉 huge page
    // sysctl_overcommit_ratio 系统控制的比例参数
    allowed = (totalram_pages - hugetlb_total_pages())
            * sysctl_overcommit_ratio / 100;

    //非root 用户保留 3%
    if (!cap_sys_admin)
        allowed -= allowed / 32;
    // 加上 swap 空闲页
    allowed += total_swap_pages;
    
    // 防止单进程占用过多内存，需要保留 3% 给其他进程
    if (mm)
        allowed -= mm->total_vm / 32;

    if (percpu_counter_read_positive(&vm_committed_as) < allowed)
        return 0;
error:
    vm_unacct_memory(pages);

    return -ENOMEM;
}

从代码层面来看：

  1. overcommit_memory = 1, 不检查，有锅自己背。
  2. overcommit_memory = 0，检查当前进程需要的虚拟内存 < (当前剩余的物理 + swap分区)
  3. overcommit_memory = 2, 检查整个系统已经分配的内存 < (物理内存*允许比例 + swap分区)

5） END​

调整系统参数还是需要谨慎再谨慎，在没有详细查看官方文档以及全面了解参数对系统的影响的时候，切勿手贱随意调整。

", "url": "https://hulkdev.com/posts-overcommit-memory", "title": "谈谈 overcommit memory", "summary": "春节前几天运维大侠说要扩容 Redis 从库但同步一直失败，看日志发现在做 bgsave 的时候一直失败。 日志如下:", "date_modified": "2016-02-15T00:00:00.000Z", "tags": [ "linux", "memory" ] }, { "id": "posts-how-php-check-tcp-liveness", "content_html": "

长连接可以减少建立连接的过程, 使用长连接可以提高服务的性能。php 很多扩展都支持长连接，如 redis, memcache, mysql 的主流扩展都支持。

我们知道长连接就是一次建立连接，使用之后不会马上释放，而是把这个连接放到连接池。那么引发的一个问题就是，我们下次使用时如何知道这个连接是否已经被关闭。

我们来看看 phpredis 是如何来判断，连接是否可用。 phpredis 检查的函数在 library.c 的 redis_check_eof 的方法，而这个方法调用的是 php 内部的方法 php_stream_eof, 我们来看这个方法的具体实现。

PHPAPI int _php_stream_eof(php_stream *stream TSRMLS_DC)
{
    // 如果有数据未读取，说明 socket 还是可用
    if (stream->writepos - stream->readpos > 0) {
        return 0;
    }

    // 咦? 这里通过 php_stream_set_option 来检查
    if (!stream->eof && PHP_STREAM_OPTION_RETURN_ERR ==
            php_stream_set_option(stream, PHP_STREAM_OPTION_CHECK_LIVENESS,
            0, NULL)) {
        stream->eof = 1;
    }

    return stream->eof;
}

判断socket 是否可用, 有两个条件:

  1. writepos > readpos, 说明还有数据未读, 连接正在使用中
  2. php_stream_set_option 通过 PHP_STREAM_OPTION_CHECK_LIVENESS 选项来判断

解析来看看 php_stream_set_option 是如何实现的:

PHPAPI int _php_stream_set_option(php_stream *stream, int option, int value, void *ptrparam TSRMLS_DC)
{
    int ret = PHP_STREAM_OPTION_RETURN_NOTIMPL;

    if (stream->ops->set_option) {
        ret = stream->ops->set_option(stream, option, value, ptrparam TSRMLS_CC);
    }
    ...
}

这个函数调用的是 stream 的 set_option 方法，我们知道 php 的stream 是一类文件操作的抽象。在 php 里面的 tcp, udp，socket, 普通文件, 文件流等都是 stream, 只是他们实现的方法各有差异，我们这里只关注 tcp 的实现：

php_stream_ops php_stream_socket_ops = {
    php_sockop_write, php_sockop_read,
    php_sockop_close, php_sockop_flush,
    \"tcp_socket\",
    NULL, /* seek */
    php_sockop_cast,
    php_sockop_stat,
    php_tcp_sockop_set_option,
};

对于 socket 的stream, 它的 set_option 就是 php_tcp_sockop_set_option, 实现如下:

if (php_pollfd_for(sock->socket, PHP_POLLREADABLE|POLLPRI, &tv) > 0) {
    if (0 >= recv(sock->socket, &buf, sizeof(buf), MSG_PEEK) && php_socket_errno() != EWOULDBLOCK) {
            alive = 0;
    }
}

这里我们看到, 检查一个 socket 是否存活, 是通过 poll 来查询 socket 的可读些状态。然后使用 recv 来判断 socket 是否关闭，或者出错。

1. recv = 0 时, 说明连接已经关闭
2. recv < 0 且  errno != EWOULDBLOCK 时，说明 socket 出错了。

部门细心的小伙伴，发现了这个判断条件有一个小 bug。 如果上一次查询结果的 errno = EWOULDBLOCK，因为只有异常才会覆盖 errno，所以recv = 0时，也会认为 socket 是存活的。

php_pollfd_for 的实现也有一些小技巧：

static inline int php_pollfd_for(php_socket_t fd, int events, struct timeval *timeouttv)
{
    php_pollfd p;
    int n;

    p.fd = fd;
    p.events = events;
    p.revents = 0;
    
    n = php_poll2(&p, 1, php_tvtoto(timeouttv));

    if (n > 0) {
        return p.revents;
    }

    return n;
}

php_poll2 第二个参数是 1， poll 只会查询一个 fd, poll 不会引入查询多个无用 fd 的问题。 第三那个参数在 check_liveness 时，是设置为 0, poll 也不会阻塞。

", "url": "https://hulkdev.com/posts-how-php-check-tcp-liveness", "title": "php 如何检查 TCP 连接是否关闭", "summary": "长连接可以减少建立连接的过程, 使用长连接可以提高服务的性能。php 很多扩展都支持长连接，如 redis, memcache, mysql 的主流扩展都支持。", "date_modified": "2015-08-08T00:00:00.000Z", "author": { "name": "hulk" }, "tags": [ "PHP", "TCP" ] } ] }