首页
学习
活动
专区
圈层
工具
发布
  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    API设计:先思考再编码

    GET 用于检索资源,POST创建一个,PUT 和PATCH 来更新现有的资源,DELETE删除东西。 头部Header:包含有关客户端或服务器的信息。...参数:在端点中用于指定动态参数,如ID或查询搜索。 响应:内容类型,HTTP状态代码和主体数据。 除此之外,蜜蜂是一个协作平台,用于创建、呈现、测试和服务您的API。...但在你开始启动你的系统之前,这里有一些小提示: 该做什么和不该做什么 这里是简单设计规则和最佳实践: 1.将端点操作视为CRUD(L)操作 我们的/cakes/端点可能有创建,读取,更新,删除和列表操作...你可以使用HTTP动词和URL来构造这些动作,例如: 列表:GET /cakes/ 创建:POST /cakes/ 阅读:GET /cakes/1/ 更新:PATCH /cakes/1/ 删除:DELETE...使用查询参数! 此功能允许您指定一些过滤列表端点,这里是一个例子: GET /cakes/?name=apple 如果实现,应该所有名称是苹果的蛋糕。 GET /cakes/?

    1.6K30

    关于“先扛住,再优化”

    关于“先扛住,再优化” 由 Ghostzhang 发表于 2010-09-13 19:00 公司内部有一个系列的培训课——海量服务之道,其中有一个思想,叫“先扛住,再优化”。...不分具体情况,一遇到需要花点时间的需求,就退缩了,还给自己一个漂亮的理由:“先扛住”。...我所理解的“先扛住”,并不是简单的先把东西搞出来就算了,而是在当前情况下已经做了80%左右的优化,一些很花时间的优化先保留接口,后期到一定阶段“再优化”。...如果一开始没有优化的意识,那么到后面“再优化”的难度将会非常的大。说不定还没到“再优化”的阶段就已经出问题了。...希望各位理解了“先扛住,再优化”思想的同学,在传播这个思想的时候,更准确的把它的意思传达清楚,而不只是字面的意思。在学习这个思想的时候,我觉得最重要的还是两个字——“态度”!

    50040

    到底是先更新数据库还是先更新缓存?

    首先一个业务场景就是数据库写多读少的场景,这种场景下采用先更新数据库再更新缓存的策略,就会导致缓存并未被读取就会被频繁的更新,极大的浪费了服务器的性能。...如果这种场景下使用先更新数据库再更新缓存的策略,也会造成服务器资源的浪费。...先删除缓存再更新数据库 先删除缓存再更新数据库的方案也存在着线程安全的问题,例如,线程A更新缓存,同时,线程B读取缓存的数据。可能会出现下面的执行顺序。...先更新数据库再删除缓存 首先,这种方式也有极小的概率发生数据库数据和缓存数据不一致的情况,例如,线程A做查询操作,线程B执行更新操作,其执行的顺序如下所示。...推荐使用 在实际的生产环境中,推荐 使用先更新数据库再删除缓存 的操作。那么,我们该如何解决这种策略下的问题呢?

    1.9K10

    ​到底是先更新数据库还是先更新缓存?

    首先一个业务场景就是数据库写多读少的场景,这种场景下采用先更新数据库再更新缓存的策略,就会导致缓存并未被读取就会被频繁的更新,极大的浪费了服务器的性能。...如果这种场景下使用先更新数据库再更新缓存的策略,也会造成服务器资源的浪费。...先删除缓存再更新数据库 先删除缓存再更新数据库的方案也存在着线程安全的问题,例如,线程A更新缓存,同时,线程B读取缓存的数据。可能会出现下面的执行顺序。...先更新数据库再删除缓存 首先,这种方式也有极小的概率发生数据库数据和缓存数据不一致的情况,例如,线程A做查询操作,线程B执行更新操作,其执行的顺序如下所示。...推荐使用 在实际的生产环境中,推荐 使用先更新数据库再删除缓存 的操作。那么,我们该如何解决这种策略下的问题呢?

    2.7K20

    高并发场景下,到底先更新缓存还是先更新数据库?

    踩坑一:先更新数据库,再更新缓存 如果同时有两个写请求需要更新数据,每个写请求都先更新数据库再更新缓存,在并发场景可能会出现数据不一致的情况。...踩坑二:先删缓存,再更新数据库 如果写请求的处理流程是先删缓存再更新数据库,在一个读请求和一个写请求并发场景下可能会出现数据不一致情况。...先删缓存,再更新数据库 如上图的执行过程: (1)写请求删除缓存数据; (2)读请求查询缓存未击中(Hit Miss),紧接着查询数据库,将返回的数据回写到缓存中; (3)写请求更新数据库。...踩坑三:先更新数据库,再删除缓存 在实际的系统中针对写请求还是推荐先更新数据库再删除缓存,但是在理论上还是存在问题,以下面这个例子说明。...先更新数据库,再删除缓存 如上图的执行过程: (1)读请求先查询缓存,缓存未击中,查询数据库返回数据; (2)写请求更新数据库,删除缓存; (3)读请求回写缓存; 整个流程操作下来发现数据库age为20

    90150

    58一面:Redis数据更新,是先更新数据库还是先更新缓存?

    5、redis作为高速缓存和数据库的数据一致性的问题,如果数据更新的话是先更新数据库还是先更新缓存?若果先更新数据库再更新缓存会涉及什么问题 基础部分: 1、hashMap底层?...7、平时建mysql表的时候会考虑一些什么? 8、写sql语句的时候where会考虑什么? ---- redis作为高速缓存和数据库的数据一致性的问题,如果数据更新的话是先更新数据库还是先更新缓存?...在这里,我们讨论三种更新策略: 先更新数据库,再更新缓存 先删除缓存,再更新数据库 先更新数据库,再删除缓存 应该没人问我,为什么没有先更新缓存,再更新数据库这种策略。...(1)先更新数据库,再更新缓存 这套方案,大家是普遍反对的。为什么呢?有如下两点原因。...接下来讨论的就是争议最大的,先删缓存,再更新数据库。还是先更新数据库,再删缓存的问题。 (2)先删缓存,再更新数据库 该方案会导致不一致的原因是。

    2.8K40

    高并发场景下,到底先更新缓存还是先更新数据库?

    踩坑一:先更新数据库,再更新缓存 如果同时有两个写请求需要更新数据,每个写请求都先更新数据库再更新缓存,在并发场景可能会出现数据不一致的情况。 ?...踩坑二:先删缓存,再更新数据库 如果写请求的处理流程是先删缓存再更新数据库,在一个读请求和一个写请求并发场景下可能会出现数据不一致情况。 ?...先删缓存,再更新数据库 如上图的执行过程: (1)写请求删除缓存数据; (2)读请求查询缓存未击中(Hit Miss),紧接着查询数据库,将返回的数据回写到缓存中; (3)写请求更新数据库。...踩坑三:先更新数据库,再删除缓存 在实际的系统中针对写请求还是推荐先更新数据库再删除缓存,但是在理论上还是存在问题,以下面这个例子说明。 ?...先更新数据库,再删除缓存 如上图的执行过程: (1)读请求先查询缓存,缓存未击中,查询数据库返回数据; (2)写请求更新数据库,删除缓存; (3)读请求回写缓存; 整个流程操作下来发现数据库age为20

    99220

    高并发场景下,到底先更新缓存还是先更新数据库?

    踩坑一:先更新数据库,再更新缓存 如果同时有两个写请求需要更新数据,每个写请求都先更新数据库再更新缓存,在并发场景可能会出现数据不一致的情况。 ?...踩坑二:先删缓存,再更新数据库 如果写请求的处理流程是先删缓存再更新数据库,在一个读请求和一个写请求并发场景下可能会出现数据不一致情况。 ?...先删缓存,再更新数据库 如上图的执行过程: (1)写请求删除缓存数据; (2)读请求查询缓存未击中(Hit Miss),紧接着查询数据库,将返回的数据回写到缓存中; (3)写请求更新数据库。...踩坑三:先更新数据库,再删除缓存 在实际的系统中针对写请求还是推荐先更新数据库再删除缓存,但是在理论上还是存在问题,以下面这个例子说明。 ?...先更新数据库,再删除缓存 如上图的执行过程: (1)读请求先查询缓存,缓存未击中,查询数据库返回数据; (2)写请求更新数据库,删除缓存; (3)读请求回写缓存; 整个流程操作下来发现数据库age为20

    4.9K21

    到底先修改MySQL还是先修改Redis?

    「更新」的话调用Redis的set方法,新值替换旧值;「删除」直接删除原来的缓存,下次查询的时候重新读取数据库,然后再更新Redis。 结论:推荐直接使用「删除」操作。...因为使用「更新」操作的话,你会面临两种选择 先更新缓存,再更新数据库 先更新数据库,再更新缓存 第1种不用考虑了,下面讨论一下「先更新数据库,再更新缓存」这种方案。...明确这个问题之后,摆在我们面前的就只有两个选择了: 先更新数据库,再删除缓存 先删除缓存,再更新数据库 2.2....先更新数据库,再删除缓存 这种方式可能存在以下两种异常情况 更新数据库失败,这时可以通过程序捕获异常,直接返回结果,不再继续删除缓存,所以不会出现数据不一致的问题 更新数据库成功,删除缓存失败。...先删除缓存,再更新数据库 这种方式可能存在以下两种异常情况 删除缓存失败,这时可以通过程序捕获异常,直接返回结果,不再继续更新数据库,所以不会出现数据不一致的问题 删除缓存成功,更新数据库失败。

    2.8K90
    领券