使用.NET简单实现一个Redis的高性能克隆版（六）

译者注

该原文是Ayende Rahien大佬业余自己在使用C# 和 .NET构建一个简单、高性能兼容Redis协议的数据库的经历。

首先这个"Redis"是非常简单的实现，但是他在优化这个简单"Redis"路程很有趣，也能给我们在从事性能优化工作时带来一些启示。

原作者：Ayende Rahien

原链接：

https://ayende.com/blog/197569-B/high-performance-net-building-a-redis-clone-skipping-strings

另外Ayende大佬是.NET开源的高性能多范式数据库RavenDB所在公司的CTO，不排除这些文章是为了以后会在RavenDB上兼容Redis协议做的尝试。大家也可以多多支持，下方给出了链接

RavenDB地址：https://github.com/ravendb/ravendb

构建Redis克隆版-字符串处理

我克隆版Redis目前代码中高成本的地方就是字符串的处理，下面的分析器图表实际上有一些误导：

字符串占用了运行时的12.57%的时间，另外就是GC Wait, 我们需要清理掉这些开销。这意味着我们之前写的代码是非常低效的。

我们的测试场景现在也只涉及 GET 和 SET 请求，没有删除、过期等。我提到这一点是因为我们正在考虑用什么来替换字符串。

最简单的选择是用字节数组替换它，但它仍然是托管内存，并且会产生与 GC 相关的成本。我们可以池化这些字节数组，但是我们还有一个重要的问题要回答，我们如何知道什么时候不再使用池化的数组，也就是说，什么什么把它归还到池中？

考虑以下一组事件流程:

在上面的例子中，线程2访问了值缓冲区，但是在Time-3中我们使用SET abc命令替换了原来的数据，导致线程2访问的不再是原来的数据。

我们需要找一个方法，将值缓冲区保留到没有任何对象引用它的时候，另外在销毁它时我们要将它归还到池中。

我们可以通过手动管理内存的方式来实现这个，这是很可怕的。实际上我们可以使用一些不同的方式，比如利用GC来达到我们的目的。



public class ReusableBuffer

{

    public byte[] Buffer;

    public int Length;

    public Span<byte> Span => new Span<byte>(Buffer, 0, Length);

    public ReusableBuffer(byte[] buffer, int length)

    {

        Buffer = buffer;

        Length = length;

    }

    public override bool Equals(object? obj)

    {

        if (obj is not ReusableBuffer o)

            return false;

        return o.Span.SequenceEqual(Span);

    }

    public override int GetHashCode()

    {

        var hc = new HashCode();

        hc.AddBytes(Span);

        return hc.ToHashCode();

    }

    // 关键是这里，声明一个析构函数

    // 当GC需要释放它的时候会调用

    ~ReusableBuffer()

    {

        ArrayPool<byte>.Shared.Return(Buffer);

    }

}

想法很简单。我们有一个持有缓冲区的类，当 GC 注意到它不再被使用时，它将把它的缓冲区归还到池中。这个想法是我们依靠 GC 来为我们解决这个(真正困难的)问题。虽然这会将一些成本转移到终结器，但是目前来说我们不必担心这个问题。不然，你就得经历很多困难来编写手动管理内存的代码。

ReusableBuffer类还实现了GetHashCode()/Equals()，它允许我们将其用作字典中的Key。

现在我们有了键和值的后台存储，让我们看看如何从网络读写。现在我将回到 ConcurrentDictionary 实现，一次只处理一个事情。

以前，我们使用 StreamReader/StreamWriter 来完成工作，现在我们将使用 System.IO.Pipelines 中的 PipeReader/PipeWriter。这将使我们能够轻松地直接处理原始字节数据，并且这是为高性能场景设计的。

我编写了两次代码，一次使用可重用的缓冲区模型，一次使用 PipeReader/PipeWriter 并分配字符串。我惊讶地发现，我的可重用缓冲区的性能差距只有字符串实现的1% (简单得多)。顺便说一句，那是1%的错误方向。

在我的机器上，基于可重用的缓冲区是16.5w/s，而基于字符串的系统是每秒16.6w/s。

下面是基于可重用缓冲区的完整方法源代码。比较一下，这是基于字符串的。基于字符串的代码行比基于字符串的代码行短50%左右。

基于可重用缓冲区：https://gist.github.com/ayende/f6263d5ddd331a7f8263ef892b45f526
基于字符串：https://gist.github.com/ayende/bc52b3cbdb6d5ebd8fa00ac5d014a876

我猜测是因为我们这个场景的分配模式非常适合GC所做的那种启发式处理。我们要么有长期对象(在缓存中)，么有非常短期的对象。

值得指出的是，网络中命令的实际解析并不使用字符串。只有实际的键和值实际上被转换为字符串。其余部分使用原始字节数据。

下面是对字符串版本的代码进行分析的结果:

使用可重用缓冲区也如下所示:

这里有一些有趣的事情值得注意。ExecCommand 的成本几乎是基于字符串版本尝试的两倍。深入挖掘，我相信错误就在这里:

var buffer = ArrayPool<byte>.Shared.Rent((int)cmds[2].Length);

cmds[2].CopyTo(buffer);

var val = new ReusableBuffer(buffer, (int)cmds[2].Length);

Item newItem;

ReusableBuffer key;

if (_state.TryGetValue(_reusable, out var item))

{

    // can reuse key buffer

    newItem = new Item(item.Key, val);

    key = item.Key;

}

else

{

    var keyBuffer = ArrayPool<byte>.Shared.Rent((int)cmds[1].Length);

    cmds[1].CopyTo(keyBuffer);

    key = new ReusableBuffer(keyBuffer, (int)cmds[1].Length);

    newItem = new Item(key, val);

}

_state[key] = newItem;

WriteMissing();

这段代码负责在字典中设置项。但是，请注意，我们正在对每个写操作执行读操作？这里的想法是，如果我们现在_state中已经存在了这个值，那么我们就避免再次为它分配缓冲区，而是重用它。

但是，这段代码处于这个基准测试的关键路径中，代价相当高昂。我修改了这段代码，不再重用，总是new对象进行分配，我们得到了一个比字符串版本快1~3%的版本。这看起来是这样的:

换句话说，这是当前每次操作对应的性能表（在探查器下）：

1.57 ms - 基于字符串
1.79 ms - 基于可重用缓冲区（减少内存使用量）
1.04 ms - 基于可重用缓冲区（优化查找）

得出的那些结果都在我计算机使用分析器运行的。让我们看看当我在生产实例上运行它们时，最终的结果是怎么样的？

基于字符串 – 16.0w次/秒
可重用缓冲区（减少内存代码）– 18.6w次/秒
可重用缓冲区（优化查找）– 17.5w次/秒

这些结果与我们在开发机器中看到的结果并不匹配。可能的原因是并发和请求数量足够高，负载足够大，以至于我们看到大规模内存优化的效果要好很多。

这是我能得出的唯一结论，减少分配内存，能够在这样的高负载场景下处理更多的请求。

系列链接

使用.NET简单实现一个Redis的高性能克隆版（一）

使用.NET简单实现一个Redis的高性能克隆版（二）

使用.NET简单实现一个Redis的高性能克隆版（三）

使用.NET简单实现一个Redis的高性能克隆版（四、五）