• macworks
    2018-03-01
    等幂性讲的很清楚
    
     10
  • halfamonk
    2018-03-11
    私以为f(x) = f(f(x)) 这个数学公式表达幂等性不太对。因为f(f(x))应该是代表把f(x)的“结果”当作参数重新传入f()。这和文字的表述还是有区别的

    作者回复: 谢谢回复,我理解你的意思。不过数学上的幂等的确是这样描述的。参看:https://en.wikipedia.org/wiki/Idempotence

    
     6
  • 小倬
    2018-06-16
    没有理解,感觉应该用业务内容做id,比如参数,要不然下游超时,上游再次发送请求,生成的id是不同的
     5
     5
  • 幻想
    2018-03-05
    皓哥,这个专题能顺便说下分布式锁吗?我最近刚用db实现一个分布式锁。感觉不太满意。能否大概介绍一下这个主题?
    
     4
  • yunfeng
    2019-12-27
    ## 什么是幂等性
    一次和多次请求某一个资源应该具有同样的副作用(对资源变更带来连锁反应或影响):f(x) = f(f(x))。

    ## 为什么要幂等性设计
    系统解耦后,系统间服务调用存在三种状态:
        * 成功
        * 失败
        * 超时(中间状态)
    前面两种是明确的,超时是不知道什么状态,一般引起原因:
        * 请求没有到达服务方(网络延时或丢失)
        * 请求达到了服务方,服务方处理超时
        * 请求到达了服务方并且处理完返回结果,但接收方没有收到
    相关例子:订单创建、库存扣减、订单支付
    ## 怎么做幂等性设计
    * 下游提供查询接口,上游对于状态疑异订单进行查询
    * 下游系统坐幂等性设计:确保不会重复
        * 全局ID:Twitter的Snowflake算法/UUID
        * 存储冲突来解决(唯一约束)
            * 插入重复无效,`insert into … values … on DUPLICATE KEY UPDATE …`
            * 更新状态:`update table set status = “paid” where id = xxx and status = “unpaid”;`
    - HTTP幂等性
        - 只有POST需要特殊处理,其他都具有幂等性:
            - 前端生成token,后端存(唯一约束)
            - PRG模式
    展开
    
     2
  • 灯火可亲
    2019-04-01
    请问全局ID生成策略是什么了 怎么让下游系统判断发过来的请求是同一个请求了
     1
     2
  • 邓呵呵
    2018-04-27
    以前对重复提交总觉得应该放前端实现,原来后端处理就是幂等性,受教了
    
     2
  • 刘波3S
    2018-04-13
    这篇文章ID生成的讲解,解开了我一个长久的疑问,就这一段,付费199我也是愿意的。

    作者回复: 谢谢

    
     2
  • 酱了个油
    2018-03-25
    皓哥,由客户端如何生存唯一id呀,感觉twitter的算法适合服务器,有1024个服务器限制,可以给点提示吗

    作者回复: 你什么集群?1024个不够?如果实在不够加几个bit给机器id吧

     1
     2
  • MC
    2018-03-13
    问题:上游(upstream)和下游(downstream)两个词是不是用反了?如果不是,这两个术语的在这篇文章上下文中的具体意思是什么?

    作者回复: 有可能是我用错了。我的“上游”偏请求方,“下游”偏响应方。

     1
     2
  • zhuxiaozhu167
    2019-12-24
    请问皓叔,处理流程-“要做到这个事,我们需要一个存储来记录收到的交易。”这个存储,指的是一个独立于业务存储的存储服务吗?是不是还得保证业务存储与幂等服务的存储事务一致性?
    
     1
  • 陈杨
    2018-10-28
    皓哥,在保存的地方,假设db保存,一个表可以使用数据库唯一索引来报错,但是在分库分表后,数据库唯一索引就不能工作了,只有把同一个这样的请求路由到同一个库,才可以,但是这样可能跟分库分表的依据冲突,这样情况下怎么让他报错?
    
     1
  • sonnyching
    2018-05-09
    我们现在的系统设计的时候都没考虑到这些😂比如做幂等性接口的时候,下游每次收到订单都先查询一次,的确有点慢了。果然需要学习的地方还有很多呀。付费学习是值得的。
     1
     1
  • YY
    2018-03-06
    重复交易过来后,返回上次交易信息,这个上次交易信息是不是需要存储起来,这个返回信息怎样存储比较好,是否有必要把所有的返回信息都存储起来
     1
     1
  • thomas
    2018-03-02
    你这里说的副作用是指什么?

    作者回复: 你问的是哪句话的“副作用”?

     1
     1
  • 特约嘉宾
    2018-03-01
    受教了,🙏
    
     1
  • 1994
    2020-02-06
    如果这个接口是提供给前端或者是第三方使用的,是不是就要提供一个获取全局ID的接口出来?
    
    
  • slark
    2020-01-28
    冥等性,从字面意思很好理解,在前面也有类似概念。函数是无副作用,函数是无状态的,请求都依赖外部参数。
    从这个角度放大到业务请求,就是一个请求是无副作用或者多次调用副作用一致。
    请求可以有成功,失败,超时三种。
    POST请求通常无法保持冥等。
    要确保请求的冥等,需要通过一些手段来记录,追踪请求。通过一个全局的ID是比较合理的。该ID可通过算法生成,可以在不同阶段生成,但要全局唯一且足够高效,用中间的生成器不合理。
    可以采用分布式的long类型生成算法,以时间,机器号,进程号,生成编号等方式生成。
    最后,要保障存储id系统是可靠的,避免后续追踪查询问题
    展开
    
    
  • Geek_Heiko
    2020-01-07
    "幂等性设计"产生的大背景是: 服务请求方相对于被请求方的等待超(不明确请求结果)而多次发送同一个请求,从而导致返回多个不同的处理结果,而实际的多个请求只为返回一个明确处理结果的情况。由此,我们导出幂等设计的含义是,使得服务被调用方对于多个相同的请求能够返回一个相同的处理结果。但本文中很巧妙地使用:”副作用“这个词汇,即文中的含义是:"一个服务被多次调用和第一次调用所产生的副作用是一样的"。这里,我个人的理解是,幂等设计原本就是针对于不正常的服务调用(等待超时)的一种预防手段,一般正常情况下,这种"手段"是要带来一定的"副作用"的,如,为了判定多次请求的是同一个目的,我们得在系统中额外添加一个能够产生全局唯一 id 的功能,每个相同的请求都得附上该 id,然后,服务被调用方的服务相应每次都得获得该 id,根据处理情况对应地进行结果返回或丢弃等,为了防止每次服务被调用都需要查询该 id 的操作,文中推荐使用的存储冲突报错的机制,及通过多次存储同一个 id 报错的方式实现服务的高效幂等性设计。
    以上,可以推出幂等性设计的关键技术要点是:生成全局唯一 id 及其存储(读写)。这里的若是分布式系统中服务,由于其要求系统中的服务要设计成"无状态"的,所以,其幂等设计也得是"分布式"的。关于全局 id 的生成,这里推荐使用的是Twitter 的开源项目 Snowflake,其设计初衷就是面向分布式的唯一 id 生成算法;关于全局 id 的存储,这里给出的参考方案是采用关系性数据库或key-value的 NoSQL(MongoDB)。
    展开
    
    
  • 知行合一
    2020-01-03
    实现幂等性的两种方式:1 服务提供方提供查询接口供调用方使用,2使用全局性唯一ID检验来实现幂等性。页面防止重复提交使用token其实就是方式二。我们在消费消息时,是用组合业务属性唯一来实现幂等的。
    
    
我们在线,来聊聊吧