首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

React-query:如何更新缓存?

React-query是一个用于管理数据的库,它提供了一种简单且强大的方式来处理数据的获取、缓存和更新。在React-query中,更新缓存的方式取决于你的具体需求和数据结构。

一般来说,React-query提供了两种更新缓存的方式:乐观更新和无效化查询。

  1. 乐观更新(Optimistic Updates):乐观更新是指在发送请求之前,先更新本地缓存中的数据,然后再发送请求到服务器。这样可以立即更新UI,给用户一种快速响应的感觉。如果请求成功,那么什么都不需要做;如果请求失败,可以通过回滚缓存来恢复之前的数据状态。
  2. 乐观更新的步骤如下:
    • 使用useMutation钩子来发送更新请求,并在onSuccess回调中更新缓存。
    • onMutate回调中,可以先备份当前的缓存数据,以便在请求失败时进行回滚。
    • onError回调中,可以根据需要进行缓存的回滚操作。
    • 乐观更新的优势是用户体验好,但需要注意处理请求失败的情况。
  • 无效化查询(Invalidating Queries):无效化查询是指在数据发生变化时,手动使相关的查询失效,以触发重新获取数据并更新缓存。这种方式适用于需要保持数据一致性的场景,比如在数据更新后需要立即刷新相关页面。
  • 无效化查询的步骤如下:
    • 使用useMutation钩子来发送更新请求,并在onSuccess回调中使相关的查询失效。
    • 在相关的查询中使用useQuery钩子,并设置enabled选项为false,以便手动触发查询。
    • 在更新请求成功后,通过调用queryClient.invalidateQueries方法来使相关的查询失效。
    • 无效化查询的优势是保持数据一致性,但需要手动触发查询。

综上所述,React-query提供了乐观更新和无效化查询两种方式来更新缓存。具体选择哪种方式取决于你的业务需求和数据更新的时机。更多关于React-query的信息和使用示例,你可以参考腾讯云的React-query产品介绍

页面内容是否对你有帮助?
有帮助
没帮助

相关·内容

如何以正确姿势引入缓存更新

互联网业务系统在应对大并发时候通常会选择引入缓存,当然可以Scale UP,但是响应成本上升,引入缓存是一种比较经济有效方法。...在面对各种缓存更新与访问策略时候我们可能会眼花缭乱,不合适的缓存更新策略可能达不到预期效果。 为什么要引入缓存呢? DB查询慢,通过分库分表或者对数据库进行垂直扩展,通过索引加速查询速度。...基于缓存可以轻松实现复杂查询。 引入缓存钱我们最好问自己三个问题 系统是否存在读多写少? 数据是否写入一次,多次读取? 数据是否始终唯一?...1 数据访问策略 1.1 Cache-Aside image.png Cache Aside作为最常见一种缓存更新策略,在后台使用最为广泛。...假设更新时间为m,单位为秒,更新因子为p(范围0-1) 1 应用程序访问Cache,如果距离上次更新时间小于m*p,那么可以直接使用Cache数据 2 如果距离上次访问时间大于m*p,小于m,那么触发异步更新

1.2K30

缓存层场景实战读缓存如何更新缓存+缓存的高可用设计+监控

◆ 如何更新缓存 更新缓存的步骤特别简单,共两步:更新数据库和更新缓存。但这简单的两步中需要考虑很多问题。 1)先更新数据库还是先更新缓存更新缓存时先删除还是直接更新?...◆ 组合1:先更新缓存,再更新数据库 对于这个组合,会遇到这种情况:假设第二步更新数据库失败了,要求回滚缓存更新,这时该怎么办呢?...2)线程A将缓存中的值更新成b,且保存了原来的值a,然后更新数据库。 3)线程B将缓存中的值更新成c,且保存了原来的值b,然后更新数据库。...◆ 组合5:先删除缓存更新数据库,再删除缓存 还有一个方案,就是先删除缓存,再更新数据库,再删除缓存。...1)删除缓存数据后变相出现缓存击穿,此时该怎么办?此问题在前面已经给出了方案。 2)删除缓存失败如何重试?这个重试可以做得复杂一点,也可以做得简单一点。

79610
  • 缓存层场景实战读缓存如何更新缓存+缓存的高可用设计+监控

    如何更新缓存 更新缓存的步骤特别简单,共两步:更新数据库和更新缓存。但这简单的两步中需要考虑很多问题。 1)先更新数据库还是先更新缓存更新缓存时先删除还是直接更新?...组合1:先更新缓存,再更新数据库 对于这个组合,会遇到这种情况:假设第二步更新数据库失败了,要求回滚缓存更新,这时该怎么办呢?...组合5:先删除缓存更新数据库,再删除缓存 还有一个方案,就是先删除缓存,再更新数据库,再删除缓存。...1)删除缓存数据后变相出现缓存击穿,此时该怎么办?此问题在前面已经给出了方案。 2)删除缓存失败如何重试?这个重试可以做得复杂一点,也可以做得简单一点。...本文给大家讲解的内容是缓存层场景实战,读缓存如何更新缓存+缓存的高可用设计+缓存的监控 下篇文章给大家讲解的内容是缓存层场景实战,写缓存,业务场景:如何以最小代价解决短期高频写请求 觉得文章不错的朋友可以转发此文关注小编

    82230

    你是如何更新缓存的?看懂这篇缓存读写策略

    也许你会觉得缓存读写很简单: 先读缓存缓存不命中就查DB,查到了就回种缓存 先删缓存,再更新DB,而后续操作会把数据再装载到缓存 这是错误的。最简单的两个并发操作:更新&查询。...更新操作删除缓存后,查询操作没有命中缓存,先把老数据读出来后放到缓存,然后更新操作更新了数据库。于是,缓存中的数据还是老数据,导致缓存中的数据是脏的,而且还一直这样脏下去。...一个查询操作,一个更新操作的并发 首先,没有了删除cache数据的操作,而是先更新数据库中的数据,此时,缓存依然有效,所以,并发的查询操作拿的是没有更新的数据,但是,更新操作马上让缓存的失效了,后续的查询操作再把数据从数据库中拉出来...为什么不是写DB后更新缓存?...则用缓存服务自己来加载,从而对应用方是透明的 2.2 Write Through 和Read Through相仿,不过是在更新数据时发生 当有数据更新时 如果没有命中缓存,直接更新数据库,然后返回 如果命中了缓存

    1.1K51

    谈谈缓存更新

    看到好些人在写更新缓存数据代码时,先删除缓存,然后再更新数据库,而后续的操作会把数据再装载的缓存中。然而,这个是逻辑是错误的。...试想,两个并发操作,一个是更新操作,另一个是查询操作,更新操作删除缓存后,查询操作没有命中缓存,先把老数据读出来后放到缓存中,然后更新操作更新了数据库。...这里,我们先不讨论更新缓存更新数据这两个事是一个事务的事,或是会有失败的可能,我们先假设更新数据库和更新缓存都可以成功的情况(我们先把成功的代码逻辑先写对)。...为什么不是写完数据库后更新缓存?...Write Back套路,一句说就是,在更新数据的时候,只更新缓存,不更新数据库,而我们的缓存会异步地批量更新数据库。

    1.1K20

    缓存雪崩、缓存穿透、缓存预热、缓存更新缓存降级等问题!

    ,今天给大家整理一篇关于Redis经常被问到的问题:缓存雪崩、缓存穿透、缓存预热、缓存更新缓存降级等概念的入门及简单解决方案。...(2)还有一个解决办法解决方案是:给每一个缓存数据增加相应的缓存标记,记录缓存的是否失效,如果缓存标记失效,则更新数据缓存,实例伪代码如下: ?...解释说明: 1、缓存标记:记录缓存数据是否过期,如果过期会触发通知另外的线程在后台去更新实际key的缓存; 2、缓存数据:它的过期时间比缓存标记的时间延长1倍,例:标记缓存时间30分钟,数据缓存设置为60...这样,当缓存标记key过期后,实际缓存还能把旧数据返回给调用端,直到另外的线程在后台更新完成后,才会返回新缓存。...关于缓存崩溃的解决方法,这里提出了三种方案:使用锁或队列、设置过期标志更新缓存、为key设置不同的缓存失效时间,还有一各被称为“二级缓存”的解决方法,有兴趣的读者可以自行研究。

    3.8K10

    漫谈缓存更新之道

    许多人在更新缓存时,先删除缓存,然后再更新数据库,而后续的操作会把数据再装载入缓存中。 然而,这个逻辑是错误的!!!...试想,两个并发操作,一个更新,一个查询,更新删除缓存后,查询没有命中缓存,先把旧数据读出来后放到缓存中,然后更新操作更新了数据库。于是,在缓存中的数据还是旧数据,导致缓存中持续地产生脏数据....这里,我们先不讨论更新缓存更新数据这两个事是一个事务的事,或是会有失败的可能,我们先假设更新数据库和更新缓存都可以成功的情况 更新缓存的的Design Pattern有四种 1 Cache Aside...,成功后,让缓存失效 一个查询操作,一个更新操作的并发 首先,没有了删除cache数据的操作,而是先更新数据库中的数据,此时,缓存依然有效,所以,并发的查询操作拿的是没有更新的数据,但是,更新操作马上让缓存的失效了...则用缓存服务自己来加载,从而对应用方是透明的 2.2 Write Through 和Read Through相仿,不过是在更新数据时发生 当有数据更新时 如果没有命中缓存,直接更新数据库,然后返回

    3.2K31

    缓存更新的套路

    看到好些人在写更新缓存数据代码时,先删除缓存,然后再更新数据库,而后续的操作会把数据再装载的缓存中。然而,这个是逻辑是错误的。...试想,两个并发操作,一个是更新操作,另一个是查询操作,更新操作删除缓存后,查询操作没有命中缓存,先把老数据读出来后放到缓存中,然后更新操作更新了数据库。...这里,我们先不讨论更新缓存更新数据这两个事是一个事务的事,或是会有失败的可能,我们先假设更新数据库和更新缓存都可以成功的情况(我们先把成功的代码逻辑先写对)。...为什么不是写完数据库后更新缓存?...Write Back套路,一句说就是,在更新数据的时候,只更新缓存,不更新数据库,而我们的缓存会异步地批量更新数据库。

    1.3K130

    缓存更新的套路

    看到好些人在写更新缓存数据代码时,先删除缓存,然后再更新数据库,而后续的操作会把数据再装载的缓存中。然而,这个是逻辑是错误的。...试想,两个并发操作,一个是更新操作,另一个是查询操作,更新操作删除缓存后,查询操作没有命中缓存,先把老数据读出来后放到缓存中,然后更新操作更新了数据库。...这里,我们先不讨论更新缓存更新数据这两个事是一个事务的事,或是会有失败的可能,我们先假设更新数据库和更新缓存都可以成功的情况(我们先把成功的代码逻辑先写对)。...为什么不是写完数据库后更新缓存?...Write Back套路,一句说就是,在更新数据的时候,只更新缓存,不更新数据库,而我们的缓存会异步地批量更新数据库。

    2.2K70

    缓存更新的套路

    阅读本文大概需要 10 分钟 原文 | http://sina.lt/gpqN 看到好些人在写更新缓存数据代码时,先删除缓存,然后再更新数据库,而后续的操作会把数据再装载到缓存中。...试想,两个并发操作,一个是更新操作,另一个是查询操作,更新操作删除缓存后,查询操作没有命中缓存,先把老数据读出来后放到缓存中,然后更新操作更新了数据库。...这里,我们先不讨论更新缓存更新数据这两个事是不是一个事务的事,或是会有失败的可能,我们先假设更新数据库和更新缓存都可以成功的情况(我们先把成功的代码逻辑先写对)。...更新:先把数据存到数据库中,成功后,再让缓存失效。 ? 注意,我们的更新是先更新数据库,成功后,让缓存失效。那么,这种方式是否可以避免文章前面提到过的那个问题呢?...Write Back 套路,一句说就是,在更新数据的时候,只更新缓存,不更新数据库,而我们的缓存会异步地批量更新数据库。

    1.3K20

    缓存更新策略

    问题:项目中,Redis用了缓存热点数据,持久化数据在MySQL DB中;那么Redis缓存数据什么时候更新呢? 方法A: 步骤:1....删除缓存,2.更新DB , 3.下一次读操作没有命中缓存时,更新缓存; 存在的问题:如果另外一个读任务发生在"更新DB"之前,那么缓存就"更新DB"之前的“脏数据”; 方法B:...步骤:1.更新DB,2.更新缓存; 存在的问题:如果发生并发“更新数据”,程序不能保证“更新缓存”的先后顺序,存在“脏数据”的可能性; 方法C:...步骤:1.更新DB, 2....下一次读操作没有命中缓存时,更新缓存; 存在的问题:如果在步骤1“更新DB”之前,有一个并发读任务没有命中缓存,从DB读取到“老数据”,在步骤2之后才把“老数据”更新缓存,那么缓存中就是

    1.5K00

    React-Query:啥都没干,就被淘汰了?

    作为前端缓存库中的佼佼者,React-Query一直拥有大量受众,官方推出的React-Query课程都卖出了8w+份。 但就是这样一款能打的产品,居然有被淘汰的风险,这究竟是为什么?...本文参考了文章You Might Not Need React Query[1] 前端缓存库的本质 React-Query的定位是「前端缓存库」。...在后端看来,后端负责提供数据,前端负责展示数据,那么: 数据更新后,前端应该如何渲染? 数据失效后,前端应该如何渲染?...所以,React-Query还是有用武之地。 类似的,在全栈框架Next.js中,也推荐在CSR(客户端渲染)时使用同团队开发的缓存库SWR用于数据的同步操作。...没曾想,随着这些全栈框架的爆发,前端缓存React-Query成为受伤最重的那个。 这就是所谓的 —— 毁灭你,与你何干。

    30220

    React-Query:啥都没干,就被淘汰了?

    作为前端缓存库中的佼佼者,React-Query一直拥有大量受众,官方推出的React-Query课程都卖出了8w+份。但就是这样一款能打的产品,居然有被淘汰的风险,这究竟是为什么?...前端缓存库的本质React-Query的定位是前端缓存库。如果从前端的视角来理解这个库,可能会认为它是axios加强版。但要理解这个库的本质,其实需要我们从后端的视角出发。...在后端看来,后端负责提供数据,前端负责展示数据,那么:数据更新后,前端应该如何渲染?数据失效后,前端应该如何渲染?...所以,React-Query还是有用武之地。类似的,在全栈框架Next.js中,也推荐在CSR(客户端渲染)时使用同团队开发的缓存库SWR用于数据的同步操作。...没曾想,随着这些全栈框架的爆发,前端缓存React-Query成为受伤最重的那个。这就是所谓的 —— 毁灭你,与你何干。

    46430

    Redis缓存雪崩、缓存穿透、缓存预热、缓存更新缓存降级等问题

    一、缓存雪崩 由于原有缓存失效,新缓存未到期间,比如我们设置缓存时采用了相同的过期时间,在同一时刻出现大面积的缓存过期,所有原本应该访 问缓存的请求都去查询数据库了,而对数据库CPU和内存造成巨大压力,...(2)还有一个简单方案就时将缓存失效时间分散开。 二、缓存穿透 缓存穿透是指用户查询数据,在数据库没有,自然在缓存中也不会有。...如果这些数据是一些32bit大小的数据该 如何解决?如果是64bit的呢? 对于空间的利用到达了一种极致,那就是Bitmap和布隆过滤器(Bloom Filter)。...用户直接查询事先被预热的缓存数据 解决办法 (1)直接写个缓存刷新页面,上线时手工操作下; (2)数据量不大,可以在项目启动的时候自动进行加载; (3)定时刷新缓存; 四、缓存更新 除了缓存服务器自带的缓存失效策略之外...,过期的话就去底层系统得到新数 据并更新缓存

    2.2K20

    react-query解决你一半的状态管理问题

    缓存」的性质不同于「状态」 不同于交互的中间状态,服务端状态更应被归类为「缓存」,他有如下性质: 通常以「异步」的形式请求、更新 「状态」由请求的数据源控制,不由前端控制 「状态」可以由不同组件共享...作为可以由不同组件共享的「缓存」,还需要考虑更多问题,比如: 缓存失效 缓存更新 Redux一把梭固然方便。...不仅如此,React-Query还为我们做了如下工作: 多个组件请求同一个query时只发出一个请求 缓存数据失效/更新策略(判断缓存合适失效,失效后自动请求数据) 对失效数据垃圾清理 数据的CRUD由...所以我们需要告诉React-Query,userData query对应的缓存已经失效,需要更新: import { useQuery, queryCache } from 'react-query';...这为我们带来很多好处: 使用通用的hook处理请求中间状态 多余请求合并 针对缓存更新/失效策略 Redux等「全局状态管理方案」可以更专注于「前端中间状态」处理 参考资料 [1] SWR: https

    2.6K10

    如何定时更新或者缓存Feed订阅的RSS数据?

    正好网友荒野孤灯遇到了同样的问题,我就索引度娘了一番,查询如何定时的缓存订阅数据,以减少加载时间。不过查出来的一般都是Redis,TPCache之类的。...Redis我熟,是单独的一个类似缓存数据库的东西;而TPCache又是一个插件。我也不想插件套插件了。干脆搜搜网页,弄个最简单的就好了。 建立缓存目录 在网站根目录下,新建了一个文件夹cache。...也是怕自己突然懵了 //缓存目录 - 这里注意上面建立缓存目录的路径 $cacheDir = '..../cache/'; //缓存名称 - 这里我采用了去除掉http之后的域名作为缓存文件名(因为也没有其他唯一值可以用了) $cacheName = str_replace('/','',preg_replace...://)','',$link.'.xml.cache')); //缓存时间 1小时 - 下面写秒 $ageInSeconds = 3600; //清除文件状态缓存 clearstatcache(); /

    1.4K20

    使用React-Query解决接口请求的麻烦事

    在后台更新“过期”数据 知道数据何时“过期” 尽快反映数据更新 性能优化,如分页和延迟加载数据 管理内存和服务器状态的垃圾收集 使用结构共享记忆查询结果 直到React-Query的出现,上面的问题都变得迎刃而解...React-Query React Query 是一个开箱即用,零配置的服务端状态管理库,支持Restful和GraphQL两种类型的请求,它能帮助你很好的获取、同步、管理和缓存你的远程数据。...key值,也可以在数组中,写入多项如:['repoData', '1'],这样React-Query在使用的时候会自动把它拼接为/repoData/1,这个在缓存用户访问过的页面时,非常有用。...,以及触发更新的方法。...笔者之后也会继续更新React-Query的其他使用场景,如果可以的话,不妨点个赞再走呢,这对我很重要。

    97630

    为什么是删除缓存,而不是更新缓存

    原因很简单,很多时候,在复杂点的缓存场景,缓存不单单是数据库中直接取出来的值。 比如可能更新了某个表的一个字段,然后其对应的缓存,是需要查询另外两个表的数据并进行运算,才能计算出缓存最新的值的。...另外更新缓存的代价有时候是很高的。是不是说,每次修改数据库的时候,都一定要将其对应的缓存更新一份?也许有的场景是这样,但是对于比较复杂的缓存数据计算的场景,就不是这样了。...如果你频繁修改一个缓存涉及的多个表,缓存也频繁更新。但是问题在于,这个缓存到底会不会被频繁访问到?...2)最初级的缓存不一致问题及解决方案 问题:先更新数据库,再删除缓存。如果删除缓存失败了,那么会导致数据库中是新数据,缓存中是旧数据,数据就出现了不一致。 解决思路:先删除缓存,再更新数据库。...如果数据库更新失败了,那么数据库中是旧数据,缓存中是空的,那么数据不会不一致。因为读的时候缓存没有,所以去读了数据库中的旧数据,然后更新缓存中。

    15410
    领券