wordpress网站定制,怎么做才能设计出好的网站,拍摄宣传片的流程简要,新闻类网站怎么做缓存 缓存(Cache),就是数据交换的缓冲区,俗称的缓存就是缓冲区内的数据,一般从数据库中获取,存储于高速存储媒介上。 缓存的本质就是用空间换时间#xff0c;牺牲数据的实时性#xff0c;以服务器内存中的数据暂时代替从数据库读取最新的数据#xff0c;减少数据库IO#…缓存 缓存(Cache),就是数据交换的缓冲区,俗称的缓存就是缓冲区内的数据,一般从数据库中获取,存储于高速存储媒介上。 缓存的本质就是用空间换时间牺牲数据的实时性以服务器内存中的数据暂时代替从数据库读取最新的数据减少数据库IO减轻服务器压力减少网络延迟加快页面打开速度。 缓存的优点及作用 降低后端负载提高读写效率降低响应时间。 缓存分类 浏览器缓存 主要是存在于浏览器端的缓存 应用层缓存 使用在代码层面的Map、List、Set等进行存储实现对数据、页面、图片等资源的缓存 数据库缓存 早期的数据库如Oracle、MySQL、SQL server等数据都是存放在磁盘。虽然数据库层也有对应的缓存(例如MySQL增改查数据都会先加载到数据库中的一片空间 buffer pool)但这种缓存一般针对的是查询内容而且粒度太小一般只有表中数据没有变更的时候数据库对应的缓存才发挥作用。但这并不能减少业务系统对数据库产生的增、删、查、改的庞大IO压力。 redis、mamcached、mongodb是比较常见的缓存数据库把经常需要从数据库查询的数据、或经常更新的数据放入到缓存中这样下次查询时直接从缓存直接返回减轻数据库压力。但这些缓存数据库大多在系统关机后数据就会丢失所以大量的数据仍需存在早期的数据库中。 CPU缓存 当代计算机最大的问题是 cpu性能提升了但内存读写速度没有跟上所以为了适应当下的情况增加了cpu的L1L2L3级的缓存介于CPU和内存之间。 服务器缓存 包括代理服务器缓存和CDN缓存 代理服务器缓存代理服务器是浏览器和源服务器之间的中间服务器浏览器先向这个中间服务器发起Web请求经过处理后(比如权限验证缓存匹配等)再将请求转发到源服务器。 代理服务器缓存的运作原理跟浏览器的运作原理差不多只是规模更大。可以把它理解为一个共享缓存不只为一个用户服务一般为大量用户提供服务因此在减少响应时间和带宽使用方面很有效同一个副本会被重用多次。 CDN缓存也叫网关缓存、反向代理缓存。CDN缓存一般是由网站管理员自己部署为了让他们的网站更容易扩展并获得更好的性能。 浏览器先向CDN网关发起Web请求网关服务器后面对应着一台或多台负载均衡源服务器会根据它们的负载请求动态将请求转发到合适的源服务器上。 虽然这种架构负载均衡源服务器之间的缓存没法共享但却拥有更好的处扩展性。从浏览器角度来看整个CDN就是一个源服务器。 缓存思路 基于Redis的缓存 标准的操作方式就是查询数据库之前先查询缓存如果缓存数据存在则直接从缓存中返回如果缓存数据不存在再查询数据库然后将数据存入redis。 更新策略 缓存更新是redis为了节约内存而设计出来的一个东西主要是因为内存数据宝贵当我们向redis插入太多数据此时就可能会导致缓存中的数据过多所以需要淘汰掉部分过期的数据。 另外缓存的数据源来自于数据库,而数据库的数据是会发生变化的,因此,如果当数据库中数据发生变化,而缓存却没有同步,此时就会有一致性问题存在。 策略选择 低一致性要求——内存淘汰或过期淘汰 高一致性要求——主动更新为主、过期淘汰兜底 内存淘汰 redis自动进行当redis内存达到咱们设定的max-memery的时候会自动触发淘汰机制淘汰掉一些不重要的数据(可以自己设置策略方式) 超时剔除 当我们给redis设置了过期时间ttl之后redis会将超时的数据进行删除方便咱们继续使用缓存 主动更新 我们可以手动调用方法把缓存删掉通常用于解决缓存和数据库不一致问题 Cache Aside Pattern 人工编码方式缓存调用者在更新完数据库后再去更新缓存也称之为双写方案。 Read/Write Through Pattern : 由系统本身完成数据库与缓存的问题交由系统本身去处理。 Write Behind Caching Pattern 调用者只操作缓存其他线程去异步处理数据库实现最终一致。 Cache Aside 缓存调用者在更新数据库的同时完成对缓存的更新 一致性良好、实现难度一般 删除/更新缓存 更新缓存每次更新数据库都更新缓存会产生无效更新并且存在较大的线程安全问题。 如果是先更新数据库再更新缓存。理论上这种方式比先更新数据库再删缓存有着更高的读性能因为它事先准备好数据。但由于要更新数据库和缓存两块数据所以它的写性能就比较低而且关键在于它也会出现脏数据如下图两个并发更新操作分别出现一前一后写数据库、一后一前写缓存则最终缓存的数据是二者中前一次写入的数据不是最新的。 如果是先更新缓存再更新数据库。这种方案见Write Back策略。 删除缓存更新数据库时让缓存失效查询时再更新缓存。本质是延迟更新没有无效更新线程安全问题相对较低。 先操作数据库/先删除缓存 先操作数据库再删除缓存在满足事务原子性的情况下安全问题概率较低. 写操作先更新数据库更新成功后使缓存失效。读操作先读缓存缓存中读到了则直接返回缓存中读不到再读数据库之后再将数据库数据加载到缓存中。不过这同样存在问题查询操作未命中缓存接着读数据库老数据之后、写缓存之前此时另一个用户发起了更新操作更新了数据库并清了缓存接着查询操作将数据库中老数据更新到缓存。这就导致缓存中数据变成脏数据并且会一直脏下去直到缓存过期或发起新的更新操作。不过这个情况出现的情况比较低其需要具备以下情况 读操作读缓存失效有个并发的写操作写操作比读操作更快读操作早于写操作进入数据库晚于写操作更新缓存 实际上数据库的写操作会比读操作慢得多而且还要锁表而读操作必需在写操作前进入数据库操作而又要晚于写操作更新缓存所有的这些条件都具备的概率基本并不大。并且即使出现这个问题还有一个缓存过期时间来自动兜底。 先删除缓存再操作数据库安全问题概率较低。 假设有两个并发操作一个操作更新、另一个操作查询更新操作删除缓存后还没来得及更新数据库此时另一个用户发起了查询操作它因没有命中缓存进而从数据库读此时第一个操作还没到更新数据库的阶段读取到的是老数据接着写到缓存中导致缓存中数据变成脏数据并且会一直脏下去直到缓存过期或发起新的更新操作。 如何保证数据库与缓存操作原子性 单体系统利用事务机制 (比如方法体上添加注解 Transactional) 分布式系统利用分布式事务机制 Read/With Through 缓存与数据库集成为一个服务服务保证两者的一致性对外暴露API接口调用者调用API无需知道操作的是缓存还是数据库不关心一致性 一致性良好、实现复杂、性能一般 Write Back 缓存调用者的CRUD都针对缓存完成由独立的异步线程将缓存数据写入数据库实现最终一致。 一致性差、性能良好、实现复杂 缓存穿透 缓存穿透 缓存穿透是指客户端请求的数据在缓存中和数据库中都不存在这样缓存永远不会生效这些请求都会打到数据库。 常见的解决方案有两种 缓存空对象 优点实现简单维护方便缺点 额外的内存消耗可能造成短期的不一致 布隆过滤 优点内存占用较少没有多余key缺点 实现复杂存在误判可能 缓存空对象 当我们客户端访问不存在的数据时先请求redis但是此时redis中没有数据此时会访问到数据库但是数据库中也没有数据这个数据穿透了缓存直击数据库我们都知道数据库能够承载的并发不如redis这么高如果大量的请求同时过来访问这种不存在的数据这些请求就都会访问到数据库简单的解决方案就是哪怕这个数据在数据库中也不存在我们也把这个数据存入到redis中去这样下次用户过来访问这个不存在的数据那么在redis中也能找到这个数据就不会进入到缓存了 布隆过滤 布隆过滤器其实采用的是哈希思想来解决这个问题通过一个庞大的二进制数组走哈希思想去判断当前这个要查询的这个数据是否存在如果布隆过滤器判断存在则放行这个请求会去访问redis哪怕此时redis中的数据过期了但是数据库中一定存在这个数据在数据库中查询出来这个数据后再将其放入到redis中假设布隆过滤器判断这个数据不存在则直接返回。 这种方式优点在于节约内存空间存在误判误判原因在于布隆过滤器走的是哈希思想只要哈希思想就可能存在哈希冲突。 缓存雪崩 缓存雪崩是指在同一时段大量的缓存失效或者Redis等缓存服务宕机导致大量请求到达数据库带来巨大压力。 解决方案 给不同的Key的TTL添加随机值避免了因为采用相同的过期时间导致的缓存雪崩利用Redis集群提高服务的可用性可以使用主从架构的集群提高服务的可用性万一出现宕机可以使用从节点顶上避免因为一台Redis缓存服务宕机影响整个业务提高Redis的容灾性给缓存业务添加降级限流策略当redis发生故障的时候可以直接拒绝服务而不是继续访问数据库给业务添加多级缓存在浏览器、nginx、redis、jvm、数据库等一层层的添加缓存使用熔断机制。当流量到达一定的阈值时就直接返回“系统拥挤”之类的提示防止过多的请求打在数据库上。至少能保证一部分用户是可以正常使用其他用户多刷新几次也能得到结果。 缓存击穿 缓存击穿问题也叫热点Key问题就是一个被高并发访问并且缓存重建业务较复杂的key突然失效了无数的请求访问会在瞬间给数据库带来巨大的冲击。 常见的解决方案有两种 互斥锁逻辑过期 互斥锁 如果发生缓存击穿后第一个请求查询数据库中该数据的时候使用一个锁锁住后续的所有请求在锁未放开之前访问这个数据就让它休眠一会重新查询缓存。缺点就是在第一个线程写缓存期间其他访问该数据的线程拿不到锁就只能处于等待状态影响查询的性能因为此时会让查询的性能从并行变成了串行我们可以采用tryLock方法 double check来解决这样的问题。 优点没有额外的内存消耗保证了缓存数据库的一致性实现比较简单 缺点线程需要等待性能受影响可能有死锁风险。 逻辑过期 我们把过期时间设置在 redis的value中注意这个过期时间并不会直接作用于redis而是我们后续通过逻辑去处理。 假设线程1去查询缓存然后从value中判断出来当前的数据已经过期了此时线程1去获得互斥锁那么其他线程会进行阻塞获得了锁的线程他会开启一个新开的线程2去进行 以前的重构数据的逻辑直到新开的线程完成这个逻辑后才释放锁 而线程1直接进行返回假设现在线程3过来访问由于线程线程2持有着锁所以线程3无法获得锁线程3也直接返回过期的数据只有等到新开的线程2把重建数据构建完后其他线程才能返回更新的数据。 优点线程无需等待 缺点不能保证缓存数据库一致性有额外的内存消耗实现比较复杂。