前言：

自从CYQ.Data框架出了数据库读写分离、分布式缓存MemCache、自动缓存等大功能之后，就进入了频繁的细节打磨优化阶段。

从以下的更新列表就可以看出来了，3个月更新了100条次功能：

+ View Code?

其实更多的时间，是放在ASP.NET Aries 业务开发框架上，上里下外全部重构了一遍。

前几天，决定把Redis集成进来，一鼓作气，解决了。

下面分享一下经历：

最初的想法：

一开始我是拒绝的，不愿动态调用第三方的客户端（关联依赖的dll太多）。

最近打算支持Redis，有点妥协了，动态加载就动态加载了吧：

考虑着引入：StackExchange.Redis或ServiceStack.Redis？

看着这些DLL，太重量级，方法反射起来也费劲！

中间思维停顿了一会。。。

发现轻量级：Bettle.Redis

在寻找Redis的API资料时，无意发现了这个开源的轻量级Bettle.Redis。

看到源码编绎后才46K，感觉就是它了。

不过才几刻间，发现了以下几个问题了：

1：自身虽然46K，但代码引用了另外两个3个dll（依赖太多）：

2：使用的方法不符合使用习惯，一个命令类型就对应一个类。

3：不支持集群的水平扩展（没实现支持一致性Hash）。

4：代码是用.NET 4.0 以下版本写的，（CYQ.Data 框架是支持2.0起的，改代码改到我手痛）

所以，以上原因估计是它没被普及的原因，也是最终没有被我选择集成的原因。

但是它开放了源码、对我还是有点启发和参考意义。

Redis API 扫盲：

在决定支持Redis的过程中，花了不少时间扫了Redis的文档：

更多命令详情可以看：http://doc.redisfans.com

从这么一堆的命令中，找到基本命令：Get、Set、Exists、Expire、Info，可怜没有Add。

其它的命令，多数都是可以用基本命令实现的，就被无视了。

经过短时间内大量的集中思考，决定自己实现了：

重新定位的思路：

框架之前已经集成了MemCache，而Redis和MemCache又大同小异。

一些共性的东西，可以复用：

1：hash算法。

2：一致性Hash（水平扩展）。

3：SocketPool。

4：ServerPool。

5：序列化（压缩）

剩下的，就是完成Socket和Redis的交互及使用方式。

以下是Redis的协议规范，不过是我实现Redis相关功能后才发现的：

?

折腾的经过：

Bettle.Redis里有源码，看看实现就可以了，所以没找协议规范：

通过几个小时的引进和代码调整，测试。

以为大功告成之际，测试到当Set的数据太大时，NetworkStream报异常：此流不支持Seek操作。

怀疑是Redis的Set有大小限制?：用Bettle.Redis自身试了下，发现正常，梦B了。

经代码调试，发现Bettle的Socket实现（Socket.Send）和Socket池的实现（NetworkStream.Write）不一样。

Bettle.Redis是把所有的协议构造好一次性Socket.Send（byte[]）。

怀疑NetworkStream的默认缓存池太小引发的？：用memCache，Set了大量的数据，发现NetworkStream并没有抛异常，又梦B了。

怀疑是Redis协议的问题了？：改造代码，把协议分拆，先发送：$长度 ，再发送数据，发现竟然正常了，无语问苍天了！

经过一夜一天的折腾，Cache目录下补了4个类，同时进行了算法优化，清掉一些没用的代码。

支持Redis后，发现cyq.data.dll的大小竟然没变化，结果超出了预期，很好！

最后改造成的源码结构是：

完整的源码已经提交在：https://github.com/cyq1162/cyqdata

Redis使用方式：

　　　　　　  AppConfig.Cache.RedisServers = "127.0.0.1:6379,127.0.0.1:1121";//配置启用,            AppConfig.Cache.RedisServersBak = "127.0.0.1:6379";//备用配置。                       CacheManage cache = CacheManage.RedisInstance;//操作对象            cache.Add("obj", cache.CacheTable);//添加DataTable            MDataTable obj = cache.Get<MDataTable>("obj");            Console.WriteLine(obj.Rows.Count);            Dictionary<string, string> dic = new Dictionary<string, string>();            dic.Add("路过秋天", "http://www.cnblogs.com/cyq1162");            cache.Add("dic", dic);//添加字段            Dictionary<string, string> dicObj = cache.Get<Dictionary<string, string>>("dic");            Console.WriteLine(dicObj["路过秋天"]);            cache.Remove("dic");//移除Dic            bool hasKey = cache.Contains("dic");//检测是否存在            Console.WriteLine(hasKey);            Console.Read();

结果：

对于存储类型的改进：

由于Redis的Get只支持字符串，为了达到支持任意类型，我必须改进算法：

1：存档：目标是对象时=》进行序列化（对于>128K的会进行压缩）

2：数据的第1个字节：存档数据类型。

3：获取数据时：根据第1个字节，进行准确的数据类型还原。

（aaa是通过命令行Set的，而a0是通过代码设置的，所以多了\x02的类型标识）

因此：框架靠Set与Get能支持任意类型的存取档！

对于分布式算法的改进：

1：对于水平增加节点的扩展：

内部已经实现了一致性Hash算法，因此省了不少工作：

简单的描述为：把ip1产生N个hash ，ip2产生N个hash，... 然后排序（最后就看key的hash值离谁最新就粘谁了）

借用一张图表示为：

2：对于节点故障的转移：

在测试的过程中，我填写了一台异常的主机，发现被分配到异常的主机的key的读写都没反应了：

（我潜意识默认以为会自动转移到相邻的主机中）

默认的算法：

1：没有自动切换相邻的主机【用思考代码疑问：主动切换可能导致雪崩效应，（累积的压力可能把所有的服务器都搞挂）】。

2：有重试连接机制（2分钟试1次）。

改进了算法：增加了一个备份机的配置（AppConfig.Cache.RedisServersBak）

1：根据Hash，每一台主机都会指向一台备份机。2：主机异常时，由备份机代理服务器15分钟（即每15分检测主机是否正常一次，如果正常，则恢复主机服务）。

3：当主机恢复时，从备份机里恢复数据，并清空备份机的数据（未实现）

由于可能同时挂掉N台，所以备份机可能存档多台主机的信息。

于是算法的思路有3个：

1：数据不要了（主机重新缓存即可）2：主机被请求时（检测是否挂过，如果是，读自身（若没有）=》读备份机（同时发表移除指令）（若有数据）=》返回（同时写入主机）3：主机被请求时（检测是否挂过，如果是开启线程（读备份机所有Key，检测Hash是否符合自身，如果是，则从备份读取并写入，同时清除备份机的数据）

总结：

至此，CYQ.Data已经支持上Redis了，而且在分布式算法上，借了memCache的风，以及改进的算法，显的更为实用！

当然，细节仍需打磨，代码还可以改的更简洁优美。

在分布式已经泛滥的今天，能正确的判断并用好分布式框架是一种能力的体现。

刚刚群里有人发了这条消息：

其实前面的问题都可以无视，因为最后解决方案他只是把Redis部署从Windows转移到Linux就好了。

QPS最大时听说7万多（两台Web分来就是3万多，大部分是刷票造成的请求）

Redis在Windows上的表现并不如Linux的好，这个可以理解。

但是如果在架构设计方案上稍为调整，其实也毫无压力了。

最后我发现问题的根源不在于技术，在于人：.NET缺少有足够知识和思维的架构师。

不要遇到点问题就力不从心，在.NET的阵营上坚持吧，少年！