服装网站推广方案,广告传媒公司,珠海工商年检到哪个网站做,四平市城市建设档案馆网站前言
在网络技术中基于浏览器的B/S结构无论在PC端还是手机端都充当着至关重要的角色。 PC端自不必说#xff0c;手机中很多应用虽然是以APP的形式存在#xff0c;但它采用的还是B/S结构。如今日头条、微信的朋友圈等#xff0c;这些应用在内部封装了浏览器#xff0c;后端…前言
在网络技术中基于浏览器的B/S结构无论在PC端还是手机端都充当着至关重要的角色。 PC端自不必说手机中很多应用虽然是以APP的形式存在但它采用的还是B/S结构。如今日头条、微信的朋友圈等这些应用在内部封装了浏览器后端仍然是 Web站点。
在大型网站和复杂系统的开发中Java无疑具有很大的优势而在lava的Web框架中 Sprig MVC 以其强大的功能和简单且灵活的用法受到越来越多开发者的青睐。
Spring MVC入门很简单但是要想真正使用好却并非易事而且现在也没有全面、深入地使用资料以致在实际使用的过程中程序员经常会遇到各种各样的问题而不知道如何解决。对 Spring MVC 这样的开源项目来说。最好的学习方法当然是分析它的源代码分析透源代码不仅可以让我们更灵活地使用 Spring MVC来开发高质量的产品而且可以学习到其中的很多优秀的编程技巧和设计理念。
本次分享PDF文档资料除了分析Spring MVC的源代码还系统地介绍了各种网站架构的演变以及 Web开发中所涉及的协议和Tomcat的实现方法现在很多程序员都想了解这方面的知识但苦于缺乏通俗易懂的资料而且这些也是程序员达到更高的层次所需要的知识。
Cache aside
Cache aside也就是旁路缓存是比较常用的缓存策略。
1读请求常见流程 应用首先会判断缓存是否有该数据缓存命中直接返回数据缓存未命中即缓存穿透到数据库从数据库查询数据然后回写到缓存中最后返回数据给客户端。
2写请求常见流程 首先更新数据库然后从缓存中删除该数据。
看了写请求的图之后有些同学可能要问了为什么要删除缓存直接更新不就行了这里涉及到几个坑我们一步一步踩下去。
Cache aside踩坑
Cache aside策略如果用错就会遇到深坑下面我们来逐个踩。
踩坑一先更新数据库再更新缓存
如果同时有两个写请求需要更新数据每个写请求都先更新数据库再更新缓存在并发场景可能会出现数据不一致的情况。 如上图的执行过程
1写请求1更新数据库将 age 字段更新为18
2写请求2更新数据库将 age 字段更新为20
3写请求2更新缓存缓存 age 设置为20
4写请求1更新缓存缓存 age 设置为18
执行完预期结果是数据库 age 为20缓存 age 为20结果缓存 age为18这就造成了缓存数据不是最新的出现了脏数据。
踩坑二先删缓存再更新数据库
如果写请求的处理流程是先删缓存再更新数据库在一个读请求和一个写请求并发场景下可能会出现数据不一致情况。 如上图的执行过程
1写请求删除缓存数据
2读请求查询缓存未击中(Hit Miss)紧接着查询数据库将返回的数据回写到缓存中
3写请求更新数据库。
整个流程下来发现数据库中age为20缓存中age为18缓存和数据库数据不一致缓存出现了脏数据。
踩坑三先更新数据库再删除缓存
在实际的系统中针对写请求还是推荐先更新数据库再删除缓存但是在理论上还是存在问题以下面这个例子说明。 如上图的执行过程
1读请求先查询缓存缓存未击中查询数据库返回数据
2写请求更新数据库删除缓存
3读请求回写缓存
整个流程操作下来发现数据库age为20缓存age为18即数据库与缓存不一致导致应用程序从缓存中读到的数据都为旧数据。
但我们仔细想一下上述问题发生的概率其实非常低因为通常数据库更新操作比内存操作耗时多出几个数量级上图中最后一步回写缓存set age 18速度非常快通常会在更新数据库之前完成。
如果这种极端场景出现了怎么办我们得想一个兜底的办法缓存数据设置过期时间。通常在系统中是可以允许少量的数据短时间不一致的场景出现。
Read through
在 Cache Aside 更新模式中应用代码需要维护两个数据源头一个是缓存一个是数据库。而在 Read-Through 策略下应用程序无需管理缓存和数据库只需要将数据库的同步委托给缓存提供程序 Cache Provider 即可。所有数据交互都是通过抽象缓存层完成的。 如上图应用程序只需要与Cache Provider交互不用关心是从缓存取还是数据库。
在进行大量读取时Read-Through 可以减少数据源上的负载也对缓存服务的故障具备一定的弹性。如果缓存服务挂了则缓存提供程序仍然可以通过直接转到数据源来进行操作。
Read-Through 适用于多次请求相同数据的场景这与 Cache-Aside 策略非常相似但是二者还是存在一些差别这里再次强调一下
在 Cache-Aside 中应用程序负责从数据源中获取数据并更新到缓存。在 Read-Through 中此逻辑通常是由独立的缓存提供程序Cache Provider支持。
Write through
Write-Through 策略下当发生数据更新(Write)时缓存提供程序 Cache Provider 负责更新底层数据源和缓存。
缓存与数据源保持一致并且写入时始终通过抽象缓存层到达数据源。
Cache Provide 点击领取2024完整开源项目《一线大厂Java面试题解析后端开发学习笔记最新架构讲解视频实战项目源码讲义》 r类似一个代理的作用。 Write behind
Write behind在一些地方也被成为Write back 简单理解就是应用程序更新数据时只更新缓存 Cache Provider每隔一段时间将数据刷新到数据库中。说白了就是延迟写入。 如上图应用程序更新两个数据Cache Provider 会立即写入缓存中但是隔一段时间才会批量写入数据库中。
这种方式有优点也有缺点 优点是数据写入速度非常快适用于频繁写的场景。 缺点是缓存和数据库不是强一致性对一致性要求高的系统慎用。
最后
码字不易觉得有帮助的可以帮忙点个赞让更多有需要的人看到
又是一年求职季在这里我为各位准备了一套Java程序员精选高频面试笔试真题来帮助大家攻下BAT的offer题目范围从初级的Java基础到高级的分布式架构等等一系列的面试题和答案用于给大家作为参考
以下是部分内容截图
位准备了一套Java程序员精选高频面试笔试真题来帮助大家攻下BAT的offer题目范围从初级的Java基础到高级的分布式架构等等一系列的面试题和答案用于给大家作为参考
以下是部分内容截图 [外链图片转存中…(img-3WfGiIyc-1709733399500)] 本文已被CODING开源项目【一线大厂Java面试题解析核心总结学习笔记最新讲解视频实战项目源码】收录
