前方:

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

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

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

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

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

要是你看到一个员工坐着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:我博客是有打赞插件的,哈。

posted on 2016-07-13 09:59  路过秋天  阅读(3663)  评论(16编辑  收藏  举报
路过秋天