前言
.NETCore 从1.0发布历经坎坷,一开始各种库缺失到现在的部分完善,走到今天实属不易。
比如 redis-cli SDK 简直是坑出不穷。
过去 .net 最有名望的 ServiceStack.Redis 早已沦为商业用途,在 .NETCore 中使用只能充值;
后来居上的 StackExchange.Redis 虽然能用,但线上各种 Timeout 错误把人坑到没脾气,两年多两年多两年多都不解决,最近发布的 2.0 版本不知道是否彻底解决了底层。
csredis v3.0.0 更新
1、所有方法名与redis-cli保持一持;
据了解,java/python/go/nodejs/php SDK 方法名基本都与 redis-cli 一致,反对二次命名的库
2、增加反序列对象获取,如:Get<byte[]>、HGet<byte[]>,所有获取方法都重载了
3、SafeObjectPool 的引入使用;
使用
nuget Install-Package CSRedisCore
var rds = new CSRedis.CSRedisClient("127.0.0.1:6379,password=123,defaultDatabase=13,poolsize=50,ssl=false,writeBuffer=10240,prefix=key前辍"); rds.Set("test1", "123123", 60); rds.Get("test1"); //函数名与 redis-cli 的命令相同,rds 一定是单例单例单例高级玩法:分区
现实多个服务节点共同分担存储,与官方的分区、集群、高可用方案不同。
例如:缓存数据达到500G,如果使用一台redis-server服务器光靠内存存储将非常吃力,使用硬盘又影响性能。
可以使用此功能自动管理N台redis-server服务器分担存储,每台服务器只需约 (500/N)G 内存,且每台服务器匀可以配置官方高可用架构。
var rds = new CSRedis.CSRedisClient(null, "127.0.0.1:6371,password=123,defaultDatabase=11,poolsize=10,ssl=false,writeBuffer=10240,prefix=key前辍", "127.0.0.1:6372,password=123,defaultDatabase=12,poolsize=11,ssl=false,writeBuffer=10240,prefix=key前辍", "127.0.0.1:6373,password=123,defaultDatabase=13,poolsize=12,ssl=false,writeBuffer=10240,prefix=key前辍", "127.0.0.1:6374,password=123,defaultDatabase=14,poolsize=13,ssl=false,writeBuffer=10240,prefix=key前辍"); //实现思路:根据key.GetHashCode() % 节点总数量,确定连向的节点 //也可以自定义规则(第一个参数设置) rds.MSet("key1", 1, "key2", 2, "key3", 3, "key4", 4); rds.MGet("key1", "key2", "key3", "key4");高级玩法:发布订阅
//普通订阅 rds.Subscribe( ("chan1", msg => Console.WriteLine(msg.Body)), ("chan2", msg => Console.WriteLine(msg.Body))); //模式订阅(通配符) rds.PSubscribe(new[] { "test*", "*test001", "test*002" }, msg => { Console.WriteLine($"PSUB {msg.MessageId}:{msg.Body} {msg.Pattern}: chan:{msg.Channel}"); }); //模式订阅已经解决的难题: //1、分区的节点匹配规则,导致通配符最大可能匹配全部节点,所以全部节点都要订阅 //2、本组 "test*", "*test001", "test*002" 订阅全部节点时,需要解决同一条消息不可执行多次 //发布 rds.Publish("chan1", "123123123"); //无论是分区或普通模式,rds.Publish 都可以正常通信高级玩法:缓存壳
