Redis到底该如何利用(三)?_.NET_编程开发_程序员俱乐部

中国优秀的程序员网站程序员频道CXYCLUB技术地图
热搜:
更多>>
 
您所在的位置: 程序员俱乐部 > 编程开发 > .NET > Redis到底该如何利用(三)?

Redis到底该如何利用(三)?

 2014/11/19 3:08:52  笋干  程序员俱乐部  我要评论(0)
  • 摘要:上两篇受益匪浅,秉着趁热打铁,不挖到最深不罢休的精神,我决定追加这篇。上一篇里最后我有提到实现分级缓存管理应该是个可行的方案,因此今天特别实践了一下。不过缓存分级之后也发现了一些问题,例如下图:当appServerA修改了数据,并同步到Redis/DB之后,如何让appServerB也能更新本地缓存呢?虽然Redis的出现是为了解决这个问题的,但是分级方案里,MemoryCache还是需要保留。那么如何保存呢?我尝试了下面的几种方式,现在我们逐一来看。全数据增量同步所谓全数据校验
  • 标签:利用

class="hf-line">上两篇受益匪浅,秉着趁热打铁,不挖到最深不罢休的精神,我决定追加这篇。上一篇里最后我有提到实现分级缓存管理应该是个可行的方案,因此今天特别实践了一下。不过缓存分级之后也发现一些问题,例如下图:

当appServerA修改了数据,并同步到Redis/DB之后,如何让appServerB也能更新本地缓存呢?虽然Redis的出现是为了解决这个问题的,但是分级方案里,MemoryCache还是需要保留。那么如何保存呢?我尝试了下面的几种方式,现在我们逐一来看。

 全数据增量同步

所谓全数据校验,即所有的缓存数据首先都同步至Redis,然后根据数据的时间戳来进行同步。分解步骤如下:

  1. 首先将缓存的数据初始化,同步至Redis和MemoryCache,保持初始数据的同步
  2. 第二步,每当操作了数据之后,给记录一个时间戳标识最近的更新。
  3. MemoryCache定时或者每次取数据的时候,以最近的一个同步的时间戳开始同步到现在的时间戳

上面的方案咱们落地到.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功能。于是我就利用了这个功能,设计了如下的方案:

  1. 为app增加一个sub线程,用于接收redis订阅消息
  2. 在每一个缓存对象更新的同时,增加异步pub消息到redis

先来看下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,为了技术而技术了,不过不尝试碰下壁,怎么能得到成长。所谓兼听则明 偏信则暗,我感觉自己有点不见棺材不落泪了。请前辈们不吝指教!

发表评论
用户名: 匿名