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