1.性能問題-批量多次讀寫、序列化和反序列化的場景

注意看到dotnet下的IDistributedCache接口內部方法聲明都是針對單個key的，當需要多次大量讀寫同一類型kv值時，存在多次連接redis的情況，導致性能特別慢。
在abp框架中AbpRedisCache有些SetMany和GetMany的方法，它可以很好的解決這個問題。
今天再分享一個Redis的批操作的寫法(db.CreateBatch())，性能會更好一些，大致寫法如下。

    static async Task Main(string[] args)
    {
        // 連接到 Redis 服務器
        var connection = ConnectionMultiplexer.Connect("localhost:6379");
        var db = connection.GetDatabase();

        // 使用管道進行批量操作
        var batch = db.CreateBatch();

        // 執行多個命令
        var task1 = batch.StringSetAsync("key1", "value1");
        var task2 = batch.StringSetAsync("key2", "value2");
        var task3 = batch.StringSetAsync("key3", "value3");

        // 提交批量操作
        batch.Execute();

        // 等待所有異步操作完成
        await Task.WhenAll(task1, task2, task3);

        // 驗證結果
        Console.WriteLine(await db.StringGetAsync("key1"));  // 輸出 "value1"
        Console.WriteLine(await db.StringGetAsync("key2"));  // 輸出 "value2"
        Console.WriteLine(await db.StringGetAsync("key3"));  // 輸出 "value3"
    }

另外我們還要注意，儘量別存取複雜對象，儘量是值類型、string和byte[]，因為複雜對象我們很多都是json序列化成string後再存，讀的時候還要反序列化，大量數據或者特別大的對象序列化和反序列化都是很消耗性能的，特別批量存取的情況下更嚴重。

2.報錯問題

經常報超時錯誤，StackExchange.Redis.TimeoutException。
很多時候與redis本身沒關係，很多是我們用了一些第三方庫導致，比如：
CSRedis-到目前內存實現都是同步代碼
EasyCaching-極容易導致超時情況，它內存莫名其妙開鎖
本人目前就發現這兩個，主要是極高併發的情況下，普通使用基本沒問題，調試當然是發現不了問題的。
所以乾脆別再用第三方庫，就用StackExchangeRedis好了，其他都只能是基本的封裝，別玩花樣（比如試圖寫個庫自動適配其他緩存場景）。

3.吐槽下dotnet下的生態

dotnet開源已經很久了，本身非常好用，特別是其他重量級的庫，比如EFCore就非常棒。
但是很多第三方庫就很糟糕了，redis這個只是其中有一個，其他方面的庫在我使用過後都存在的各種問題，而且都非常棘手，都是容易引起性能問題的情況。
所以總結就是少用各種組件和各種庫，即便有些庫有大量的推薦文章，真用起來，高併發的情況下就是災難。