性能文章>使用.NET简单实现一个Redis的高性能克隆版(六)>

使用.NET简单实现一个Redis的高性能克隆版(六)原创

1月前
163301

译者注

该原文是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%左右。

我猜测是因为我们这个场景的分配模式非常适合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的高性能克隆版(四、五)

点赞收藏
分类:标签:
INCerry
请先登录,感受更多精彩内容
快去登录吧,你将获得
  • 浏览更多精彩评论
  • 和开发者讨论交流,共同进步

为你推荐

【全网首发】Redis系列3:高可用之主从架构

【全网首发】Redis系列3:高可用之主从架构

Redis只能做缓存?太out了!

Redis只能做缓存?太out了!

【全网首发】Redis系列4:高可用之Sentinel(哨兵模式)

【全网首发】Redis系列4:高可用之Sentinel(哨兵模式)

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

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

【全网首发】Redis系列5:深入分析Cluster 集群模式

【全网首发】Redis系列5:深入分析Cluster 集群模式

【全网首发】追求性能极致:Redis6.0的多线程模型

【全网首发】追求性能极致:Redis6.0的多线程模型

1
0