首先奉献caching的开源地址[微软源码]

1.工程架构

为了提高程序效率,我们经常将一些不频繁修改,但是使用了还很大的数据进行缓存。尤其是互联网产品,缓存可以说是提升效率优化第一利器。微软为我们实现了俩种缓存方式:内存缓存、分布式缓存。个人理解如果缓存在前端电脑内存的缓存叫做内存缓存,如果缓存在其它设备上,那么叫做分布式缓存。

  • 俩种缓存方式的优缺点

  我开发程序经历过三个时间点,开始的时候从来不使用缓存,之后将数据缓存在内存中,最后使用分布式缓存。内存缓存的优点是速度快,缺点是内存损耗比较大,可能缓存的数据太大的时候就放不下了,另外一个缺点就是对于多前端程序的原则上是不支持的。而分布式缓存的优点是,理论上缓存大小没有上线,可以通过扩充物理硬件进行扩展,对于多前端支持的较好。

Microsoft.Framework.Caching.Abstractions

这个工程定义的是缓存的整体架构。我们的思想是面向接口编程,而不是面向实现编程。所以该工程定义了我们想要的接口

从上图显而易见,微软将内存缓存和分布式缓存割裂开来,而不是我们一般意义上定义一个ICache接口,之后让IMemoryCache和IDistributedCache分别继承ICache接口。

所以我们用分布式缓存,内存缓存原则不能无缝的直接切换。需要我们修改程序代码,或者进行适配封装。

  • 分布式缓存

   这部分包含内容只包含简单的俩点:配置项(DistributedCacheEntryOptions)、缓存接口(IDistributedCache)。而DistributedCacheEntryExtentions是DistributedCacheEntryOptions的扩展方法包装类,CaceheExtensions是IDistributedCache扩展方法包装类,CacheItemPriority是优先级枚举。

  • 内存缓存

  内存缓存,微软的设计就比较复杂,考虑到方方面面。首先时缓存的配置项(IMemoryCacheEntryOptions)、缓存接口(IMemoryCache)以及它们扩展项(MemoryCacheEntryExtentions、CacheExtentions)。

  但是微软的想法,缓存不止应该只有过期失效,当我程序update一个字段后,我想通知内存缓存,我更改了,那又该怎么办呢?于是微软设计了右上角的部分(*由于代码的持续更新原因右上角部分的接口已经被去掉,由IList<IChangeToken> ExpirationTokens { get; }属性替代,但是原则都是一样的,即外部通知内部,数据已经更新)。

  既然外部数据更新能通知缓存,那反向呢?缓存更新是否能够通知外部使用对象呢?答案是这个可以支持,所有上边框,下面的部分。

  既然能外部修改通知内部,内部修改也能通知外部应用程序。设计已经趋近完美了?微软说还不够,于是上图左边的部分产生了。它的意义就是,我可以为缓存创建一个范围,至于范围是做什么的?答案是“我也不知道”,但是从内存缓存的实现上来看,是用于整体缓存token等信息的。

  缓存配置项的时间选项:AbsoluteExpiration、AbsoluteExpirationRelativeToNow、SlidingExpiration。分别表示的是绝对的过期时间点、相对于现在多久的绝对过期时间点,有效期时长。我们注意下类型AbsoluteExpiration是DateTimeOffset不是DateTime。(*DateTimeOffset 是对于1970年1月1日0时的时间偏移量,和DateTime相比,缺少时区的概念。而此处不需要有时区相关概念,所以选用了DateTimeOffset )。

 Microsoft.Extensions.Caching.Memory

  内存缓存的实现。此处代码结构如下图所示:

  • 大逻辑

  1,缓存太大时,压缩缓存空间(个人理解)

  系统创建内存缓存对象(MemoryCache)的时候,同时创建GcNotification对象,之后GcNotification对象立马失效。GC需要析构的时候,会调用GcNotification的析构函数,析构函数被调用后会执行CallBack函数(定义在MemoryCache),之后再次注册析构函数,循环往复的如此。所以当内存占用太高的时候,缓存会缩减缓存空间。

        if (reRegister && !Environment.HasShutdownStarted)
{
GC.ReRegisterForFinalize(this);
}

注册析构函数

  2,缓存对象(MemoryCache)的释放,没有对象引用缓存的话,难免GC会回收缓存对象。那么怎么避免缓存被GC回收?下面代码的思路还是不错的

        ~MemoryCache()
{
Dispose(false);
} public void Dispose()
{
Dispose(true);
} protected virtual void Dispose(bool disposing)
{
if (!_disposed)
{
if (disposing)
{
GC.SuppressFinalize(this);
} _disposed = true;
}
} private void CheckDisposed()
{
if (_disposed)
{
throw new ObjectDisposedException(typeof(MemoryCache).FullName);
}
}

缓存对象析构

  3,IEntryLink对象的跨线程访问

  缓存过期的时候,很可能不是本线程访问的,可能是另外一个线程,通过获取IEntryLink,之后通过IChangeToken对象通知缓存,所以不同线程间必须是可以共享IEntryLink对象。此处使用的是CallContext.LogicalGetData与CallContext.LogicalSetData。关于线程见数据通信,请参考“如何实现对上下文(Context)数据的统一管理

    internal static class EntryLinkHelpers
{
private const string ContextLinkDataName = "EntryLinkHelpers.ContextLink"; public static EntryLink ContextLink
{
get
{
var handle = CallContext.LogicalGetData(ContextLinkDataName) as ObjectHandle; if (handle == null)
{
return null;
} return handle.Unwrap() as EntryLink;
}
set
{
CallContext.LogicalSetData(ContextLinkDataName, new ObjectHandle(value));
}
} internal static IEntryLink CreateLinkingScope()
{
var parentLink = ContextLink;
var newLink = new EntryLink(parent: parentLink);
ContextLink = newLink;
return newLink;
} internal static void DisposeLinkingScope()
{
var currentLink = ContextLink;
var priorLink = ((EntryLink)currentLink).Parent;
ContextLink = priorLink;
}
}

EntryLinkHelpers代码示例

未完待续......

[Asp.net 5] Caching-缓存架构与源码分析的更多相关文章

  1. Caching-缓存架构与源码分析

    Caching-缓存架构与源码分析 首先奉献caching的开源地址[微软源码] 1.工程架构 为了提高程序效率,我们经常将一些不频繁修改,但是使用了还很大的数据进行缓存.尤其是互联网产品,缓存可以说 ...

  2. MyBatis架构与源码分析<资料收集>

    1.架构与源码分析 :https://www.cnblogs.com/luoxn28/p/6417892.html .https://www.cnblogs.com/wangdaijun/p/5296 ...

  3. Volley源码解析(三) 有缓存机制的情况走缓存请求的源码分析

    Volley源码解析(三) 有缓存机制的情况走缓存请求的源码分析 Volley之所以高效好用,一个在于请求重试策略,一个就在于请求结果缓存. 通过上一篇文章http://www.cnblogs.com ...

  4. Spring Security 架构与源码分析

    Spring Security 主要实现了Authentication(认证,解决who are you? ) 和 Access Control(访问控制,也就是what are you allowe ...

  5. 关于Asp.net core配置信息读取的源码分析梳理

    概述 我们都知道asp.net core配置信息的读取离不开IConfigurationSource和IConfigurationProvider这两个类,ConfigurationSource可以提 ...

  6. java集合框架02——Collection架构与源码分析

    Collection是一个接口,它主要的两个分支是List和Set.如下图所示: List和Set都是接口,它们继承与Collection.List是有序的队列,可以用重复的元素:而Set是数学概念中 ...

  7. Java 自动拆箱 装箱 包装类的缓存问题--结合源码分析

    都0202 了 java 1.8 已经是主流 自动装箱 .拆箱已经很普遍使用了,那么有时候是不是会遇到坑呢? 我们先来看一段代码: public class TestWraperClass { pub ...

  8. Guava Cache 缓存实现与源码分析

    目录 一.概述 1.内存缓存 2.核心数据结构 二.具体实现 0.一览众山小 1.CacheBuilder 构建器 2.LocalCache 一.概述 1.内存缓存 可看作一个jdk7的concurr ...

  9. jQuery源码分析系列

    声明:本文为原创文章,如需转载,请注明来源并保留原文链接Aaron,谢谢! 版本截止到2013.8.24 jQuery官方发布最新的的2.0.3为准 附上每一章的源码注释分析 :https://git ...

随机推荐

  1. Git命令总结

    本文转载自345大神.... 查看原文 先上个图形化界面GIT工具 SourceTree下载链接 windows版 1.8.3 & Mac版 2.2.4 链接: http://pan.baid ...

  2. AFNetworking 3.0 源码解读(十一)之 UIButton/UIProgressView/UIWebView + AFNetworking

    AFNetworking的源码解读马上就结束了,这一篇应该算是倒数第二篇,下一篇会是对AFNetworking中的技术点进行总结. 前言 上一篇我们总结了 UIActivityIndicatorVie ...

  3. vue.js初探

    前言 入手2016最火前端框架之一vue.js.大概从网上找了些资料看了下vue.js,从网上的资料来看只能惊叹其发展速度太快,让我意外的是其作者是华人的前提下作品这么受欢迎. 网上的博客和教程各种组 ...

  4. java使用websocket,并且获取HttpSession,源码分析

    转载请在页首注明作者与出处 http://www.cnblogs.com/zhuxiaojie/p/6238826.html 一:本文使用范围 此文不仅仅局限于spring boot,普通的sprin ...

  5. 搭建QQ聊天通信的程序:(1)基于 networkcomms.net 创建一个WPF聊天客户端服务器应用程序 (1)

    搭建QQ聊天通信的程序:(1)基于 networkcomms.net 创建一个WPF聊天客户端服务器应用程序 原文地址(英文):http://www.networkcomms.net/creating ...

  6. 防线修建 bzoj 2300

    防线修建(1s 512MB)defense [问题描述] 近来A国和B国的矛盾激化,为了预防不测,A国准备修建一条长长的防线,当然修建防线的话,肯定要把需要保护的城市修在防线内部了.可是A国上层现在还 ...

  7. Windows下MySQL无法启动

    问题描述: 从网上下了5.7 的MySQL,在bin目录下执行 start mysqld ,弹出个cmd窗口一闪就没了,也看不清是什么报错.mysqld --install安装了服务,也启动不了.   ...

  8. 页面与ViewModel(上)

    在UWP淘宝与旺信中,笔者主要负责页面与控件的制作,这些工作看似简单,但要想做的全面细致仍然需要深入的思考.本文想分享一些在UWP旺信的制作过程中,笔者在UI页面与控件制作上体会到的一些心得.可能笔者 ...

  9. 模仿EF,我们用JS开发的HTML5 SQLite 访问库

    今天终于有空把demo放到了RunJS上面去.请使用google chrome观看在线演示: http://sandbox.runjs.cn/show/pekbd9zb 这个库本来是我们开发的phon ...

  10. vagrant 1.8.6 安装过程及总结遇到的坑

    下面先总结遇到的问题,这些问题如果你也遇到,可能需要搜索很多次才能找到原因. 如果想看安装过程,可以先直接跳到后面第二部分部分. 1 问题汇总: 1.1 vagrant版本过高问题. vagrant ...