上两篇受益匪浅，秉着趁热打铁，不挖到最深不罢休的精神，我决定追加这篇。上一篇里最后我有提到实现分级缓存管理应该是个可行的方案，因此今天特别实践了一下。不过缓存分级之后也发现了一些问题，例如下图：
当appServerA修改了数据，并同步到Redis/DB之后，如何让appServerB也能更新本地缓存呢？虽然Redis的出现是为了解决这个问题的，但是分级方案里，MemoryCache还是需要保留。那么如何保存呢？我尝试了下面的几种方式，现在我们逐一来看。
全数据增量同步
所谓全数据校验，即所有的缓存数据首先都同步至Redis，然后根据数据的时间戳来进行同步。分解步骤如下：
- 首先将缓存的数据初始化，同步至Redis和MemoryCache，保持初始数据的同步
- 第二步，每当操作了数据之后，给记录一个时间戳标识最近的更新。
- 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功能。于是我就利用了这个功能，设计了如下的方案：
- 为app增加一个sub线程，用于接收redis订阅消息
- 在每一个缓存对象更新的同时，增加异步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，为了技术而技术了，不过不尝试碰下壁，怎么能得到成长。所谓兼听则明 偏信则暗，我感觉自己有点不见棺材不落泪了。请前辈们不吝指教！