缓存

题目： 请你为 最不经常使用（LFU）缓存算法设计并实现数据结构。它应该支持以下操作：get 和 put。 get(key) - 如果键存在于缓存中，则获取键的值（总是正数），否则返回 -1。 put(key, value) - 如果键不存在，请设置或插入值。当缓存达到其容量时，则应该在插入新项之前，使最不经常使用的项无效。在此问题中，当存在平局（即两个或更多个键具有相同使用频率）时，应该去除 最近 最少使用的键。 「项的使用次数」就是自插入该项以来对其调用 get 和 put 函数的次数之和。使用次数会在对应项被移除后置为 0 。 题解： 这题其实不会做... 先记录 有机会重新写过 struct Node { int key, val, fre; Node(int x, int y, int z): key(x), val(y), fre(z) {} }; class LFUCache { public: int cap, minfreq; unordered_map<int, list<Node>::iterator> stuff; unordered_map<int, list<Node>> fre_table; LFUCache(int capacity) { cap = capacity; minfreq = 0; stuff.clear(); fre_table

“小明，多系统的session共享，怎么处理？”“Redis缓存啊！” “小明，我想实现一个简单的消息队列？”“Redis缓存啊！” “小明，分布式锁这玩意有什么方案？”“Redis缓存啊！” “小明，公司系统响应如蜗牛，咋整？”“Redis缓存啊！” 本着研究的精神，我们来分析下小明的第四个问题。 准备： Idea2019.03/Gradle6.0.1/Maven3.6.3/JDK11.0.4/Lombok0.28/SpringBoot2.2.4RELEASE/mybatisPlus3.3.0/Soul2.1.2/ Dubbo2.7.5/Druid1.2.21/Zookeeper3.5.5/Mysql8.0.11/Vue2.5/Redis3.2 难度：新手-- 战士 --老兵--大师 目标： Spring优雅整合Redis做数据库缓存 步骤： 为了遇见各种问题，同时保持时效性，我尽量使用最新的软件版本。源码地址： https://github.com/xiexiaobiao/vehicle-shop-admin 1 先说结论 Redis缓存不是金弹，若系统DB毫无压力，系统性能瓶颈不在DB上，不建议强加缓存层！ 增加业务复杂度：同一缓存必须被全部相关方法所覆盖，如订单缓存，只要涉及到订单数据更新的方法都要进行缓存逻辑处理。 同时，KV存储时，因各方法返回的类型不同

　　作者：战斗民族就是干 　　转载请注明地址：http://www.cnblogs.com/prayers/p/8982141.html 　　本篇文章我们来了解一下solr的性能方面的调优，分为Schema优化、索引更新与提交调优、索引合并性能调优、Solr缓存、Solr查询性能优化 Schema优化 　　 1、index=true比index=false在索引时占用更多的内存、索引合并和优化时间更长，索引体积也响应变的更大，如果你不需要针对该域进行检索，可以设置为index=false 　　2、如果不关心Term在文档中出现的次数对最终文档的影响可以设置omitNorms=true，即取消标准化因此对score的影响。 它能减少磁盘空间的占用并加快索引速度 　 3、如果你不需要对该域进行高亮，你还可以设置omitPositions=true进一步减小索引体积 　　4、如果只需要利用倒排索引结构根据指定的Term找到对应的document，不需要计算Term在Document中的出现频率来考虑每个索引文档的权重，那么还可以设置omitTermFreqAndPositions=true即忽略TF计算以及Term在TermVector中的位置信息，这样能够进一步减小索引体积 　　5、对于stored属性而言，在响应结果集中通过FL参数返回stored=true的域的执行开销很大

Enterprise Library: Caching Application Block 概述 Written by: Rickie Lee (rickieleemail#yahoo.com) My blog: http://www.cnblogs.com/rickie Enterprise Library 中 Caching Application Block 允许开发人员在应用程序中采用本地缓存（ Cache ），它支持内存缓存和可选的辅助存储器（ Enterprise Library Data Access Application Block 或隔离的存储器（ Isolated storage ））。该 Application Block 提供了检索、增加和删除缓存数据的所有功能，还包括可配置的有效期和清除策略（ Expiration and Scavenging Policies ）。 在创建企业级分布式应用程序时，架构师和开发人员经常面临许多挑战，缓存技术可以帮助克服如下一些挑战： 性能（ Performance ）：通过存储相关的数据尽可能靠近数据消费者，缓存提供了应用程序的性能。这样可以避免重复的数据创建、处理和传输。 可扩展性（ Scalability ）：随着应用程序需求的增加，缓存信息有助于节省资源并提高可扩展性。 可用性（ Availability ）

1、技术背景 1.1、技术举例：Memcache 1.2、技术瓶颈 memcached服务器端本身不提供分布式cache的一致性，由客户端实现提供。以余数分布式算法为例。 余数分布式算法是根据添加进入缓存时key的hash值通过特定的算法得出余数，然后根据余数映射到关联的缓存服务器，将该key-value数据保存到该服务器 1.2.1、假设有3台缓存服务器以及它们对应的余数值 Node A:0，3，6，9 Node B:1，4，7 Node C:2，5，8 1.2.2、此时添加一台服务器Node D 服务器对应的余数值发生变化，如下 Node A:0，1，2 Node B:3，4 Node C:5，6 Node C:7，8，9 根据上面的变化，发现只有余数值为0，4，5所对应的缓存服务器没有发生改变，也就是说其它余数值对应的缓存服务器发生了改变，即缓存失效，如果大量缓存失效会严重影响系统的性能，也就是缓存动荡。针对这样大片缓存失效的技术瓶颈，于是提出了一致性hash算法。缩小失效缓存范围。 2、一致性Hash算法 2.1、将hash值范围看成一个0～2 32 的圆。 2.2、将服务器节点的hash值映射到该圆上。 2.3、对数据进行缓存时，计算key的hash值，然后找到该值在圆上的位置，顺时针进行查找，将数据保存到第一个查找到的服务器。 2.4、添加一个缓存服务器，如图

本文从地图操作和要素可见性入手分析地图简化的影响因素，并基于分析的结果设计相应的缓存结构以加速地图的渲染。研究GPU环境下梯形格网的高效LOD方法，探讨简化前后节点的重组和显存中EBO数据的更新方法，最终提出一种基于 三维GIS 技术的矢量地图动态LOD渲染方法。 1 简化的影响因素 1.1 地图操作对简化的影响 本文方法依据视点进行简化，当要素与视点的位置发生变化时进行实时简化操作。用户进行地图操作时，当视点与要素的距离发生变化时进行简化，不发生变化时则可以使用缓存数据进行绘制，从而加快渲染。因此，需要讨论地图操作导致的视点与要素的距离变化情况。 (1)平移操作 平移操作可能会导致视点与要素的距离发生变化。在非俯仰状态下，平移操作不会导致视点与要素的距离发生变化;在俯仰状态下，平移操作会导致视点与要素的距离发生变化。 平移操作示意图 (2)旋转 旋转操作可能会导致视点与要素的距离发生变化。非俯仰状态下，旋转操作不会导致视点与要素的距离发生变化;俯仰状态下，旋转操作会导致视点与要素的距离发生变化。 旋转操作示意图 (3)放缩操作 放缩操作会导致视点与要素的距离发生变化。 放缩操作示意图 (4)俯仰 俯仰操作会导致视点与要素的距离发生变化。 俯仰操作示意图 综上分析可知，在非俯仰状态下，地图平移操作和旋转操作不会改变要素距视点的距离，可以使用上一帧的地图缓存进行绘制，加快其渲染速度

缓存雪崩 假设每天高峰期每秒 5000 个请求，本来缓存在高峰期可以扛住每秒 4000 个请求，但是缓存机器意外发生了全盘宕机。缓存挂了，此时 1 秒 5000 个请求全部落数据库，数据库必然扛不住，它会报一下警，然后就挂了。此时，如果没有采用什么特别的方案来处理这个故障，DBA 很着急，重启数据库，但是数据库立马又被新的流量给打死了。 通常我们在使用 Redis 的时候，都会为缓存设置过期时间，但是如果在某个时间点，有大量缓存失效，那么下一个时间点就会有大量请求访问到数据库，这种情况下，数据库可能因为访问量多大导致“崩溃”，这就是缓存雪崩。 第一种情况:缓存雪崩的事前事中事后的解决方案如下： 事前：redis 高可用，主从+哨兵，redis cluster，避免全盘崩溃。 事中：本地 ehcache 缓存 + hystrix 限流&降级，避免 MySQL 被打死。对于缓存大面积失效的情况可以设置缓存的失效时间使用随机数，避免此问题。 事后：redis 持久化，一旦重启，自动从磁盘上加载数据，快速恢复缓存数据。 第二种情况: 不设置缓存过期时间 最暴力的解决办法，缓存不设置自动过期时间，只要缓存不崩，数据库就不会崩。 设置随机过期时间 另外一个办法，就是让缓存过期时间不那么一致，比如一批缓存数据24小时后过期，那么就在这个基础上，让每条缓存的过期时间前后随机 1-6000 秒（1

规则1-减少HTTP请求 1.图片合并 1)将多个图片合并为一个图片, 2)CSS Sprites。使用CSS的background-positon属性，配合width/height显示指定位置的图片局部内容。 <div style="background-image:url('xxxxx.gif');background-position:-260px -90px; width:26px;height:24px;"></div> 3)合并后的图片，不但减少了下载次数，而且降低了总体大小，因为它减少了颜色表、格式信息等图片格式开销。 2.内嵌图片 1)使用data:URL模式 data:[<mediatype>][;base64],<data> data:URL形式无法直接被浏览器缓存，可以将其放在css样式表中，从而实现缓存，base64转换后的图片会变大。 .home{background-image:url(data:image/gif;base64,XXXXXXXXX);} 3.合并js和css文件 规则2-使用内容分发网络 规则3-使用Max-Age 1.使用Expires/Max-Age/mod_expires设定缓存时间 可以通过设置文件版本号等方法，使文件及时刷新。 规则4-压缩组件 1.gzip压缩 1)浏览器发送Accept-Encoding:gzip

只要用缓存，就可能会涉及到缓存与数据库双存储双写，你只要是双写，就一定会有数据一致性的问题，那么你如何解决一致性问题？ 面试题剖析 　　一般来说，如果允许缓存可以稍微的跟数据库偶尔有不一致的情况，也就是说如果你的系统不是严格要求 “缓存+数据库” 必须保持一致性的话，最好不要做这个方案，即：读请求和写请求串行化，串到一个内存队列里去。 　　串行化可以保证一定不会出现不一致的情况，但是它也会导致系统的吞吐量大幅度降低，用比正常情况下多几倍的机器去支撑线上请求。 Cache Aside Pattern 　　最经典的缓存+数据库读写的模式，就是 Cache Aside Pattern。 　　读的时候，先读缓存，缓存没有的话，就读数据库，然后取出数据后放入缓存，同时返回响应。 　　更新的时候，先更新数据库，然后再删除缓存。 为什么是删除缓存，而不是更新缓存？ 　　原因很简单，很多时候，在复杂点的缓存场景，缓存不单单是数据库中直接取出来的值。 　　比如可能更新了某个表的一个字段，然后其对应的缓存，是需要查询另外两个表的数据并进行运算，才能计算出缓存最新的值的。 　　另外更新缓存的代价有时候是很高的。是不是说，每次修改数据库的时候，都一定要将其对应的缓存更新一份？也许有的场景是这样，但是对于比较复杂的缓存数据计算的场景，就不是这样了。如果你频繁修改一个缓存涉及的多个表，缓存也频繁更新

Redis概述 Redis常用数据结构 Redis删除过期数据策略 Redis内存淘汰机制 Redis持久化机制 缓存问题及解决方案 Redis概述 Redis是一个开源的、基于内存的数据结构存储器，可以用作数据库、缓存和消息中间件 Redis最常用的功能 缓存 分布式锁 本文介绍使用环境 Windows 10 Redis 3.0.504 如何安装Redis就不做介绍，若不想安装Redis环境，可以使用 try redis 尝试Redis功能 CMD 启动 Redis，打开Reids目录，执行下面命令，出现下面图片代表启动成功 redis-server redis.windows.conf Redis常用数据结构 字符串(String) 用途 存放字符串/数字 常规key-value缓存应用 常规计数：订单数，商品数 常用命令 用途 set key value 设置指定 key 的值 get key 获取指定key的值 decr key 将指定的key的值递减1，若设置的值不是数字，报错 incr key 将指定的key的值递增1，若设置的值不是数字，报错 mget key1 [key2] 获取指定的key，返回多个值 哈希(Hash) 用途 hash 特别适合用于存储对象(用户信息，商品信息) 可以修改/读取对象某个值 常用命令 用途 hset key field value