使用.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的高性能克隆版（四、五）
