电商课题:幂等性

标签: 电商 幂等 | 发表时间:2012-11-22 23:52 | 作者:旁观者
出处:http://www.cnblogs.com/zhengyun_ustc/
@郑昀汇总
关键词:
idempotency,BASE,
 

一. 断言:

幂等性的数学表达:f(f(x)) = f(x)。
幂等性是系统接口对外的一种承诺。
幂等性指的是,使用相同参数对同一资源重复调用某个接口的结果与调用一次的结果相同。
幂等性的一个实现是,使你的接口必须返回 0(成功),即使这时资源或动作已经停止并且无工作要完成。
 
二. 电商常见问题:
HTTP POST 操作既不是安全的,也不是幂等的(至少在HTTP规范里没有保证)。
当我们因为反复刷新浏览器导致多次提交表单,多次发出同样的POST请求,导致远端服务器重复创建出了资源。 
所以,对于电商应用来说,第一对应的后端 WebService 一定要做到幂等性,第二服务器端收到 POST 请求, 在操作成功后必须302跳转到另外一个页面,这样即使用户刷新页面,也不会重复提交表单。
2.2. 集群环境下的 定时任务幂等性
分布式环境下,定时任务或异步处理如何保持幂等性?
 
三. 把分布式事务分解为具有幂等性的异步消息处理:
电商的很多业务,考虑更多的是 BASE(即Basically Available、Soft state、和Eventually consistent),而不是 ACID(Atomicity、Consistency、Isolation和 Durability)。即为了满足高负载的用户访问,我们可以容忍短暂的数据不一致。
那怎么做呢?  
第一,不做分布式事务,代价太大。
第二,不一定需要实时一致性,只需要保证最终的一致性即可。
第三,“通过状态机和严格的有序操作,来最大限度地降低不一致性”。
第四,最终一致性(Eventually Consistent)通过异步事件做到。
如果消息具有操作幂等性,也就是一个消息被应用多次与应用一次产生的效果是一样的话,那么 把不需要同步执行的事务交给异步消息推送和订阅者集群来处理即可。假如消息处理失败,那么就消息重播,由于幂等性,应用多次也能产生正确的结果。
实际情况下,消息很难具有幂等性,解决方法是使用另一个表记录已经被成功应用的消息,即消息队列和消息应用状态表一起来解决问题。
 
参考资源:
1)weidagang2046,博客园, 理解HTTP幂等性
2)相关设计模式“Synchronized Token(简而言之,就是客户端的每一次 Request 里,必须携带一个服务器端给出的 Hash Code 作为 Token,这个 Token 只能用一次,不能重复使用) ”和“幂等接收器,Idempotent Receiver ”;
3)针对 POST ,请参考  HTTPLR(由Bill de hÓra提出)、 Mark Nottingham的POE(POST Once Exactly)和Paul Prescod的 HTTP中的可靠传递。(另一个值得一提的是Yaron Goland的 SOA-Rity);
4)淘宝核心系统团队博客,2010, 用消息队列和消息应用状态表来消除分布式事务

本文链接

相关 [电商 幂等] 推荐:

电商课题:幂等性

- - 博客园_旁观者
幂等性的数学表达:f(f(x)) = f(x). 幂等性是系统接口对外的一种承诺. 幂等性指的是,使用相同参数对同一资源重复调用某个接口的结果与调用一次的结果相同. 幂等性的一个实现是,使你的接口必须返回 0(成功),即使这时资源或动作已经停止并且无工作要完成. 防范 POST 重复提交. HTTP POST 操作既不是安全的,也不是幂等的(至少在HTTP规范里没有保证).

HTTP幂等性概念和应用

- rockmaple - 酷壳 - CoolShell.cn
[ 感谢 Todd 同学投递本文 ]. 基于HTTP协议的Web API是时下最为流行的一种分布式服务提供方式. 无论是在大型互联网应用还是企业级架构中,我们都见到了越来越多的SOA或RESTful的Web API. 为什么Web API如此流行呢. 我认为很大程度上应归功于简单有效的HTTP协议.

创建订单实现幂等的一点思考

- - 文章 – 伯乐在线
大部分文章都会说,同一个操作,进行多次操作后,结果是一样的,就可以说这个操作是支持幂等的. 感觉不太准确,比如一个http get操作,可能每次的结果都不一样,但是其实是幂等的. 看了很多文章,感觉下面的定义比较准确:. 一个操作如果多次任意执行所产生的影响(或者叫副作用),都是相同的. 如果一个用户分两次下单,购买的商品都是一样的.

分布式幂等问题解决方案三部曲

- - SegmentFault 最新的文章
文章目的:本文旨在提炼一套分布式幂等问题的思考框架,而非解决某个具体的分布式幂等问题. 在这个框架体系内,会有一些方案举例说明. 文章目标:希望读者能通过这套思考框架设计出符合自己业务的完备的幂等解决方案. (1)背景介绍,为什么会有幂等. (2)什么是幂等,这个定义非常重要,决定了整个思考框架. (3)解决幂等问题的三部曲,也是作者的思考框架.

Kafka笔记—可靠性、幂等性和事务 - luozhiyun - 博客园

- -
这几天很忙,但是我现在给我的要求是一周至少要出一篇文章,所以先拿这篇笔记来做开胃菜,源码分析估计明后两天应该能写一篇. Kafka只对“已提交”的消息(committed message)做有限度的持久化保证. 当Kafka的若干个Broker成功地接收到一条消息并写入到日志文件后,它们会告诉生产者程序这条消息已成功提交.

高并发下如何保证接口的幂等性?

- -
接口幂等性问题,对于开发人员来说,是一个跟语言无关的公共问题. 本文分享了一些解决这类问题非常实用的办法,绝大部分内容我在项目中实践过的,给有需要的小伙伴一个参考. 不知道你有没有遇到过这些场景:. form表单时,保存按钮不小心快速点了两次,表中竟然产生了两条重复的数据,只是id不一样. 接口超时问题,通常会引入了.

Kafka幂等性原理及实现剖析 - 哥不是小萝莉 - 博客园

- -
最近和一些同学交流的时候反馈说,在面试Kafka时,被问到Kafka组件组成部分、API使用、Consumer和Producer原理及作用等问题都能详细作答. 但是,问到一个平时不注意的问题,就是Kafka的幂等性,被卡主了. 那么,今天笔者就为大家来剖析一下Kafka的幂等性原理及实现. 2.1 Kafka为啥需要幂等性.

高并发的核心技术-幂等的实现方案 - 无量的IT生活 - ITeye博客

- -
高并发的核心技术-幂等的实现方案. 我们实际系统中有很多操作,是不管做多少次,都应该产生一样的效果或返回一样的结果. 前端重复提交选中的数据,应该后台只产生对应这个数据的一个反应结果. 我们发起一笔付款请求,应该只扣用户账户一次钱,当遇到网络重发或系统bug重发,也应该只扣一次钱;. 发送消息,也应该只发一次,同样的短信发给用户,用户会哭的;.

电商之城

- 可可 - 《商业价值》杂志
原产地效应正在点亮越来越多的电商之城,这代表着电子商务正在逐步回归“商务”的本质. 从机场拿一份免费的手绘地图,和着有点潮湿的空气,足够开启对厦门这座海滨城市的造访. 从市中心到达位于厦门东北方向的软件园二期,只用了不到20分钟. 对于一个习惯了北京的拥堵和密集的人来说,一座被出租车师傅将半小时车程定义为“还挺远”的城市,从一开始就带给人惊喜.

谈电商平台

- - 人月神话的BLOG
一个完整的电商平台模块本身应该如何划分,可以从两个维度来进行思考,一个维度是本身电商的端到端业务和流程角度出发,可以分为哪些大的阶段,每个大阶段可对应为模块;另外一个维度则是从电商业务中的核心主数据和业务单据出发,围绕数据来考虑模块的划分. 电商平台核心模块从基础数据层面包括了产品管理,客户管理,供应商,经销商管理,在产品和供应商管理中可能又会拆分单独的价格库模块,维护产品价格和价格策略信息.