前方:

其实完成这个功能之前,我就在思考:是先把想法写了来,和大伙讨论讨论后再实现,还是实现后再写文论述自己的思维。

忽然脑后传来一个声音说:你发文后会进入发呆阶段。

所以还是静下心,让我轻轻地把代码撸完再说。

最近这几天,自己在大脑里演练过各种技术难点,解决方案,推敲了各种该解决的问题,觉的差不多了,才决定撸码。

忽然发觉,原来代码是可以写在大脑里的。

要是你看到一个员工坐着2天没写一行代码,说明人家是高手,正在大脑编程。

好,不扯,回正文!

传统ORM的二级缓存为何失效?

有些ORM会提供:如Hibernate。

有些不提供:如EF,不提供是因为知道提供了也没啥鸟用,因为:

1:你不能强迫一个项目全部用单实体编程,多表时,用户更偏向于执行SQL语句。

2:没有分布式缓存做为基础,解决不了多应用程序部署的缓存策略问题。

因此:

1:若控制不了整个项目用户的SQL语句,单机的搞不了。

2:没有分布式缓存做基础,分布式的都搞不了。

这也是为啥EF一直不提供,是因为看到Hibernate虽然提供但并没多大卵用的原因吧!

疑惑数据库已有缓存,为何框架还要造孽?

主要原因:

1:数据库从请求到建立缓存,需要时间(框架缓存可以减缓数据库缓存失效时压力)

2:数据库是有链接数限制的,不可能允许大量并发的直连,需要外界分压。

3:数据库的缓存是单机性。

4:数据库发数据往服务器的时间比本机缓存的长。

自动缓存设计前的一些思考:

1:一开始我思考的缓存策略,是细化到行或列,于是了解数据库自身缓存后发现数据库目前也只是做了以表为单位。

2:MSSQL是有提供SqlDependency的缓存依赖项的,它可以从数据库层面通知你的数据何时失效。

3:但是SqlDependency和SqlCommand依赖太深,无法在所有数据库层面通用。

4:SqlDependency的缓存依赖只能在本地缓存。

5:其它数据库不支持依赖通知。

6:所以方案只能通过全局执行与分析,来处理缓存及失效策略。

7:单机时:全局拦截分析,如何分析出表?

8:应用分布式时:缓存及时失效?

9:用户直接修改数据库时:缓存如何失效?

还有好多好多问题,一直在思考......

缓存什么?

1:缓存单个对象时,是直接存档对象的,Cache返回时会根据本地或是远程选择是否Clone返回。。

2:缓存列表时:只存档字段类型仅包含:(数字、布尔、字符、时间、GUID)的字段,并转成Json字符串存档。

技术细节:

  A:一个对象存档在本机时,存档的是引用(可能出现误写操作);存档在分布式时,存档的不是引用,这会在使用时出现不确定性。

  B:大对象的存档,在缓存来去间需要序列化和反序列化,性能上降低很多。

因此:将列表转成Json存档,拿到时再还原,可以同时解决A和B的问题。

简单的说,如果对象有长字段,或者有二进制数据,是不会被缓存的,所以MSSQL的Timestamp字段就不要用了;

如果要用:AppConfig.DB.HiddenFields="字段名",把它隐藏了也行。

缓存时间?

考虑到通常访问量低时都是在中午和晚上的时间,因此,将缓存的对象的时间随机分布(早上的分布在中午失效,下午的分布在晚上失效)

考虑到分页时的查询,通常都关注前面几页,因此前面几页的数据,时间如上的时间段分布。

分页后面的数据,只默认2分钟的缓存时间。

其它规则有待讨论......

缓存多大?

1:在单机状态,检测到内存的可用比例低于15%时,则不再接受缓存。

2:在分布式缓存状态,暂时有多少扔多少。

缓存如何失效:

1:拦截请求:(包括(MAction)增删改查+(MProc)执行自定义语句+(MDataTable)批量方法)

2:分析语句的关联表(单表的可以拿表名,视图的拿关联结构涉及的表名,存储过程(目前没法),自定义SQL(语句分析出表名),批量(直接拿表名)

3:技术难点:如何从未知的SQL或视图中准确的分析出所有关联的表。

4:缓存失效:执行以下方法应该失效:增删改,执行ExeNonQuery,批量语句。

5:技术难点:

  1:对于视图(关联了多个表,如何根据一个表名,关联到相应涉及的视图语句失效?)

  2:对于分布式的应用,A服务更新,如何B服务器也失效。

如何处理修改频繁的表:

1:一开始想增加配置,让用户设置不参与缓存的表,认真思考后,发现根据缓存失效的时间和次数,可自动分析判断一个表是否修改频繁。

2:表操作相关增删查时,该表被置为失效(相关缓存会被移除),此时设置好时间间隔(6秒),在此时间段对该表相关的不缓存,同时提交的缓存删命令也可以无视。

3:对被分析出为修改频繁的表该如何处理?延长相应的不缓存时间,或是??还需要思考!!!

缓存失效的粒度能不能小?

1:目前的失效,和数据库一样,是以表为单位的。

2:对于插入操作,不会影响某一条数据的读取(所以单条数据的查询,是不应该受到插入操作的影响的)

3:还有其它情形是必然不会影响的?

框架有自动缓存,业务需不需要缓存?

1:数据库有自动缓存,框架的也可以自动缓存。

2:框架有自动缓存,同理业务也可以有缓存。

框架能处理的粒度是有限的,不能细到具体的行或列的缓存级别,因此在业务复杂和并发到一定量后,业务缓存是必要的。

数据库有缓存,业务也可做缓存,为何还思考往框架增加自动缓存?

1:数据库的默认缓存是固定的,需要配置,各种数据库环境不一致。

2:数据库链接池默认是固定的。

3:业务加缓存的事,往往是后期的动作。

现另一个现状是:

1:.NET 群体,存在很多初中级的开发人员,这部分人员的技术成长相对较慢,对缓存或性能调优并不熟。

2:国内有很多的中小网站,默认都抗不起并发,攻击成本很小,几百上千个并发就可以挂你站了。

因此,既然有现实的问题,就可以有对应的解决方案。

V5框架此功能的出现,就是为了从基础层面统一解决这些问题。

只有当.NET行业不在有慢网站的存在,整体提升档次了,有良好的口碑,才会引进更多的BOSS选用 .NET,大伙所期待的.NET春天也就近了

V5的目前解决的问题:

总体而言,要实现这个功能,核心要解决以下问题:

下面我来将技术一点一点出卖:

5:AOP拦截问题:

首先,要实现这功能,就得全局拦截,扫荡过源码或用过V5的同学,听说过框架本身就有AOP的吧;

其次,得改造这个AOP:框架默认有一个空AOP,当外部有AOP装载的时候,会替换掉这个空AOP。

要实现这个自动缓存:本想在空AOP里实现,放着浪费,但若用户自定义的Aop被装载,又会被替换掉,走不通...

方案想了三四个,思考了三四夜,最后还是在撸码时才确定了现在的模式(这个告诉我们,想的差不多了就该撸码了,要100%想通再撸不太靠谱):

于是,我这样做了:

原有的Aop,改名成InterAop,不过是挂名的,因为它没有继承IAOP接口,而且从原本的单例变更成多例模式。

这里可以贴两行代码,意思是:在Bengin和End方法调用了外部AOP的接口,并根据外部AOP的状态决定后续的执行流程:

完整的源码你们自己SVN了:https://github.com/cyq1162/cyqdata.git

 public AopResult Begin(AopEnum action)
{
AopResult ar = AopResult.Continue;
if (outerAop != null)
{
ar = outerAop.Begin(action, Para);
if (ar == AopResult.Return)
{
return ar;
}
}
if (AppConfig.Cache.IsAutoCache && !IsTxtDataBase) // 只要不是直接返回
{
isHasCache = AutoCache.GetCache(action, Para); //找看有没有Cache
}
if (isHasCache) //找到Cache
{
if (outerAop == null || ar == AopResult.Default)//不执行End
{
return AopResult.Return;
}
return AopResult.Break;//外部Aop说:还需要执行End
}
else // 没有Cache,默认返回
{
return ar;
}
} public void End(AopEnum action)
{
if (outerAop != null)
{
outerAop.End(action, Para);
}
if (!isHasCache && !IsTxtDataBase)
{
AutoCache.SetCache(action, Para); //找看有没有Cache
}
}

代码最后很少,但没想出来之前,2天都搞不定。

1:基础单表、视图操作

A:单表,这个是最简单的,传递进来的就是表名;

B:视图,这个麻烦一点,传递的是视图名;

于是,如何从视图获取相关参与的表名?你现在应该不知道,我来告诉你吧:

DBDataReader sdr=....
DataTable dt = sdr.GetSchemaTable();

这条语句,可以通杀所有的数据库,不用去N种数据库里搜各种元数据藏在哪了!!!

2:多表SQL语句操作:

对于SQL语句,可以用上面的方法,执行一个DataReader再拿,但我弄了一个简单的方法来找关联表:

 internal static List<string> GetTableNamesFromSql(string sql)
{
List<string> nameList = new List<string>(); //获取原始表名
string[] items = sql.Split(' ');
if (items.Length == 1) { return nameList; }//单表名
if (items.Length > 3) // 总是包含空格的select * from xxx
{
bool isKeywork = false;
foreach (string item in items)
{
if (!string.IsNullOrEmpty(item))
{
string lowerItem = item.ToLower();
switch (lowerItem)
{
case "from":
case "update":
case "into":
case "join":
case "table":
isKeywork = true;
break;
default:
if (isKeywork)
{
if (item[0] == '(' || item.IndexOf('.') > -1) { isKeywork = false; }
else
{
isKeywork = false;
nameList.Add(NotKeyword(item));
}
}
break;
}
}
}
}
return nameList;
}

有可能会找多,找到后,再过滤一下名称是不是数据库里的表就可以了。

3:直接操作数据库

一开始设置的思维,是动态创建一个表,字段大概是这样的:

表名    更新时间

然后如果手工操作数据库,可以手工更改时间,也可以用触发器引发这里的更新。

然后后台线程定时扫这个表,就知道有没有表被更新了。

不过--------V5目前并木有实现它,只是开放了一个接口,可以让你在代码里调用移除缓存。

这个方法就是:

 public abstract partial class CacheManage
{
/// <summary>
/// 获取系统内部缓存Key
/// </summary>
public static string GetKey(CacheKeyType ckt, string tableName)
{
return GetKey(ckt, tableName, AppConfig.DB.DefaultDataBase, AppConfig.DB.DefaultDalType);
}
/// <summary>
/// 获取系统内部缓存Key
/// </summary>
public static string GetKey(CacheKeyType ckt, string tableName, string dbName, DalType dalType)
{
switch (ckt)
{
case CacheKeyType.Schema:
return TableSchema.GetSchemaKey(tableName, dbName, dalType);
case CacheKeyType.AutoCache:
return AutoCache.GetBaseKey(dalType, dbName, tableName);
}
return string.Empty;
}
}

4:跨服务器操作

这个本来是简单的,后来又想麻烦了,因为要兼顾性能问题,缓存移除可能会频繁的问题。

后来,通过增加了缓存类型,来识别本地缓存或分布式缓存,来区别写代码:

private static void SetBaseKey(string baseKey, string key)
{
//baseKey是表的,不包括视图和自定义语句
if (_MemCache.CacheType == CacheType.LocalCache)
{
if (cacheKeys.ContainsKey(baseKey))
{
cacheKeys[baseKey] = cacheKeys[baseKey].Append("," + key);
}
else
{
cacheKeys.Add(baseKey, new StringBuilder(key));
}
}
else
{
StringBuilder sb = _MemCache.Get<StringBuilder>(baseKey);
if (sb == null)
{
_MemCache.Set(baseKey, new StringBuilder(key));
}
else
{
sb.Append("," + key);
_MemCache.Set(baseKey, sb);
}
}
}

6:缓存失效问题  

这个问题,流程本来很简单的:

但思考到Cache多,而且分布式时,返回会卡,所以删除Cache操作就变成线程处理了。

后来为了避免线程多开,又把类改成了单例(一开始是多实例的)

现在,又把这线程的线程开启,放到LocalCache里和另一个线程作伴了,然后这个单例类又变更成了静态类。

V5框架怎么使用这功能:

升级版本到最新版即可!

总结:

1:没有这个功能之前:框架解决了三大问题:编程架构的统一(自动化)、数据库压力(读写分离)、服务器压力(分布式缓存)。

2:此功能的存在:是针对从基础层面提升行业项目的整体水平。

3:最近大脑有点发春,一个个创新Idea不断的从我大脑冒出来,折腾的我好累:

要思考架构、落实框架代码、要写文分享,写框架Demo、群里解答。

4:开源不赚钱,又投入这么多精力,只能把它当理想了,希望它有天成为.NET项目的标配数据层。

5:我博客是有打赞插件的,哈。

CYQ.Data V5 分布式自动化缓存设计介绍的更多相关文章

  1. CYQ.Data V5 分布式自动化缓存设计介绍(二)

    前言: 最近一段时间,开始了<IT连>创业,所以精力和写的文章多数是在分享创业的过程. 而关于本人三大框架CYQ.Data.Aries.Taurus.MVC的相关文章,基本都很少写了. 但 ...

  2. CYQ.Data V5 分布式缓存Redis应用开发及实现算法原理介绍

    前言: 自从CYQ.Data框架出了数据库读写分离.分布式缓存MemCache.自动缓存等大功能之后,就进入了频繁的细节打磨优化阶段. 从以下的更新列表就可以看出来了,3个月更新了100条次功能: 3 ...

  3. CYQ.Data V5 数据库读写分离功能介绍

    前言 好多年没写关于此框架的新功能的介绍了,这些年一直在默默地更新,从Nuget上的记录就可以看出来: 这几天在看Java的一些东西,除了觉的Java和.NET的相似度实在太高之外,就是Java太原始 ...

  4. CYQ.Data V5 分布式缓存MemCached应用开发介绍

    前言 今天大伙还在热议关于.NET Core的东西,我只想说一句:在.NET 跨平台叫了这么多年间,其实人们期待的是一个知名的跨平台案例,而不是一堆能跨平台的消息. 好,回头说说框架: 在框架完成数据 ...

  5. CYQ.Data V5 从入门到放弃ORM系列:框架的优势

    前言: 框架开源后,学习使用的人越来越多了,所以我也更加积极的用代码回应了. 在框架完成了:数据库读写分离功能 和 分布式缓存功能 后: 经过三天三夜的不眠不休,终于完成框架第三个重量级的功能:自动化 ...

  6. CYQ.Data 支持分布式数据库(主从备)高可用及负载调试

    前言: 继上一篇,介绍 CYQ.Data 在分布式缓存上支持高可用,详见:CYQ.Data 对于分布式缓存Redis.MemCache高可用的改进及性能测试 本篇介绍 CYQ.Data 在对数据库层面 ...

  7. CYQ.Data V5 MDataTable 专属篇介绍

    前言 以前一两个月才出一篇,这三天有点变态地连续1天1篇(其实都是上周末两天写好的存货). 短期应该没有新的和此框架相关的文章要写了,这应该是最后一篇,大伙且看且珍惜. 前两篇讲数据库读写分离和分布式 ...

  8. CYQ.Data 对于分布式缓存Redis、MemCache高可用的改进及性能测试

    背景: 随着.NET Core 在 Linux 下的热动,相信动不动就要分布式或集群的应用的需求,会慢慢火起来. 所以这段时间一直在研究和思考分布式集群的问题,同时也在思考把几个框架的思维相对提升到这 ...

  9. 终于等到你:CYQ.Data V5系列 (ORM数据层)最新版本开源了

    前言: 不要问我框架为什么从收费授权转到免费开源,人生没有那么多为什么,这些年我开源的东西并不少,虽然这个是最核心的,看淡了就也没什么了. 群里的网友:太平说: 记得一年前你开源另一个项目的时候我就说 ...

随机推荐

  1. VM(虚拟机安装win7 提示 :units specified don't exist, SHSUCDX can't install)解决方法

    改成IDE的模式

  2. 前端css兼容性与易混淆的点

    一.常用的骨灰级清除浮动 .clearfix:after { content: "."; display: block; height:; clear: both; visibil ...

  3. RecyclerView使用大全

    RecylerView介绍 RecylerView是support-v7包中的新组件,是一个强大的滑动组件,与经典的ListView相比,同样拥有item回收复用的功能,这一点从它的名字recyler ...

  4. jquery和Js的区别和基础操作

    jqery的语法和js的语法一样,算是把js升级了一下,这两种语法可以一起使用,只不过是用jqery更加方便 一个页面想要使用jqery的话,先要引入一下jqery包,jqery包从网上下一个就可以, ...

  5. Apache Ignite之集群应用测试

    集群发现机制 在Ignite中的集群号称是无中心的,而且支持命令行启动和嵌入应用启动,所以按理说很简单.而且集群有自动发现机制感觉对于懒人开发来说太好了,抱着试一试的心态测试一下吧. 在Apache ...

  6. 记一个mvn奇怪错误: Archive for required library: 'D:/mvn/repos/junit/junit/3.8.1/junit-3.8.1.jar' in project 'xxx' cannot be read or is not a valid ZIP file

    我的maven 项目有一个红色感叹号, 而且Problems 存在 errors : Description Resource Path Location Type Archive for requi ...

  7. WCF学习之旅—第三个示例之四(三十)

           上接WCF学习之旅—第三个示例之一(二十七)               WCF学习之旅—第三个示例之二(二十八)              WCF学习之旅—第三个示例之三(二十九)   ...

  8. HTML 事件(二) 事件的注册与注销

    本篇主要介绍HTML元素事件的注册.注销的方式. 其他事件文章 1. HTML 事件(一) 事件的介绍 2. HTML 事件(二) 事件的注册与注销 3. HTML 事件(三) 事件流.事件委托 4. ...

  9. dubbox微服务实例及引发的“血案”

    Dubbo 是阿里巴巴公司开源的一个高性能优秀的服务框架,使得应用可通过高性能的 RPC 实现服务的输出和输入功能,可以和 Spring框架无缝集成. 主要核心部件: Remoting: 网络通信框架 ...

  10. 【Java每日一题】20170106

    20170105问题解析请点击今日问题下方的"[Java每日一题]20170106"查看(问题解析在公众号首发,公众号ID:weknow619) package Jan2017; ...