class="hf-line">上两篇受益匪浅,秉着趁热打铁,不挖到最深不罢休的精神,我决定追加这篇。上一篇里最后我有提到实现分级缓存管理应该是个可行的方案,因此今天特别实践了一下。不过缓存分级之后也发现了一些问题,例如下图:
当appServerA修改了数据,并同步到Redis/DB之后,如何让appServerB也能更新本地缓存呢?虽然Redis的出现是为了解决这个问题的,但是分级方案里,MemoryCache还是需要保留。那么如何保存呢?我尝试了下面的几种方式,现在我们逐一来看。
全数据增量同步
所谓全数据校验,即所有的缓存数据首先都同步至Redis,然后根据数据的时间戳来进行同步。分解步骤如下:
上面的方案咱们落地到.NET+Redis又该怎么处理呢?
第一步很简单直接跳过,第二步就有点问题了,这个时间戳要便于redis的排序和获取,考虑到这些问题,我觉得取Linux的数字型时间戳比较靠谱,再配合SortSet来建立索引,进行同步,看起来的确不错。那么来看下代码:
本篇还是以User为例,可能场景不适合,大家将就理解
public void UpdateToRedis(User user) { var redis = ConnectionMultiplexer.Connect("localhost"); var db = redis.GetDatabase(); TimeSpan ts = DateTime.Now.ToUniversalTime() - new DateTime(1970, 1, 1, 0, 0, 0, 0); double time = Convert.ToInt64(ts.TotalSeconds);//计算Unix时间戳 db.SortedSetAdd("capqueen:user:index", user.Id, time);//更新记录 var json = JsonConvert.SerializeObject(user); db.StringSet("capqueen:user" + user.Id, json);//user记录 }
同步:
public void Sync(double timespan) { var redis = ConnectionMultiplexer.Connect("localhost"); var db = redis.GetDatabase(); TimeSpan ts = DateTime.Now.ToUniversalTime() - new DateTime(1970, 1, 1, 0, 0, 0, 0); double time = Convert.ToInt64(ts.TotalSeconds);//计算Unix时间戳 //同步时间范围内的记录,这里增加时间范围,以防止一些数据不准确的问题 var members = db.SortedSetRangeByScore("capqueen:user:index", timespan, time); var keys = members.ToList().Select<RedisValue, RedisKey>(i => i.ToString()); var values = db.StringGet(keys.ToArray()); //构造List Json以加速解析 var portsJson = new StringBuilder("["); values.ToList().ForEach(item => { if (!string.IsNullOrWhiteSpace(item)) { portsJson.Append(item).Append(","); } }); portsJson.Append("]"); var users = JsonConvert.DeserializeObject<List<User>>(portsJson.ToString()); //和内存的List<User>做同步 ... //END }
上面的代码只是实例,实际运行的时候感觉还不是特别靠谱。
消息通知
增量同步是好,但是同时时机也是个问题,时机不对,就会影响用户体验。而且感觉我们还是无法很好的掌控数据。那么有没有一种方式可以及时的通知到appServer更新缓存呢?这里我脑子里冒出来的是.NET Event机制。
我觉得.NET因为有了优秀的Event机制,才让我觉得它使用起来很方便
但是这里是服务器之间的通信,我想非Scoket莫属了,之间做过Scoket双向通信,印象特别深刻,这样的场景让我自然而然的想到了这个方案。可是特别的增加一个socket,本身复杂的架构要更复杂了,还是寻求一个靠谱的中间件比较适合。看过Redis的功能列表的同学,一定没忘记Redis还有一个订阅发布,pub/sub功能。于是我就利用了这个功能,设计了如下的方案:
先来看下Redis的,pub/sub功能,请看文档
redis提供指定channel的订阅发布功能,每一个Client可以订阅指定的channel消息,也可以向指定的channel发送消息。
利用ServiceStack.Redis的pub/sub功能实现如下:
using (var redisConsumer = new RedisClient(TestConfig.SingleHost)) using (var subscription = redisConsumer.CreateSubscription()) { subscription.OnSubscribe = channel => { //订阅事件 }; subscription.OnUnSubscribe = channel => { //退订事件 }; subscription.OnMessage = (channel, msg) => { // 这里的msg,我为了测试定义成了userid var user= redisConsumer.As<User>().GetById(msg);//从Redis获取记录 UpdateLocalCache(user);//更新本地 }; subscription.SubscribeToChannels("capqueen:redis:events"); //blocking }
发送:
using (var redisPublisher = new RedisClient("localhost")) { redisPublisher.PublishMessage("capqueen:redis:events", userId);//发送消息 }
这里我觉得message应该定义成一个消息体,接收处理应该根据具体的消息定义来具体处理,因为订阅发布的通道显然应该是合理利用,如果一个业务一个通道,有点太多了。
当然这个实现起来又要讲一大篇了,这里不多说明。
本篇文章,根据上一篇提的方案做了一些实现,不足之处太多了。例如事件丢了怎么办?如何正确的处理消息缺失,记录少了之类的特殊情况应该是很重要的。我暂时还没想到方案,不知道前辈们如何看待这样的问题。可能我还是滥用了Redis,为了技术而技术了,不过不尝试碰下壁,怎么能得到成长。所谓兼听则明 偏信则暗,我感觉自己有点不见棺材不落泪了。请前辈们不吝指教!