总体思路 1、 建立一个js服务，该服务实现通用js文件的加载、依赖、缓存、更新以及复用。 2、 各个项目如果使用通用js，可（bi）以（xu）使用js服务实现加载。...1、 在页面里使用引用boot.js。这个主要是一个引导程序，用他来加载其他的js。 2、 然后看看是否有缓存信息。 3、 如果有缓存信息，那么说明这是子页。...4、 如果没有缓存信息，说明这是top页面，需要加载另一个js（bootLoad.js）。这个是真正干活的文件。这里放在配置信息和加载css、加载js的函数。然后开始各种加载。 ...8、 为啥要缓存？ 不想每个页面都去加载固定不变的东东，比如配置信息和通用函数。虽然浏览器在加载的时候会启用缓存，但是不太好控制。客户端也可以强制不用缓存。...另外用缓存，速度会更快一些，比较不用浏览器去做各种判断了。虽然判断的时间一般也挺快的。 9、 如何实现更新？ 用版本号，设定一个版本号，有更新了，改一下这个版本号就可以了。
同时也避免了每次都去更新。 3、boot.js里面根据情况调用 bootLoad.js里提供的函数。目的是为了把有可能变化的都放在 bootLoad.js 里面以便于能够控制更新。 ...如果js文件有更新，那么获取的最新版本号就会发生变化，这样就可以实现js文件的及时更新了。 ...//判断有无配置信息————没有的话，加载且缓存 13 //判断有无js文件版本号——没有的话，加载且缓存 14 //加载Nature.LoadJs.js，开始加载其他js 15...分开的目的是为了可以控制更新。 30 loads.js('/bootLoad.js?...文件的版本号，用于更新浏览器的js缓存文件。
看到好些人在写更新缓存数据代码时，先删除缓存，然后再更新数据库，而后续的操作会把数据再装载的缓存中。然而，这个是逻辑是错误的。...试想，两个并发操作，一个是更新操作，另一个是查询操作，更新操作删除缓存后，查询操作没有命中缓存，先把老数据读出来后放到缓存中，然后更新操作更新了数据库。...这里，我们先不讨论更新缓存和更新数据这两个事是一个事务的事，或是会有失败的可能，我们先假设更新数据库和更新缓存都可以成功的情况（我们先把成功的代码逻辑先写对）。...一个是查询操作，一个是更新操作的并发，首先，没有了删除cache数据的操作了，而是先更新了数据库中的数据，此时，缓存依然有效，所以，并发的查询操作拿的是没有更新的数据，但是，更新操作马上让缓存的失效了，...Write Back套路，一句说就是，在更新数据的时候，只更新缓存，不更新数据库，而我们的缓存会异步地批量更新数据库。
每天某个时段的数据流量？ 4、如果我在这边频繁刷流量，大约多长时间可以发现异常？？ 5、redis作为高速缓存和数据库的数据一致性的问题，如果数据更新的话是先更新数据库还是先更新缓存？...---- redis作为高速缓存和数据库的数据一致性的问题，如果数据更新的话是先更新数据库还是先更新缓存？...但是在更新缓存方面，对于更新完数据库，是更新缓存呢，还是删除缓存。又或者是先删除缓存，再更新数据库，其实大家存在很大的争议。...在这里，我们讨论三种更新策略： 先更新数据库，再更新缓存 先删除缓存，再更新数据库 先更新数据库，再删除缓存 应该没人问我，为什么没有先更新缓存，再更新数据库这种策略。...接下来讨论的就是争议最大的，先删缓存，再更新数据库。还是先更新数据库，再删缓存的问题。 （2）先删缓存，再更新数据库 该方案会导致不一致的原因是。
（2）还有一个解决办法解决方案是：给每一个缓存数据增加相应的缓存标记，记录缓存的是否失效，如果缓存标记失效，则更新数据缓存，实例伪代码如下： ?...解释说明： 1、缓存标记：记录缓存数据是否过期，如果过期会触发通知另外的线程在后台去更新实际key的缓存； 2、缓存数据：它的过期时间比缓存标记的时间延长1倍，例：标记缓存时间30分钟，数据缓存设置为60...这样，当缓存标记key过期后，实际缓存还能把旧数据返回给调用端，直到另外的线程在后台更新完成后，才会返回新缓存。...解决思路： 1、直接写个缓存刷新页面，上线时手工操作下； 2、数据量不大，可以在项目启动的时候自动进行加载； 3、定时刷新缓存； 四、缓存更新 除了缓存服务器自带的缓存失效策略之外（Redis默认的有6...中策略可供选择），我们还可以根据具体的业务需求进行自定义的缓存淘汰，常见的策略有两种： （1）定时去清理过期的缓存； （2）当有用户请求过来时，再判断这个请求所用到的缓存是否过期，过期的话就去底层系统得到新数据并更新缓存
而引入缓存后，我们在向数据库插入数据时，到底是先更新数据库还是先更新缓存呢？ 缓存的一般使用 缓存，从本质上讲，是为了更好的协调两个速度差异比较大的组件而引入的一种中间缓存层。...但是在后续更新数据的操作中，是更新完数据库，接下来更新缓存还是删除缓存？又或者是先删除缓存，再更新数据库？ 缓存更新策略 从理论上来说，给缓存设置过期时间，其实是一中最终一致性的表现。...(1) 线程A更新了数据库 (2) 线程B更新了数据库 (3) 线程B更新了缓存 (4) 线程A更新了缓存 此时就会出现数据库中的数据与缓存的数据不一致的情况，这是因为线程A先更新了数据库，可能因为网络等异常情况...，线程B更新完数据库进而更新了缓存，当线程B更新完缓存后，线程A才更新缓存，这就导致了数据库数据与缓存数据的不一致。...先删除缓存再更新数据库 先删除缓存再更新数据库的方案也存在着线程安全的问题，例如，线程A更新缓存，同时，线程B读取缓存的数据。可能会出现下面的执行顺序。
而引入缓存后，我们在向数据库插入数据时，到底是先更新数据库还是先更新缓存呢？ 缓存的一般使用 缓存，从本质上讲，是为了更好的协调两个速度差异比较大的组件而引入的一种中间缓存层。...但是在后续更新数据的操作中，是更新完数据库，接下来更新缓存还是删除缓存？又或者是先删除缓存，再更新数据库？ 缓存更新策略 从理论上来说，给缓存设置过期时间，其实是一种最终一致性的表现。...(1) 线程A更新了数据库 (2) 线程B更新了数据库 (3) 线程B更新了缓存 (4) 线程A更新了缓存 此时就会出现数据库中的数据与缓存的数据不一致的情况，这是因为线程A先更新了数据库，可能因为网络等异常情况...，线程B更新完数据库进而更新了缓存，当线程B更新完缓存后，线程A才更新缓存，这就导致了数据库数据与缓存数据的不一致。...先删除缓存再更新数据库 先删除缓存再更新数据库的方案也存在着线程安全的问题，例如，线程A更新缓存，同时，线程B读取缓存的数据。可能会出现下面的执行顺序。
许多人在更新缓存时，先删除缓存，然后再更新数据库，而后续的操作会把数据再装载入缓存中。 然而，这个逻辑是错误的!!!...试想，两个并发操作，一个更新，一个查询，更新删除缓存后，查询没有命中缓存，先把旧数据读出来后放到缓存中，然后更新操作更新了数据库。于是，在缓存中的数据还是旧数据，导致缓存中持续地产生脏数据....这里，我们先不讨论更新缓存和更新数据这两个事是一个事务的事，或是会有失败的可能，我们先假设更新数据库和更新缓存都可以成功的情况 更新缓存的的Design Pattern有四种 1 Cache Aside...，成功后，让缓存失效 一个查询操作，一个更新操作的并发 首先，没有了删除cache数据的操作，而是先更新数据库中的数据，此时，缓存依然有效，所以，并发的查询操作拿的是没有更新的数据，但是，更新操作马上让缓存的失效了...则用缓存服务自己来加载，从而对应用方是透明的 2.2 Write Through 和Read Through相仿，不过是在更新数据时发生 当有数据更新时 如果没有命中缓存，直接更新数据库，然后返回
Intent.ACTION_MEDIA_SCANNER_SCAN_FILE,android.net.Uri.fromFile(java.io.File(f)))); 这样再从APP中 就看不到刚才删除那张图片的缓存了
问题：项目中，Redis用了缓存热点数据，持久化数据在MySQL DB中；那么Redis缓存数据什么时候更新呢？ 方法A: 步骤：1....删除缓存，2.更新DB , 3.下一次读操作没有命中缓存时，更新缓存； 存在的问题：如果另外一个读任务发生在"更新DB"之前，那么缓存就"更新DB"之前的“脏数据”； 方法B:...步骤：1.更新DB，2.更新缓存； 存在的问题：如果发生并发“更新数据”，程序不能保证“更新缓存”的先后顺序，存在“脏数据”的可能性； 方法C:...下一次读操作没有命中缓存时，更新缓存； 存在的问题：如果在步骤1“更新DB”之前，有一个并发读任务没有命中缓存，从DB读取到“老数据”，在步骤2之后才把“老数据”更新到缓存，那么缓存中就是...“脏数据”； 思考：方法C采取的策略，在实际场景中发送的概率比前两种方法小很多；但是怎么完全杜绝这种问题呢？
阅读本文大概需要 10 分钟 原文 | http://sina.lt/gpqN 看到好些人在写更新缓存数据代码时，先删除缓存，然后再更新数据库，而后续的操作会把数据再装载到缓存中。...试想，两个并发操作，一个是更新操作，另一个是查询操作，更新操作删除缓存后，查询操作没有命中缓存，先把老数据读出来后放到缓存中，然后更新操作更新了数据库。...这里，我们先不讨论更新缓存和更新数据这两个事是不是一个事务的事，或是会有失败的可能，我们先假设更新数据库和更新缓存都可以成功的情况（我们先把成功的代码逻辑先写对）。...命中：应用程序从 cache 中取数据，取到后返回。 更新：先把数据存到数据库中，成功后，再让缓存失效。 ? 注意，我们的更新是先更新数据库，成功后，让缓存失效。...Write Back 套路，一句说就是，在更新数据的时候，只更新缓存，不更新数据库，而我们的缓存会异步地批量更新数据库。
一、缓存雪崩 由于原有缓存失效，新缓存未到期间，比如我们设置缓存时采用了相同的过期时间，在同一时刻出现大面积的缓存过期，所有原本应该访 问缓存的请求都去查询数据库了，而对数据库CPU和内存造成巨大压力，...（2）还有一个简单方案就时将缓存失效时间分散开。 二、缓存穿透 缓存穿透是指用户查询数据，在数据库没有，自然在缓存中也不会有。...这样就可以避免在用户请求的时候，先查询数据库，然后再将数据缓存的问题！...用户直接查询事先被预热的缓存数据 解决办法 （1）直接写个缓存刷新页面，上线时手工操作下； （2）数据量不大，可以在项目启动的时候自动进行加载； （3）定时刷新缓存； 四、缓存更新 除了缓存服务器自带的缓存失效策略之外...，过期的话就去底层系统得到新数 据并更新缓存。
有的推荐第三方框架，比如 In.js、requrieJS、sea.js、lab.js等。这个开阔了眼界，以前只知道sea.js，省去了自己搜索的麻烦。...，并且可以自动更新。 ...不知道大家有没有发现一个问题，boot.js 可以搞定其他js文件的更新，但是他自己的更新如何搞定呢？有两个方法，一个是在后面加个随机数作为参数；另一个就是一辈子都不需要修改。...我的想法就是做一个js文件服务。由这个服务实现加载js、更新js、加载顺序（依赖），还有复用。 如果我们要做五个项目，每个项目都是一个独立的站点，那么对于共用的js文件是怎么处理的呢？...我们每写一个js文件，都需要考虑要引用哪些文件吗？目前我做的项目是，由js文件服务来搞定js文件的加载，然后写点处理业务逻辑的代码就ok了。 想说的还有很多，只是思路有点乱。
踩坑一：先更新数据库，再更新缓存 如果同时有两个写请求需要更新数据，每个写请求都先更新数据库再更新缓存，在并发场景可能会出现数据不一致的情况。 ?...先更新数据库，再更新缓存 如上图的执行过程： （1）写请求1更新数据库，将 age 字段更新为18； （2）写请求2更新数据库，将 age 字段更新为20； （3）写请求2更新缓存，缓存 age 设置为...踩坑二：先删缓存，再更新数据库 如果写请求的处理流程是先删缓存再更新数据库，在一个读请求和一个写请求并发场景下可能会出现数据不一致情况。 ?...先删缓存，再更新数据库 如上图的执行过程： （1）写请求删除缓存数据； （2）读请求查询缓存未击中(Hit Miss)，紧接着查询数据库，将返回的数据回写到缓存中； （3）写请求更新数据库。...先更新数据库，再删除缓存 如上图的执行过程： （1）读请求先查询缓存，缓存未击中，查询数据库返回数据； （2）写请求更新数据库，删除缓存； （3）读请求回写缓存； 整个流程操作下来发现数据库age为20
《缓存，究竟是淘汰，还是修改？》发出后，有朋友提到，高并发的情况下，缓存的更新可能存在问题，今天简单聊聊这个话题。...（1）把token放在缓存中，每次带上token去调用接口； （2）如果token过期，需要去申请新token； （3）申请完新token，需要把新token更新到缓存里。...线上s1和s2只从缓存读取token 更新token异步，asy-Master定期更新token，避免并发更新 使用shadow-master保证token更新高可用，asy-Master挂了，asy-Backup...顶上 潜在缺点：s1/s2/asy-master直接调用同一个缓存实例，如果缓存实例变更，可能需要同步变更，导致耦合。...，并发的请求便不再更新。
踩坑一：先更新数据库，再更新缓存 如果同时有两个写请求需要更新数据，每个写请求都先更新数据库再更新缓存，在并发场景可能会出现数据不一致的情况。...先更新数据库，再更新缓存 如上图的执行过程： （1）写请求1更新数据库，将 age 字段更新为18； （2）写请求2更新数据库，将 age 字段更新为20； （3）写请求2更新缓存，缓存 age 设置为...踩坑二：先删缓存，再更新数据库 如果写请求的处理流程是先删缓存再更新数据库，在一个读请求和一个写请求并发场景下可能会出现数据不一致情况。...先删缓存，再更新数据库 如上图的执行过程： （1）写请求删除缓存数据； （2）读请求查询缓存未击中(Hit Miss)，紧接着查询数据库，将返回的数据回写到缓存中； （3）写请求更新数据库。...先更新数据库，再删除缓存 如上图的执行过程： （1）读请求先查询缓存，缓存未击中，查询数据库返回数据； （2）写请求更新数据库，删除缓存； （3）读请求回写缓存； 整个流程操作下来发现数据库age为20
可见，这个map被用作本地的一级缓存，trie是二级缓存，底层数据库是第三级，各级数据结构的界限非常清晰，这样逐级缓存数据，每一级数据向上一级提交的时机也根据业务需求做了合理的选择。...有意思的是，stateObject内部也有类似StateDB一样的二级数据缓存机制，用来缓存和更新这些State。 ?...当SetState()调用发生时，storage内部State数据被更新，相应标示为"dirty"。...StateDB作为本地存储模块，它面向业务模型，又连接底层数据库，内部利用两极缓存机制来存储和更新所有代表“账户”的stateObject对象。...stateObject除了管理着账户余额等信息之外，也用了类似的两级缓存机制来存储和更新所有的State数据。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
