西安做网站选哪家公司,深圳做地铁的公司网站,怎么在子域名建立一个不同的网站,公司建一个网站吗在Java web项目开发中#xff0c;经常会听到在做订单系统中生成订单的时候#xff0c;要做幂等性控制和并发控制#xff0c;特对此部分内容作出总结#xff0c;在高并发场景下#xff0c;代码层面需要实现并发控制#xff1b;但是幂等性#xff0c;其实更多的是系统的接…在Java web项目开发中经常会听到在做订单系统中生成订单的时候要做幂等性控制和并发控制特对此部分内容作出总结在高并发场景下代码层面需要实现并发控制但是幂等性其实更多的是系统的接口对外的一种承诺承诺一次请求和多次请求会返回同样的数据。关于幂等性将分别从高等代数中的幂等性、HTTP中的幂等性和订单生成系统中的幂等性阐述并发性控制则提供了分布式锁等方式来对并发场景进行代码实现。 一、幂等性 idempotence [aɪdəmpoʊtəns] 1.高等代数中关于幂等idempotence概念解释 单目运算, x为某集合内的任意数, 如果满足f(x)f(f(x)), 那么我们称f运算为具有幂等性(idempotent)。比如在实数集中,绝对值运算就是一个例子: abs(a)abs(abs(a))。 双目运算x为某集合内的任意数, f为运算子如果满足f(x,x)x, f运算的前提是两个参数都同为x, 那么我们也称f运算为具有幂等性。比如在实数集中,求两个数的最大值的函数: max(x,x) x, 还有布尔代数中,逻辑运算 与, 或 也都是幂等运算, 因为他们符合AND(0,0) 0, AND(1,1) 1, OR(0,0) 0, OR(1,1) 1。 在将幂等性应用到软件开发中,需要一些更深的理解我的理解如下:数学处理的是运算和数值, 程序开发中往往处理的是对象和函数. 但是我们不能简单地理解为数学幂等中的运算就是函数,而数值就是对象。如Person对象有两个属性weight和age,但是所有的function只能对其中一个属性操作。所以从这个层面我们可以理解为: 函数只对该函数所操作的对象某个属性具有幂等性, 而不是说对整个对象有运算幂等性。 Person { private int weight; private int age; //是幂等函数public void setAge(int v){ this.age v; }//不是幂等函数public void increaseAge(){ this.age;} //是幂等函数public void setWeight(int v){ this.weightv10;//故意加10斤!!}
} 还有一点必须要澄清的是: 幂等性所表达的概念关注的是数学层面的运算和数值, 并没有提及到数值的安全性问题.如上面的Person的setAge函数, 有两种case不是幂等性所关心的, 但程序开发却又必须要关心的: 两个线程同时调用因为age从业务上讲不可能递减, 如果前一次调用设置是30岁, 后一次调用变成了10岁或是更离谱的 -1 岁幂等性是系统的接口对外一种承诺(而不是实现), 承诺只要调用接口成功, 外部多次调用对系统的影响是一致的。声明为幂等的接口会认为外部调用失败是常态, 并且失败之后必然会有重试。所以RESTful设计中将幂等性和安全性作为两个不同的指标来衡量POST,PUT,GET,DELETE操作的。因此post不是幂等性的put get delete都是幂等性的也即在生成订单的post请求中我们要做幂等性的控制。如下图一个ajax请求是一次post请求的示例如果这个post请求被调用多次它会向表插入多条记录很显然post请求并不是幂等性的所以幂等性的控制交由我们程序中来控制。 2.HTTP协议中的幂等性 项目中中的SOA和restful API接口的流行都需要应用层HTTP协议的支持目前的项目结构Web API RIARich Internet Applications富互联网应用Web API专注于提供业务服务RIA专注于用户界面和交互设计从此两个领域的分工更加明晰。正如简单的Java语言并不意味着高质量的Java程序简单的HTTP协议也不意味着高质量的Web API。要想设计出高质量的Web API还需要深入理解分布式系统及HTTP协议的特性。在HTTP1.1规范中定义幂等性。 Methods can also have the property of idempotence in that (aside from error or expiration issues) the side-effects of N 0 identical requests is the same as for a single request. 从定义上看HTTP方法的幂等性是指一次和多次请求某一个资源应该具有同样的作用。幂等性是分布式系统设计中十分重要的概念而HTTP的分布式本质也决定了它在HTTP中具有重要地位。比如有这样一个业务逻辑假设有一个从账户取钱的远程API可以是HTTP的也可以不是我们暂时定义接口 bool withdraw(account_id, amount) withdraw的语义是从account_id对应的账户中扣除amount数额的钱如果扣除成功则返回true账户余额减少amount如果扣除失败则返回false账户余额不变。值得注意的是和本地环境相比我们不能轻易假设分布式环境的可靠性。一种典型的情况是withdraw请求已经被服务器端正确处理但服务器端的返回结果由于网络等原因被丢掉了导致客户端无法得知处理结果。如果是在网页上一些不恰当的设计可能会使用户认为上一次操作失败了然后刷新页面这就导致了withdraw被调用两次账户也被多扣了一次钱。如下图所示 这个问题的解决方案一是采用分布式事务通过引入支持分布式事务的中间件来保证withdraw功能的事务性。分布式事务的优点是对于调用者很简单复杂性都交给了中间件来管理。缺点则是一方面架构太重量级容易被绑在特定的中间件上不利于异构系统的集成另一方面分布式事务虽然能保证事务的ACID性质而但却无法提供性能和可用性的保证。 另一种更轻量级的解决方案是幂等设计。我们可以通过一些技巧把withdraw变成幂等的比如 int create_ticket()
bool idempotent_withdraw(ticket_id, account_id, amount) create_ticket的语义是获取一个服务器端生成的唯一的处理号token它将用于标识后续的操作。idempotent_withdraw和withdraw的区别在于关联了一个token一个token表示的操作至多只会被处理一次每次调用都将返回第一次调用时的处理结果。这样idempotent_withdraw就符合幂等性了客户端就可以放心地多次调用。也就是说多次点击提交的时候附带提交的还有服务端生成的token由于多次提交带的是同一个token所以服务端对于同一个token的post订单至多只会处理一次所以间接的实现了幂等性的控制。 基于幂等性的解决方案中一个完整的取钱流程被分解成了两个步骤1.调用create_ticket()获取token2.调用idempotent_withdraw(token, account_id, amount)。虽然create_ticket不是幂等的但在这种设计下它对系统状态的影响可以忽略加上idempotent_withdraw是幂等的所以任何一步由于网络等原因失败或超时客户端都可以重试直到获得结果。如图2所示 和分布式事务相比幂等设计的优势在于它的轻量级容易适应异构环境以及性能和可用性方面。在某些性能要求比较高的应用中幂等设计往往是唯一的选择。 HTTP GET方法用于获取资源不应有副作用所以是幂等的。比如GET http://www.bank.com/account/123456不会改变资源的状态不论调用一次还是N次都没有副作用。请注意这里强调的是一次和N次具有相同的作用而不是每次GET的结果相同。GET http://www.news.com/latest-news这个HTTP请求可能会每次得到不同的结果但它本身并没有产生任何副作用因而是满足幂等性的。HTTP DELETE方法用于删除资源有副作用但它应该满足幂等性。比如DELETE http://www.forum.com/article/4231调用一次和N次对系统产生的副作用是相同的即删掉id为4231的帖子因此调用者可以多次调用或刷新页面而不必担心引起错误。比较容易混淆的是HTTP POST和PUT。POST和PUT的区别容易被简单地误认为“POST表示创建资源PUT表示更新资源”而实际上二者均可用于创建资源更为本质的差别是在幂等性方面。在HTTP规范中对POST和PUT是这样定义的 The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line ...... If a resource has been created on the origin server, the response SHOULD be 201 (Created) and contain an entity which describes the status of the request and refers to the new resource, and a Location header.The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server. If the Request-URI does not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create the resource with that URI. POST所对应的URI并非创建的资源本身而是资源的接收者。比如POST http://www.forum.com/articles的语义是在http://www.forum.com/articles下创建一篇帖子HTTP响应中应包含帖子的创建状态以及帖子的URI。两次相同的POST请求会在服务器端创建两份资源它们具有不同的URI所以POST方法不具备幂等性。而PUT所对应的URI是要创建或更新的资源本身。比如PUT http://www.forum/articles/4231的语义是创建或更新ID为4231的帖子。对同一URI进行多次PUT的副作用和一次PUT是相同的因此PUT方法具有幂等性。论坛网站防止重复发帖和订单生成都用到token方式的幂等性控制。 3.总结 在电商系统中常见问题如何防范post请求的重复提交HTTP POST 操作既不是安全的也不是幂等的。当我们因为反复刷新浏览器导致多次提交表单多次发出同样的POST请求导致远端服务器重复创建出了资源。所以对于电商应用来说第一对应的后端 WebService 一定要做到幂等性第二服务器端收到 POST 请求在操作成功后必须跳转到另外一个页面这样即使用户刷新页面也不会重复提交表单。 二、高并发 1.分布式锁的定义 分布式锁是控制分布式系统之间同步访问共享资源的一种方式。在分布式系统中常常需要协调他们的动作。如果不同的系统或是同一个系统的不同主机之间共享了一个或一组资源那么访问这些资源的时候往往需要互斥来防止彼此干扰来保证一致性在这种情况下便需要使用到分布式锁。分布式锁是一个在很多环境中非常有用的原语它是不同的系统或是同一个系统的不同主机之间互斥操作共享资源的有效方法。如在电商系统中需要保证整个分布式系统内对一个重要事物订单账户等的有效操作线程 同一时间内有且只有一个。比如交易中心有N台服务器订单中心有M台服务器如何保证一个订单的同一笔支付处理一个账户的同一笔充值操作是原子性的。 常见的实现分布式锁的服务有memcache zookeeper redis chubby hazelcast。 2.分布式锁实现 分布式锁在分布式应用当中是要经常用到的主要是解决分布式资源访问冲突的问题。传统的锁ReentrantLock在去实现的时候是有问题的ReentrantLock的lock和unlock要求必须是在同一线程进行而分布式应用中lock和unlock是两次不相关的请求因此肯定不是同一线程因此导致无法使用ReentrantLock。 附 1、什么是restful风格的API接口 http://www.ruanyifeng.com/blog/2014/05/restful_api.html http://www.cnblogs.com/zhengyun_ustc/archive/2012/11/17/topic2.html http://www.cnblogs.com/j2eetop/p/4612437.html http://www.cnblogs.com/weidagang2046/p/exception-handling-principles.html http://www.cnblogs.com/orange1438/p/4637776.html 转载于:https://www.cnblogs.com/RunForLove/p/5640949.html
