使用.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 buffernewItem = 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%的版本。这看起来是这样的: