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这个只是其中有一个，其他方面的库在我使用过后都存在的各种问题，而且都非常棘手，都是容易引起性能问题的情况。
所以总结就是少用各种组件和各种库，即便有些库有大量的推荐文章，真用起来，高并发的情况下就是灾难。