Caching-缓存架构与源码分析

Caching-缓存架构与源码分析

首先奉献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),之后再次注册析构函数,循环往复的如此。所以当内存占用太高的时候,缓存会缩减缓存空间。

 注册析构函数

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

 缓存对象析构

  3,IEntryLink对象的跨线程访问

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

 EntryLinkHelpers代码示例

时间: 2024-07-30 13:52:47

Caching-缓存架构与源码分析的相关文章

MyBatis架构与源码分析&lt;资料收集&gt;

1.架构与源码分析 :https://www.cnblogs.com/luoxn28/p/6417892.html .https://www.cnblogs.com/wangdaijun/p/5296830.html 2.执行器篇:https://blog.csdn.net/qingtian211/article/details/81838042 3.插件篇:https://www.cnblogs.com/xrq730/p/6984982.html 4.缓存篇:https://www.cnblo

java集合框架07——Map架构与源码分析

前几节我们对Collection以及Collection中的List部分进行了分析,Collection中还有个Set,由于Set是基于Map实现的,所以这里我们先分析Map,后面章节再继续学习Set.首先我们看下Map架构图: 从图中可以看出: 1. Map是一个接口,Map中存储的内容是键值对(key-value). 2. 为了方便,我们抽象出AbstractMap类来让其他类继承,该类实现了Map中的大部分API,其他Map的具体实现就可以通过直接继承AbatractMap类即可. 3.

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

Collection是一个接口,它主要的两个分支是List和Set.如下图所示: List和Set都是接口,它们继承与Collection.List是有序的队列,可以用重复的元素:而Set是数学概念中的集合,不能有重复的元素.List和Set都有它们各自的实现类. 为了方便,我们抽象出AbstractCollection类来让其他类继承,该类实现类Collection中的绝大部分方法.AbstractList和AbstractSet都继承与AbstractCollection,具体的List实现

jquery2源码分析系列目录

学习jquery的源码对于提高前端的能力很有帮助,下面的系列是我在网上看到的对jquery2的源码的分析.等有时间了好好研究下.我们知道jquery2开始就不支持IE6-8了,从jquery2的源码中可以学到很多w3c新的标准( 如html5,css3,ECMAScript).原文地址是:http://www.cnblogs.com/aaronjs/p/3279314.html 关于1.x.x版的jquery源码分析系列,本博客也转载了一个地址http://www.cnblogs.com/jav

[转]jQuery源码分析系列

文章转自:jQuery源码分析系列-Aaron 版本截止到2013.8.24 jQuery官方发布最新的的2.0.3为准 附上每一章的源码注释分析 :https://github.com/JsAaron/jQuery 正在编写的书 - jQuery架构设计与实现 本人在慕课网的教程(完结) jQuery源码解析(架构与依赖模块) 64课时 jQuery源码解析(DOM与核心模块)64课时 jQuery源码分析目录(完结) jQuery源码分析系列(01) : 整体架构 jQuery源码分析系列(

Hadoop-06-RPC机制以及HDFS源码分析

1.RPC机制 1.1.概述 RPC--远程过程调用协议,它是一种通过网络从远程计算机程序上请求服务,而不需要了解底层网络技术的协议.RPC协议假定某些传输协议的存在,如TCP或UDP,为通信程序之间携带信息数据.在OSI网络通信模型中,RPC跨越了传输层和应用层.RPC使得开发包括网络分布式多程序在内的应用程序更加容易. RPC采用客户机/服务器模式.请求程序就是一个客户机,而服务提供程序就是一个服务器.首先,客户机调用进程发送一个有进程参数的调用信息到服务进程,然后等待应答信息.在服务器端,

zepto源码分析系列

如果你也开发移动端web,如果你也用zepto,应该值得你看看.有问题请留言. Zepto源码分析-架构 Zepto源码分析-zepto(DOM)模块 Zepto源码分析-callbacks模块 Zepto源码分析-event模块 Zepto源码分析-ajax模块 Zepto源码分析-form模块 Zepto源码分析-deferred模块 Zepto源码分析-动画(fx fx_method)模块 内容一定要200字一定要200字内容一定要200字一定要200字内容一定要200字一定要200字内容

Solr4.8.0源码分析(19)之缓存机制(二)

Solr4.8.0源码分析(19)之缓存机制(二) 前文<Solr4.8.0源码分析(18)之缓存机制(一)>介绍了Solr缓存的生命周期,重点介绍了Solr缓存的warn过程.本节将更深入的来介绍下Solr的四种缓存类型,以及两种SolrCache接口实现类. 1.SolrCache接口实现类 前文已经提到SolrCache有两种接口实现类:solr.search.LRUCache 和 solr.search.LRUCache. 那么两者具体有啥区别呢? 1.1 solr.search.LR

Nginx源码分析—架构设计思想

Nginx源码分析-架构设计思想 我任务nginx的源码可以分为三个部分,一个是在ngx_init_cycle之前,这个也算是为了重新启动nginx而准备的代码,比如说在这个时候可以接受外部的信号,也可以保存传递的参数,等等,当然在以后的函数中也考虑了是否正在重启nginx. 至于ngx_init_cycle这个函数,是一个很庞大的函数,在这个函数中可以看到调用了各个模块的钩子函数,这里又设计到了nginx结构体的使用,比如所有的模块都是ngx_module_t这个结构体,但是这个结构体中的ct