缓存

缓存使用场景 针对读多写少的高并发场景，我们可以使用缓存来提升查询速度。 当我们使用Redis作为缓存的时候，一般流程是这样的： 因为这些数据是很少修改的，所以在绝大部分的情况下可以命中缓存。但是，一旦被缓存的数据发生变化的时候，我们既要操作数据库的数据，也要操作Redis的数据，所以问题来了。现在我们有两种选择： 先操作Redis的数据再操作数据库的数据 先操作数据库的数据再操作Redis的数据到 底选哪一种？首先需要明确的是，不管选择哪一种方案，我们肯定是希望两个操作要么都成功，要么都一个都不成功。不然就会发生Redis跟数据库的数据不一致的问题。 但是，Redis的数据和数据库的数据是不可能通过事务达到统一的，我们只能根据相应的场景和所需要付出的代价来采取一些措施降低数据不一致的问题出现的概率，在数据一致性和性能之间取得一个权衡。 对于数据库的实时性一致性要求不是特别高的场合，比如T+1的报表，可以采用定时任务查询数据库数据同步到Redis的方案。 由于我们是以数据库的数据为准的，所以给缓存设置一个过期时间，是保证最终一致性的解决方案。 选择方案 一、先更新数据库，再删除缓存 正常情况： 更新数据库，成功。 删除缓存，成功。 异常情况： 1.更新数据库失败，程序捕获异常，不会走到下一步，所以数据不会出现不一致。 2.更新数据库成功，删除缓存失败。数据库是新数据，缓存是旧数据

https://segmentfault.com/a/1190000017962411 来源： oschina 链接： https://my.oschina.net/bing309/blog/3223266

获取一张图片，从三个地方进行获取，首先是内存缓存，然后是文件缓存，最后才从网络中获取。 //内存缓存 public class ImageMemoryCache { /** * 从内存读取数据速度是最快的，为了更大限度使用内存，这里使用了两层缓存。 硬引用缓存不会轻易被回收，用来保存常用数据，不常用的转入软引用缓存。 */ private static final int SOFT_CACHE_SIZE = 15; // 软引用缓存容量 private static LruCache<String, Bitmap> mLruCache ; // 硬引用缓存 private static LinkedHashMap<String, SoftReference<Bitmap>> mSoftCache ; // 软引用缓存 public ImageMemoryCache(Context context) { int memClass = ((ActivityManager) context .getSystemService(Context. ACTIVITY_SERVICE )).getMemoryClass(); int cacheSize = 1024 * 1024 * memClass / 4; // 硬引用缓存容量，为系统可用内存的1/4 mLruCache = new

一、缓存 当系统的并发量上来了，如果我们频繁地去访问数据库，那么会使数据库的压力不断增大，在高峰时甚至可以出现数据库崩溃的现象。所以一般我们会使用缓存来解决这个数据库并发访问问题，用户访问进来，会先从缓存里查询，如果存在则返回，如果不存在再从数据库里查询，最后添加到缓存里，然后返回给用户，当然了，接下来又能使用缓存来提供查询功能。 而缓存，一般我们可以分为本地缓存和分布式缓存。 常用的本地缓存有 ehcache、guava cache，而我们一般都是使用 ehcache，毕竟他是纯 Java 的，出现问题我们还可以根据源码解决，并且还能自己进行二次开发来扩展功能。 常用的分布式缓存当然就是 Redis 了，Redis 是基于内存和单线程的，执行效率非常的高。 二、Spring Cache 相信如果要整合缓存到项目中，大家都会使用到 Spring Cache，它不但整合了多种缓存框架（ehcache、jcache等等），还可以基于注解来使用，是相当的方便。 缓存框架的整合在 spring-context-support 中： 缓存注解在 spring-context 中： 当然了，在 Spring 的 context 中没有整合 Redis，但是我们可以在 spring-data-redis 中找到。 但是我们都知道，不管是在 Spring 项目 还是 Spring Boot 中

正文 博主本来觉得， 《分布式之数据库和缓存双写一致性方案解析》 ，一文已经十分清晰。然而这一两天，有人在微信上私聊我，觉得应该要采用 先删缓存，再更新数据库，再删缓存 这一方案作为缓存更新策略，而不是先更新数据库，再删缓存。并且搬出了两篇大佬的文章， 《Cache Aside Pattern》 ， 《缓存与数据库不一致，咋办？》 ，希望博主能加以说明。因为问的人太多了，所以才有了这篇文章的诞生。 正文 在开始这篇文章之前，我们先自己思考一下以下两个更新策略 方案一 (1)删缓存 (2)更数据库 (3)删缓存 方案二 (1)更数据库 (2)删缓存 大家看下面的文章前，自己先思考一下， 方案一的步骤(1)有没有存在的必要 ？ 先上一个结论:方案二存在的缺点，方案一全部存在，且方案一比方案二多一个步骤，所以应该选方案二。 下面，针对 《Cache Aside Pattern》 ， 《缓存与数据库不一致，咋办？》 这两篇文章提出的论点，提出小小的质疑。这两篇文章认为方案二不行的原因，主要有以下两点 (1)方案二在步骤(2)，出现删缓存失败的情况下，会出现数据不一致的情形，如下图所示 Cache Aside Pattern方案存在什么问题？ 答：如果先操作数据库，再淘汰缓存，在原子性被破坏时： (1) 修改数据库成功了 (2) 淘汰缓存失败了 导致，数据库与缓存的数据不一致 (2

1.缓存的简介 在动态网站中,用户所有的请求,服务器都会去数据库中进行相应的增,删,查,改,渲染模板,执行业务逻辑,最后生成用户看到的页面. 当一个网站的用户访问量很大的时候,每一次的的后台操作,都会消耗很多的服务端资源,所以必须使用缓存来减轻后端服务器的压力. 缓存是将一些常用的数据保存内存或者memcache中,在一定的时间内有人来访问这些数据时,则不再去执行数据库及渲染等操作,而是直接从内存或memcache的缓存中去取得数据,然后返回给用户. 2.Django提供了6种缓存方式 开发调试缓存 内存缓存 文件缓存 数据库缓存 Memcache缓存(使用python-memcached模块) Memcache缓存(使用pylibmc模块) 经常使用的有文件缓存和Mencache缓存 2.1 各种缓存方式的配置文件说明 2.1.1 开发调试(此模式为开发调试使用,实际上不执行任何操作) settings.py文件配置 ? 1 2 3 4 5 6 7 8 9 10 CACHES = { 'default' : { 'BACKEND' : 'django.core.cache.backends.dummy.DummyCache' , # 缓存后台使用的引擎 'TIMEOUT' : 300 , # 缓存超时时间（默认300秒，None表示永不过期，0表示立即过期） 'OPTIONS'

欢迎大家前往 腾讯云社区 ，获取更多腾讯海量技术实践干货哦~ 作者：kevinxiaoyu，高级研究员，隶属腾讯TEG-架构平台部，主要研究方向为深度学习异构计算与硬件加速、FPGA云、高速视觉感知等方向的构架设计和优化。“深度学习的异构加速技术”系列共有三篇文章，主要在技术层面，对学术界和工业界异构加速的构架演进进行分析。 一、概述：通用=低效 作为通用处理器，CPU (Central Processing Unit) 是计算机中不可或缺的计算核心，结合指令集，完成日常工作中多种多样的计算和处理任务。然而近年来，CPU在计算平台领域一统天下的步伐走的并不顺利，可归因于两个方面，即自身约束和需求转移。 （1）自身约束又包含两方面，即半导体工艺，和存储带宽瓶颈。 一方面，当半导体的工艺制程走到7nm后，已逼近物理极限，摩尔定律逐渐失效，导致CPU不再能像以前一样享受工艺提升带来的红利：通过更高的工艺，在相同面积下，增加更多的计算资源来提升性能，并保持功耗不变。为了追求更高的性能，更低的功耗，来适应计算密集型的发展趋势，更多的设计通过降低通用性，来提升针对某一（或某一类）任务的性能，如GPU和定制ASIC。 另一方面，CPU内核的计算过程需要大量数据，而片外DDR不仅带宽有限，还具有较长的访问延迟。片上缓存可以一定程度上缓解这一问题，但容量极为有限。Intel通过数据预读、乱序执行

多线程：硬件基础 目录 多线程：硬件基础 一、高速缓存 二、缓存一致性协议 三、写缓冲器 一、高速缓存 现代CPU的处理性能是远远高于主内存，一次内存读或者写操作的时间内，CPU能够处理上百条指令。为了弥补CPU与内存之间性能的鸿沟，引入高速缓存（Cache）。 高速缓存的性能远远高于主内存，但是容量要小于主内存 。每个处理器都有其独立的高速缓存。有了高速缓存之后，处理器在做内存读写操作时就不必直接与主内存打交道，而是与缓存打交道（从缓存中读或写）。 缓存的数据结构相当于一个散列表，由若干桶和缓存条目组成，缓存条目又可以细分成三个部分：Data Block（缓存行）中存储了从内存中读取的或者将要写入内存的数据；Tag储存了缓存行中数据相应的内存地址的部分信息（内存地址的高位部分比特）；Flag用于表示缓存行的状态信息，有哪些中状态值下面会进一步说明。 那么，处理器如果想操作储存在主内存地址A的变量时，具体时如何与缓存打交道的呢？ 处理器把地址A解码为index，tag，offset三个数据。 首先通过index值定位到桶。 然后通过tag值比对定位到具体的缓存条目。 最后根据offset偏移量的值定位到缓存行中该变量的起始位置。 根据上述步骤如如果能够定位到相应的缓存行且所在缓存条目的Flag值表示缓存条目是有效的，我们就称相应的内存操作产生了 缓存命中 ，相反则称为 缓存未命中

1. Yahoo性能优化 http://developer.yahoo.com/performance/rules.html 1、尽量减少HTTP请求个数——须权衡 合并图片（如css sprites，内置图片使用数据）、合并CSS、JS，这一点很重要，但是要考虑合并后的文件体积。 2、使用CDN（内容分发网络） 这里可以关注CDN的三类实现：镜像、高速缓存、专线，以及智能路由器和负载均衡； 3、为文件头指定Expires或Cache-Control，使内容具有缓存性。 区分静态内容和动态内容，避免以后页面访问中不必要的HTTP请求。 4、避免空的src和href 留意具有这两个属性的标签如link，script，img，iframe等； 5、使用gzip压缩内容 Gzip压缩所有可能的文件类型以来减少文件体积 6、把CSS放到顶部 实现页面有秩序地加载，这对于拥有较多内容的页面和网速较慢的用户来说更为重要，同时，HTML规范清楚指出样式表要放包含在页面的<head />区域内； 7、把JS放到底部 HTTP/1.1 规范建议，浏览器每个主机名的并行下载内容不超过两个，而问题在于脚本阻止了页面的平行下载，即便是主机名不相同 8、避免使用CSS表达式 页面显示和缩放，滚动、乃至移动鼠标时，CSS表达式的计算频率是我们要关注的。可以考虑一次性的表达式或者使用事件句柄来代替CSS表达式。

一般我们的热点数据用到缓存，都存在一个问题。 就是在数据更新时，到底是 1，先更新db再更新缓存 2，先更新缓存再更新db 3，更新db前让缓存无效 4，更新db后让缓存无效 1，先更新db再更新缓存的情况 存在一个问题，当对一条数据进行更新时，无法保证前面的线程先执行完 然后下一个线程再执行的情况 可能存在这样一种情况：线程1先更新了db但还没更新缓存，然后线程2更新了db又更新了缓存，然后线程1更新了缓存 这种情况还是比较常发生的，因为两个线程同时执行一个方法，时间上的先后难以保证，运行完此方法的先后。因此不推荐。 2，先更新缓存再更新db 这种存在一个问题，假设线程1更新了缓存，但还没更新db，然后线程2更新了缓存又更新了db，然后线程1再更新db 这样就导致了线程不安全的问题，跟1类似，因此不推荐。 3，更新db前让缓存无效 假设线程1先让缓存失效，还没更新db，此时有大量的线程2,3,4,5去查缓存，没有查到就会直接查数据库，造成缓存穿透问题 因此不推荐。 4，更新db后让缓存无效 线程1更新db后，将缓存无效了，然后再查了一次缓存，线程2更新db后，将缓存无效了， 此时线程1还是旧的数据，这种情况的发生是线程2的写db速度比线程1的读还快，一般这种情况概率比较低 所以推荐这种做法。 来源： oschina 链接： https://my.oschina.net/u