服务高可用:幂等性设计

什么是幂等性?

一般在服务调用时,读服务如果调用失败了,会自动按配置次数转移到别的服务上去请求。而写服务就不能重复请求,如果因为超时或者网络故障等原因被调用服务并没有返回成功的响应,服务调用方就认为是失败了,但很有可能的是已经成功了,如果继续重复请求写服务,如转账类的服务,可能会造成严重的后果。所以,写服务失败不能设计成继续发重复请求,被调用服务也要设计幂等性,即使重复请求,也不会造成影响。

知道上面的背景,所以,幂等性就是同样的参数,重复请求相同的服务,必须得到相同的结果。

幂等性设计

举一个支付的场景,请求一个第三方支付接口发起支付功能,同样的订单号,同样的金额信息,返回的都是成功。同样的订单号,不同的金额信息,返回的是订单号重复。这就是幂等性设计,第三方支付效验了请求参数和已有数据库的信息一致时直接返回已有的成功数据,如果数据不一致而又订单号重复直接报订单号重复。而如果不做幂等性设计,同样的订单号,同样的金额信息,重复支付,可能会造成金额累加。为了服务友好性,同样的订单号同样的金额信息返回订单号重复也是不友好的。

有些服务天生就具有幂等性,如修改用户邮箱、性别等,不管你重复请求修改多少次,返回的结果都是一样的。

所以,对于服务幂等性设计的要点就是一定要效验请求参数有效性,及已有数据的对比。如果同样的请求参数已经处理过就不要重复处理,直接返回,这就是幂等性核心点。

下面这张图已经很形式的说明了幂等性的重要性。

原文地址:https://www.cnblogs.com/rinack/p/9734567.html

时间: 2024-11-09 18:35:41

服务高可用:幂等性设计的相关文章

亚马逊AWS在线系列讲座——基于AWS云平台的高可用应用设计

设计高可用的应用是架构师的一个重要目标,但是基于云计算平台设计高可用应用与基于传统平台的设计有许多不同.云计算在给架构师带来了许多新的设计挑战的时候,也给带来了许多新的设计理念和可用的服务.如何在设计应用的时候充分利用云平台的各种特点是基于云计算设计的一个重要条件.在这个在线讲座中,我们将以亚马逊AWS云平台为例,讨论如何设计一个高可用应用. 我们先会根据AWS服务是否天然高可用.高容错的特点把常见的AWS服务分类.比如AWS把下面服务设计成高可用和高容错的服务: ·     Amazon S3

高可用架构设计与实践

第一课:高可用架构知识原理篇 什么架构的高可用? 架构高可用的重要性? 架构高可用的常用手段都有哪些? 架构高可用评价维度是什么? 架构高可用的考核如何分级? 架构高可用的涉及环节都有哪些? 第二课:高可用架构设计之总体架构篇 高可用架构为什么需要分层? 高可用架构分层设计原则是什么?如何架构分层? 高可用架构分层最佳实践: 我们的实践案例: 第三课:高可用架构设计之硬件篇 如何选择硬件?选择什么样的硬件? 高可用架构硬件层面如何保证? 硬件层面高可用架构保证的最佳实践是什么? 我们的实践案例:

面向业务的立体化高可用架构设计

面向业务的立体化高可用架构设计 摘要:为了实现阿里九游游戏接入系统的业务高可用,技术人员跳出传统的面向系统的高可用的思路,转而从业务的角度来整体考虑高可用,最终实现了一套立体化的高可用架构,本文逐一展示这套立体化高可用架构的一些具体实践. 通常情况下我们在谈论高可用架构设计的时候,主要关注的是系统结构的高可用,例如主备架构.集群架构.多中心架构.我们做架构设计的时候,也主要是从系统结构本身出发,例如我们把单机改为双机.双机改为集群.单机房改为异地多机房等等. 这种以系统结构为目标的高可用架构设计

实现服务高可用奇淫技巧(一)

1. 前言 在上一篇通知文章有说过,六月份会开始更新公众号(当然一些好的文章我也会同步到博客中来,所以大家看到有些文章的内容和公众号中的是一样的),虽然现在已到月底了,但好歹也算没有失言,赶上了末班车了. 公众号中有很多读者留言,大家很期待能继续更新<RF接口自动化系列>文章,放心,牛奶会有的,面包也会有的,自己答应大家的,含泪也有完成的. 不过本篇仍不会更新<RF接口自动化系列>的文章,放心,后续会更新,敬请期待~ 本篇会给大家介绍一下服务高可用的实现,大致也会分几篇文章进行讲解

阿里游戏高可用架构设计实践

今天读了李云华老师写的<阿里游戏高可用架构设计实践 >,有一些感受想分享一下. 印象很深的一句话那就是他最开始说的“把韵味的锅让研发去背!”也就是说,高可用的系统是设计出来的,不是靠运维保障出来的! 他提到出现问题人们的思考顺序为:首先想到的是不是运维太LOW了,比如说硬件质量太差,为什么这个月机柜也坏.交换机也坏,是不是到电脑城买个二手货放里面了?第二想到的是不是运气不好,之前一个月.两个月才遇到一次,这个月遇到了4次,是不是你们没有在机房烧香?第三个是不是测试不足,为什么这些Bug测试阶段

mysql高可用架构设计

主要介绍:复制功能介绍.mysql二进制日志.mysql复制拓扑.高可用框架.单点故障.读写分离和负载均衡介绍等 mysql复制功能提供分担读负载 复制解决的问题 实现在不同服务器上的数据分布 利用二进制日志增量进行 不需要太多的带宽 但是使用基于行的复制在进行大批量的更改时会对带宽带来一定得压力,特别是跨IDC环境下进行复制 实现在不同服务器上的数据分布 实现数据读取的负载均衡 需要其他组件配合完成 利用DNS轮询的方式把程序的读连接到不同的备份数据库, 使用LVS,haproxy这样的代理方

HAProxy+KeepAlived实现web服务高可用、动静分离等

大致规划: 主机 IP 描述 VIP 192.168.0.222 对外提供高可用IP haproxy+keepalived (node1) 192.168.0.111 haproxy为后端两台WEB服务的做动静分离:keepalived为haproxy做高可用. haproxy+keepalived (node2) 192.168.0.112 WEB                (node3) 192.168.0.113 提供静态请求响应 Apache+PHP+MySQL   (node4)

高可用集群技术之heartbeat+NFS实现web服务高可用(文本方式配置接口--gui图形配置)

一.高可用集群基本概念   什么是高可用技术呢?在生产环境中我既要保证服务不间断的服务又要保证服务器稳定不down机,但是异常还是会发生,比如说:服务器硬件损坏...导致服务器down机,我该如何保证服务器down机后继续提供服务呢?这时我就应该请出高可用技术来帮忙了,当我们的服务器发生故障后不能继续时,高可用集群技术解决将业务及服务自动转移至其他主机服务器上继续服务,保证服务架构不间断运行. 高可用集群的架构层次: 后端主机层: 这一层主要是正在运行在物理主机上的服务. 2.Message l

网络服务高可用——双网卡绑定同一IP

很多时候,企业里面的一些关键型网络服务,不仅数据吞量相当大,而且还不允许随便离线的,所以就要求我们的网络服务一定要具有高可用性.数据吞吐量大,很多人就说了,这个简单,在我们的关键业务服务器上多装几张网卡,均衡流量负载也就可以了.但如果多网卡,多IP,不仅浪费了IP资源,更麻烦的事在客户访问的过程中如果出现了某张网卡离线的情况时,还需要重新连接另一IP的网卡才能继续会话,这是一件很头疼的事,有没有一个两全其美的办法了.有,其实操作起来也很简单,那么今天就给大家分享一下,如何实现双网卡绑定同一IP,

Heartbeat实现web服务高可用(三)

六:Heartbeat实现WEB服务高可用案例 6.1 部署准备 资源环境:继续使用我们之前已经部署好Heartbeat的两台服务器node01.cn和node02.cn,两台机器heartbeat是双主模式我们再捋一捋    node01.cn   eth0 172.10.25.26 外网管理IP                      eth1 10.25.25.16  心跳直连                      VIP  172.10.25.18        node02.cn