缓存

NSCache：专门做缓存的类 NSCache简介： NSCache是苹果官方提供的缓存类，用法与 NSMutableDictionary的用法很相似，在AFNetworking和SDWebImage中，使用它来管理缓存。 NSCache在系统内存很低时，会自动释放一些对象（出自苹果官方文档，不过在模拟器中模拟内存警告时，不会做缓存的清理动作） 为了确保接收到内存警告时能够真正释放内存，最好调用一下removeAllObjects方法。 NScache是线程安全的，在多线程操作中，不需要对Cache加锁。 NScache的key只是做强引用，不需要实现NScopying协议。 NSCache的属性： delegate代理属性 totalCostLimit ：缓存空间的最大成本，超出上限会自动回收对象。默认值是0没有限制。 countLimit：能够缓存对象的最大数量，默认值也是0（默认没有限制）。 （当超出缓存最大成本或数量时，NSCache会把前面的数据即最开始存的给清除掉） evictsObjectsWithDiscardedContent：标示是否回收废弃的内容，默认值是YES（自动回收）。 NSCache的方法： -objectForKey：返回与键值关联的对象。 -setObject: forKey: 在缓存中设置指定键名对应的值。与可变字典不同的是

缓存系统是我们平时开发经常使用到的，也是在高并发场景下减少或防止流量对DB等底层系统冲击的最有效手段之一。下面就简单谈谈缓存系统经常提及的三个问题以及解决方案。 1.缓存穿透 首先回忆下通常情况我们设置的缓存机制，如下图所示： 缓存加载机制 这套机制，由于出于容错考虑，从存储层查不到数据则不写入缓存，这就导致每次请求不存在的数据时都要到存储层去查询。如果有黑客可以利用不存在的key，频繁请求我们的服务器，这些请求就会穿透缓存，直接打到DB上，对DB造成巨大压力甚至挂掉。这就是缓存穿透。 解决方案 有很多种方法可以有效地解决缓存穿透问题，最常见的则是采用 布隆过滤器 （bloom filter）。 布隆过滤器是将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被 这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。 另外一个更为简单粗暴的方法，如果一个查询结果空（不管是数 据不存在，还是查询异常），我们仍然把这个空结果进行缓存，但它的过期时间会很短，几分钟即可。 2.缓存雪崩 缓存雪崩是指在如果我们几乎在同一时间设置的缓存（比如缓存预热），并且设置了相同的过期时间，这就会导致缓存会在某一时刻同时失效，这个时间所有请求会全部转发到DB，DB瞬时压力过重雪崩。 解决方案 大多数系统设计者考虑用加锁或者队列的方式保证缓存的单线 程（进程）写

http://zimg.buaa.us/ GitHub Start超过2.5K。 zimg 是一套国人针对图片处理服务器而设计开发的开源程序，目的是解决图片服务中如下三个问题： 大流量：对于一些中小型网站来说，流量问题就是成本问题，图片相对于文本来说流量增加了一个数量级，省下的每一个字节都是白花花的银子。所以凡是涉及到图片的互联网应用，都应该统筹规划，降低流量节约开支。 高并发：高并发的问题在用户量较低时几乎不会出现，但是一旦用户攀升，或者遇到热点事件，比如网站被人上传了一张爆炸性的新闻图片，短时间内将会涌入大量的浏览请求，如果架构设计得不好，又没有紧急应对方案，很可能导致大量的等待、更多的页面刷新和更多请求的死循环。总的来说，就是要把图片服务的性能做得足够好。 海量存储：在介绍Facebook图片存储的文章里提到，当时Facebook用户上传图片15亿张，总容量超过了1.5PB，这样的数量级是一般企业无法承受的。虽然很难做出一个可以跟Facebook比肩的应用，但是从架构设计的角度来说，良好的拓展方案还是要有的。需要提前设计出最合适的海量图片数据存储方案和操作方便的拓容方案，以应对将来不断增长的业务需求。 以上三个问题，其实也是相互制约和钳制的，比如要想降低流量，就需要大量的计算，导致请求处理时间延长，系统单位时间内的处理能力下降；再比如为了存储更多的图片，必然要在查找上消耗资源

前言 》 Mysql并非尽善尽美，但足够灵活，能适应高要求环境，如Web应用。 》 Mysql在众多平台上运行良好，支持多种数据类型，但不支持对象类型（Mongodb支持） 》 Mysql的存储引擎可以基于表建立，以满足对数据存储，性能，特征及其他特性的各种需要。 架构逻辑视图 每个虚线框为一层，总共三层。 第一层，服务层(为客户端服务):为请求做连接处理，授权认证，安全等。 第二层，核心层:查询解析，分析，优化，缓存，提供内建函数;存储过程，触发器，视图。 第三层，存储引擎层，不光做存储和提取数据，而且针对特殊数据引擎还要做事务处理。 连接管理与安全性(第一层 服务层) > 处理流程 Δ 每个连接的查询都在一个进程中的线程完成。 Δ 服务器负责缓存线程，所以服务层不需要为每个连接新建线程。 > 认证流程　 　 优化与执行 > 在解析查询之前，服务器会“询问”是否进行了查询缓存(只能缓存SELECT语句和相应结果)。缓存过的直接返回结果，未缓存的就需要进行解析查询，优化，重新执行返回结果。 > 解析查询时会创建一个内部数据结构(树)，然后对其进行各种优化。 > 优化:重写查询，决定查询的读表顺序，选择需使用的索引。 》 Mysql并非尽善尽美，但足够灵活，能适应高要求环境，如Web应用。 》 Mysql在众多平台上运行良好，支持多种数据类型，但不支持对象类型（Mongodb支持）

何为契约？契约其实就是面向接口编程，一个类不依赖于具体实现类，而是依赖于其接口。 首先看Laravel源中有一个Contracts目录，该目录下所有文件除了异常定义以外，其余均是接口定义。 通过定义好接口，具体实现类则可以依赖于接口，只要实现了接口的类都可以成为被依赖对象。 举个例子: 比如需要对内容进行缓存，可以使用文件缓存丶Redis缓存等。 先看不使用接口的代码有什么问题。 <?php /** * 文件缓存 */ class FileCache { public function cache ( $val ) { echo 'Using File Cache: ' . $val ; } } /** * Redis缓存 */ class RedisCache { public function cache ( $val ) { echo 'Using Redis Cache: ' . $val ; } } class Article { protected $cache ; public function __construct ( FileCache $cache ) { $this - > cache = $cache ; } public function getArticles ( ) { $content = 'Hello World!' ; $this - >

---恢复内容开始--- 代码块小数据池 id is == id 就好比身份证号 i = 100 s = 'alex' print (id(i)) print (id(s)) == 比较的是两边的值是否相等 l1 = [1,2,3] l2 = [1,2,3] print (l1 == l2) s1 = 'alex' s2 = 'alex' print (s1 == s2) is 判断的是内存地址是否相同 l1 = [1,2,3] l2 = [1,2,3] print (id(l1)) print (id(l2)) print (l1 is l2) #id 相同，值一定相同 #值相同的，id不一定相同 代码块 代码块：我们所有的代码都需要依赖代码块执行。 一个文件就是一个代码块 交互式命令下一行就是一个代码块 两个机制：同一代码块下，有一个机制。不同的代码块下，遵循另一个机制 同一代码块下的缓存机制。 前提条件：同一代码块内。 机制内容：Python在执行同一个代码块的初始化对象的命令时，会检查是否其值是否已经存在，如果存在，会将其重用。换句话说：执行同一个代码块时，遇到初始化对象的命令时，他会将初始化的这个变量与值存储在一个字典中，在遇到新的变量时，会先在字典中查询记录，如果有同样的记录那么它会重复使用这个字典中的之前的这个值。所以在你给出的例子中，文件执行时（同一个代码块

** 每天十个笔记（20/0306） ** 1、 关于postman的使用问题 ，关于模拟接口的使用问题如何解决，包括模拟文件上传问题 2、 码云上面关于python的书籍 3、 图片加载库 (解决网络, 文件, res, assets等图片的获取, 解析, 展示, 缓存等需求…) 名称 概要 详情 *Picasso Github大神推荐的强大的图片下载和缓存库 Square 开源的项目,主导者是 JakeWharton. *Glide Google推荐的图片加载和缓存的库 专注于平滑滚动时的流畅加载, Google开源项目, 2014年Google I/O 上被推荐 *Fresco Facebook推荐的的Android图片加载库 自动管理图片的加载和图片的缓存.Facebook 在2015年上半年开源的图片加载库 *Android-Universal-Image-Loader 早期广泛使用的开源图片加载库 强大又灵活的Android库, 用于加载,缓存,显示图片. Volley 2013年Google I/O推荐的网络通讯框架 使用volley加载网络图片，主要用到其中的ImageLoader, NetworkImageView类, 注意它不仅仅是个图片加载库. Cube-sdk 轻量级的Android开发框架 高效方便地加载网络图片, 更简易地处理网络API请求 图片处理库

solr缓存大小的调整 1.缓存调的越大越好? 错误的 如果把内存大量的都给了solr那么操作系统的内存就会变小,操作系统可以利用空闲的内存提升io的效率,操作系统本身也有缓存 oscache,solr通过id来获取doc的时候如果可以命中oscache不发生磁盘的读写也会极大的提升速度; 大内存也可以是大垃圾,当大量内存不被命中的时候就是垃圾,而且这些垃圾会触发jvm的GC操作,GC的时候会降低整个系统的效率 查看缓存的命中情况 cumulative_hitratio: 是一个0〜1之间的数，代表请求命中缓存的百分比。 cumulative_inserts: 在缓存的整个生存期中，有多少缓存实体对象被加入的缓存当中。 cumulative_evictions: 在缓存的整个生存期中，有多少缓存实体对象从缓存中被移除。 最终衡量缓存性能的是命中率。你需要做实验调整缓存大小，但时刻要关注命中率，看命中率是不是越来越高。下面是调整缓存大小的一些提示： 如果发现cumulative_evictions比cumulative_inserts高一些，那么可以试着增加缓存大小，观察命中率，有可能是因为缓存实体被移除得太快了。 如果发现缓存的命中率很高，而且cumulative_evictions值很小，那么说明缓存大小设置有点大了。试着减少缓存大小，观察命中率，直到命中率有变化。

LFU（Least Frequently Used）算法根据数据的历史访问频率来淘汰数据，其核心思想是“如果数据过去被访问多次，那么将来被访问的频率也更高”。 通过一个队列保存内容访问频次，所有数据按访问频次排序，想次次数的按时间排。需要淘汰数据的时候直接从队列里删除频次最小的。 LRU（Least recently used，最近最少使用）算法根据数据的历史访问记录来进行淘汰数据，其核心思想是“如果数据最近被访问过，那么将来被访问的几率也更高”。 通过一个队列记录数据，新数据或再次访问的老数据放在队列头，淘汰的时候从队列尾淘汰。 LRU-K中的K代表最近使用的次数，因此LRU可以认为是LRU-1。LRU-K的主要目的是为了解决LRU算法“缓存污染”的问题，其核心思想是将“最近使用过1次”的判断标准扩展为“最近使用过K次”。 通过两个队列记录数据，一个是新数据队列，另一个是达到K次访问的队列，新数据队列可以通过FIFO方式处理也可以根据LRU方式处理，当到达K次后移动到K次队列。 http://blog.csdn.net/jake_li/article/details/50659868 http://flychao88.iteye.com/blog/1977653 LRU的改进算法LIRS http://blog.csdn.net/IT_YUAN/article/details

在vue中有个很好用的组件<keep-alive>，但是在react中官方却没有提供，可以使用react-keeper插件来实现 项目实践 使用React-Keeper还是要慎重，react-keeper加上会出现两个问题：1.状态缓存了，如果很多页面都是列表，这代表每个页面都有缓存数据，下次进入页面的时候会展示离开时的状态，那么缓存的数据量也不少，会占用浏览器内存，性能肯定会有影响，什么时候清除是个问题。插件提供了cache='parent'为父组件缓存，在父组件不解绑的情况下会维持缓存状态。那么要解决的话就要有个父组件，如果父组件是最外层组件，不会解除，那么就要改变路由了，但插件并没有提供手动消除缓存的方式，使用起来很不灵活，而且会与router3 link有些不同，总之挺麻烦的。2.样式问题，页面回来时，有些样式会缺失，利用生命周期可以解决，但componentDidMount不会执行，componentWillUpdate、render和 componentDidUpdate，如果你在这些周期里面改变数据状态，那么组件周期将一直循环下去，浏览器性能大受影响！ 下面就是转载的内容了 了解React的同学一定了解React-Router，这个几乎是React单页面应用必备的路由框架。如果有足够多的开发经验，你一定会发现React-Router的很多问题，比如：没有页面缓存