前言:
其实完成这个功能之前,我就在思考:是先把想法写了来,和大伙讨论讨论后再实现,还是实现后再写文论述自己的思维。
忽然脑后传来一个声音说:你发文后会进入发呆阶段。
所以还是静下心,让我轻轻地把代码撸完再说。
最近这几天,自己在大脑里演练过各种技术难点,解决方案,推敲了各种该解决的问题,觉的差不多了,才决定撸码。
忽然发觉,原来代码是可以写在大脑里的。
要是你看到一个员工坐着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项目的标配数据层。