我要投搞

标签云

收藏小站

爱尚经典语录、名言、句子、散文、日志、唯美图片

当前位置:2019年全年资料内部公开36码 > 强一致性 >

保证分布式系统数据一致性的6种方案

归档日期:07-09       文本归类:强一致性      文章编辑:爱尚语录

  在电商等业务中,系统一般由多个独立的服务组成,如何解决分布式调用时候数据的一致性?

  具体业务场景如下,比如一个业务操作,如果同时调用服务 A、B、C,需要满足要么同时成功;要么同时失败。A、B、C 可能是多个不同部门开发、部署在不同服务器上的远程服务。

  在分布式系统来说,如果不想牺牲一致性,CAP 理论告诉我们只能放弃可用性,这显然不能接受。为了便于讨论问题,先简单介绍下数据一致性的基础理论。

  当更新操作完成之后,任何多个后续进程或者线程的访问都会返回最新的更新过的值。这种是对用户最友好的,就是用户上一次写什么,下一次就保证能读到什么。根据 CAP 理论,这种实现需要牺牲可用性。

  系统并不保证后续进程或者线程的访问都会返回最新的更新过的值。系统在数据写入成功之后,不承诺立即可以读到最新写入的值,也不会具体的承诺多久之后可以读到。

  弱一致性的特定形式。系统保证在没有后续更新的前提下,系统最终返回上一次更新操作的值。在没有故障发生的前提下,不一致窗口的时间主要受通信延迟,系统负载和复制副本的个数影响。DNS 是一个典型的最终一致性系统。

  在工程实践上,为了保障系统的可用性,互联网系统大多将强一致性需求转换成最终一致性的需求,并通过系统执行幂等性的保证,保证数据的最终一致性。但在电商等场景中,对于数据一致性的解决方法和常见的互联网系统(如 MySQL 主从同步)又有一定区别,群友的讨论分成以下 6 种解决方案。

  业务整合方案主要采用将接口整合到本地执行的方法。拿问题场景来说,则可以将服务 A、B、C 整合为一个服务 D 给业务,这个服务 D 再通过转换为本地事务的方式,比如服务 D 包含本地服务和服务 E,而服务 E 是本地服务 A ~ C 的整合。

  缺点:显而易见,把本来规划拆分好的业务,又耦合到了一起,业务职责不清晰,不利于维护。

  此方案的核心是将需要分布式处理的任务通过消息日志的方式来异步执行。消息日志可以存储到本地文本、数据库或消息队列,再通过业务规则自动或人工发起重试。人工重试更多的是应用于支付场景,通过对账系统对事后问题的处理。

  考虑到网络通讯失败、数据丢包等原因,如果接口不能保证幂等性,数据的唯一性将很难保证。

  此方案是 eBay 的架构师 Dan Pritchett 在 2008 年发表给 ACM 的文章,是一篇解释 BASE 原则,或者说最终一致性的经典文章。文中讨论了 BASE 与 ACID 原则在保证数据一致性的基本差异。

  如果 ACID 为分区的数据库提供一致性的选择,那么如何实现可用性呢?答案是

  BASE 的可用性是通过支持局部故障而不是系统全局故障来实现的。下面是一个简单的例子:如果将用户分区在 5 个数据库服务器上,BASE 设计鼓励类似的处理方式,一个用户数据库的故障只影响这台特定主机那 20% 的用户。这里不涉及任何魔法,不过它确实可以带来更高的可感知的系统可用性。

  文章中描述了一个最常见的场景,如果产生了一笔交易,需要在交易表增加记录,同时还要修改用户表的金额。这两个表属于不同的远程服务,所以就涉及到分布式事务一致性的问题。

  文中提出了一个经典的解决方法,将主要修改操作以及更新用户表的消息放在一个本地事务来完成。同时为了避免重复消费用户表消息带来的问题,达到多次重试的幂等性,增加一个更新记录表 updates_applied来记录已经处理过的消息。

  基于以上方法,在第一阶段,通过本地的数据库的事务保障,增加了 transaction 表及消息队列 。

  在第二阶段,分别读出消息队列(但不删除),通过判断更新记录表 updates_applied 来检测相关记录是否被执行,未被执行的记录会修改 user 表,然后增加一条操作记录到updates_applied,事务执行成功之后再删除队列。

  通过以上方法,达到了分布式系统的最终一致性。进一步了解 eBay 的方案可以参考文末链接。

  随着业务规模不断地扩大,电商网站一般都要面临拆分之路。就是将原来一个单体应用拆分成多个不同职责的子系统。比如以前可能将面向用户、客户和运营的功能都放在一个系统里,现在拆分为订单中心、代理商管理、运营系统、报价中心、库存管理等多个子系统。

  最开始的单体应用所有功能都在一起,存储也在一起。比如运营要取消某个订单,那直接去更新订单表状态,然后更新库存表就 ok 了。因为是单体应用,库在一起,这些都可以在一个事务里,由关系数据库来保证一致性。

  但拆分之后就不同了,不同的子系统都有自己的存储。比如订单中心就只管理自己的订单库,而库存管理也有自己的库。那么运营系统取消订单的时候就是通过接口调用等方式来调用订单中心和库存管理的服务了,而不是直接去操作库。这就涉及一个『分布式事务』的问题。

  幂等有两种方式,一种方式是业务逻辑保证幂等。比如接到支付成功的消息订单状态变成支付完成,如果当前状态是支付完成,则再收到一个支付成功的消息则说明消息重复了,直接作为消息成功处理。

  另外一种方式如果业务逻辑无法保证幂等,则要增加一个去重表或者类似的实现。对于 producer 端在业务数据库的同实例上放一个消息库,发消息和业务操作在同一个本地事务里。发消息的时候消息并不立即发出,而是向消息库插入一条消息记录,然后在事务提交的时候再异步将消息发出,发送消息如果成功则将消息库里的消息删除,如果遇到消息队列服务异常或网络问题,消息没有成功发出那么消息就留在这里了,会有另外一个服务不断地将这些消息扫出重新发送。

  2. 有的业务不适合异步消息的方式,事务的各个参与方都需要同步的得到结果。这种情况的实现方式其实和上面类似,每个参与方的本地业务库的同实例上面放一个事务记录库。

  比如 A 同步调用 B,C。A 本地事务成功的时候更新本地事务记录状态,B 和 C 同样。如果有一次 A 调用 B 失败了,这个失败可能是 B 真的失败了,也可能是调用超时,实际 B 成功。则由一个中心服务对比三方的事务记录表,做一个最终决定。假设现在三方的事务记录是 A 成功,B 失败,C 成功。那么最终决定有两种方式,根据具体场景:

  执行 A 和 B 的补偿操作(一种可行的补偿方式是回滚,回滚 A 和 C)。

  对 b 场景做一个特殊说明:比如 B 是扣库存服务,在第一次调用的时候因为某种原因失败了,但是重试的时候库存已经变为 0,无法重试成功,这个时候只有回滚 A 和 C 了。

  那么可能有人觉得在业务库的同实例里放消息库或事务记录库,会对业务侵入,业务还要关心这个库,是否一个合理的设计?

  实际上可以依靠运维的手段来简化开发的侵入,我们的方法是让 DBA 在公司所有 MySQL 实例上预初始化这个库,通过框架层(消息的客户端或事务 RPC 框架)透明的在背后操作这个库,业务开发人员只需要关心自己的业务逻辑,不需要直接访问这个库。

  总结起来,其实两种方式的根本原理是类似的,也就是将分布式事务转换为多个本地事务,然后依靠重试等方式达到最终一致性。

  我们把交易创建流程抽象出一系列可扩展的功能点,每个功能点都可以有多个实现(具体的实现之间有组合/互斥关系)。把各个功能点按照一定流程串起来,就完成了交易创建的过程。

  每个功能点的实现都可能会依赖外部服务。那么如何保证各个服务之间的数据是一致的呢?比如锁定优惠券服务调用超时了,不能确定到底有没有锁券成功,该如何处理?再比如锁券成功了,但是扣减库存失败了,该如何处理?

  服务依赖过多,会带来管理复杂性增加和稳定性风险增大的问题。试想如果我们强依赖 10 个服务,9 个都执行成功了,最后一个执行失败了,那么是不是前面 9 个都要回滚掉?这个成本还是非常高的。

  所以在拆分大的流程为多个小的本地事务的前提下,对于非实时、非强一致性的关联业务写入,在本地事务执行成功后,我们选择发消息通知、关联事务异步化执行的方案。

  消息通知往往不能保证 100% 成功;且消息通知后,接收方业务是否能执行成功还是未知数。前者问题可以通过重试解决;后者可以选用事务消息来保证。

  但是事务消息框架本身会给业务代码带来侵入性和复杂性,所以我们选择基于 DB 事件变化通知到 MQ 的方式做系统间解耦,通过订阅方消费 MQ 消息时的 ACK 机制,保证消息一定消费成功,达到最终一致性。由于消息可能会被重发,消息订阅方业务逻辑处理要做好幂等保证。

  所以目前只剩下需要实时同步做、有强一致性要求的业务场景了。在交易创建过程中,锁券和扣减库存是这样的两个典型场景。

  要保证多个系统间数据一致,乍一看,必须要引入分布式事务框架才能解决。但引入非常重的类似二阶段提交分布式事务框架会带来复杂性的急剧上升;在电商领域,绝对的强一致是过于理想化的,我们可以选择准实时的最终一致性。

  我们在交易创建流程中,首先创建一个不可见订单,然后在同步调用锁券和扣减库存时,针对调用异常(失败或者超时),发出废单消息到MQ。如果消息发送失败,本地会做时间阶梯式的异步重试;优惠券系统和库存系统收到消息后,会进行判断是否需要做业务回滚,这样就准实时地保证了多个本地事务的最终一致性。

  业界常用的还有支付宝的一种 xts 方案,由支付宝在 2PC 的基础上改进而来。主要思路如下,大部分信息引用自官方网站。

  分布式事务服务 (Distributed Transaction Service, DTS) 是一个分布式事务框架,用来保障在大规模分布式环境下事务的最终一致性。DTS 从架构上分为 xts-client 和 xts-server 两部分,前者是一个嵌入客户端应用的 JAR 包,主要负责事务数据的写入和处理;后者是一个独立的系统,主要负责异常事务的恢复。

  传统关系型数据库的事务模型必须遵守 ACID 原则。在单数据库模式下,ACID 模型能有效保障数据的完整性,但是在大规模分布式环境下,一个业务往往会跨越多个数据库,如何保证这多个数据库之间的数据一致性,需要其他行之有效的策略。在 JavaEE 规范中使用 2PC (2 Phase Commit, 两阶段提交) 来处理跨 DB 环境下的事务问题,但是 2PC 是反可伸缩模式,也就是说,在事务处理过程中,参与者需要一直持有资源直到整个分布式事务结束。这样,当业务规模达到千万级以上时,2PC 的局限性就越来越明显,系统可伸缩性会变得很差。基于此,我们采用 BASE 的思想实现了一套类似 2PC 的分布式事务方案,这就是 DTS。DTS在充分保障分布式环境下高可用性、高可靠性的同时兼顾数据一致性的要求,其最大的特点是保证数据最终一致 (Eventually consistent)。

  最终一致:事务处理过程中,会有短暂不一致的情况,但通过恢复系统,可以让事务的数据达到最终一致的目标。

  协议简单:DTS 定义了类似 2PC 的标准两阶段接口,业务系统只需要实现对应的接口就可以使用 DTS 的事务功能。

  与 RPC 服务协议无关:在 SOA 架构下,一个或多个 DB 操作往往被包装成一个一个的 Service,Service 与 Service 之间通过 RPC 协议通信。DTS 框架构建在 SOA 架构上,与底层协议无关。

  与底层事务实现无关: DTS 是一个抽象的基于 Service 层的概念,与底层事务实现无关,也就是说在 DTS 的范围内,无论是关系型数据库 MySQL,Oracle,还是 KV 存储 MemCache,或者列存数据库 HBase,只要将对其的操作包装成 DTS 的参与者,就可以接入到 DTS 事务范围内。

  业务活动管理器控制业务活动的一致性,它登记业务活动中的操作,并在活动提交时确认所有的两阶段事务的 confirm 操作,在业务活动取消时调用所有两阶段事务的 cancel 操作。”

  公司的支付部门,通过接入其它第三方支付系统来提供支付服务给业务部门,支付服务是一个基于 Dubbo 的 RPC 服务。

  从业务规则上需要同时保证业务数据的实时性和一致性,也就是支付成功必须加积分。

  我们采用的方式是同步调用,首先处理本地事务业务。考虑到积分业务比较单一且业务影响低于支付,由积分平台提供增加与回撤接口。

  具体的流程是先调用积分平台增加用户积分,再调用支付平台进行支付处理,如果处理失败,catch 方法调用积分平台的回撤方法,将本次处理的积分订单回撤。

  公司的用户信息,统一由用户中心维护,而用户信息的变更需要同步给各业务子系统,业务子系统再根据变更内容,处理各自业务。用户中心作为 MQ 的 producer,添加通知给 MQ。APP Server 订阅该消息,同步本地数据信息,再处理相关业务比如 APP 退出下线等。

  我们采用异步消息通知机制,目前主要使用 ActiveMQ,基于 Virtual Topic 的订阅方式,保证单个业务集群订阅的单次消费。

  分布式服务对衍生的配套系统要求比较多,特别是我们基于消息、日志的最终一致性方案,需要考虑消息的积压、消费情况、监控、报警等。

  感谢李玉福、余昭辉、蘑菇街七公提供方案,其他多位群成员对本文内容亦有贡献。

  一、说在前面微服务是当下最火的词语,现在很多公司都在推广微服务,当服务越来越多的时候,我们是否会纠结以下几个问题:面对一笔超时的订单,究竟是哪一步处理时间超长呢?数据由于并发莫名篡改,到底都谁有重大嫌...博文来自:小程故事多的博客

  分布式系统调用链监控应用架构由集中式向分布式演进后,整个调用关系变得复杂。分布式架构由复杂且较大规模集群构成,各个应用之间相当独立,可能由不同团队、不同语言实现。系统一个完整的调用过程可能横跨多个服务...博文来自:seaboat——a free boat on the sea.(公众号:远洋号)

  云栖社区2017-05-0412:09更多深度文章,请关注云计算频道:分布式调用系统的现状当前,随着互联网架构的扩张,分布式系统变得日趋复杂,越来...博文来自:u011277123的博客

  参考阿里鹰眼:分布式调用跟踪与监控实战分布式系统调用链监控博文来自:Sun

  Nginx负载均衡与反向代理—《亿级流量网站架构核心技术》原创: 张开涛 开涛的博客 2017-03-24本篇摘自《亿级流量网站架构核心技术》第二章Nginx负载均衡与反向代理部分内容。当我们的应用单...博文来自:黄小斜

  数据库包含1:会员库(会员数据,优惠券数据)2:商品库(商品数据,库存数据)3:订单库(订单表、订单明细表,下单事件表)订单系统下单处理流程1:用户提交订单前先检测资源可用性(库存,账户余额,优惠券等...博文来自:test1444509256的博客

  本文整理自美团点评技术沙龙第08期:大规模集群的服务治理设计与实践。美团点评技术沙龙由美团点评技术团队主办,每月一期。每期沙龙邀请美团点评及其它互联网公司的技术专家分享来自一线的实践经验,覆盖各主要技...博文来自:sandy_hmily的专栏

  前言随着美团点评的业务发展,公司的分布式系统变得越来越复杂,我们亟需一个工具能够梳理内部服务之间的关系,感知上下游服务的形态。比如一次请求的流量从哪个服务而来、最终落到了哪个服务中去?服务之间是RPC...博文来自:贾红平

  BraveBrave是一个用于捕捉和报告分布式操作的延迟信息给Zipkin的工具库。Zipkin基于Dapper,包含什么Brave的无依赖性trace包基于JRE6+,这是用于记录时间和描述系统的基...博文来自:借来方向

  微服务日趋火爆,系统由单体应用向微服务架构演进,拆分成多个独立的服务,如何解决分布式调用时候数据的一致性?CAP理论告诉我们,任何一个分布式系统都无法同时满足Consistency(一致性)、Avai...博文来自:weixin_34418883的博客

  库存冻结现状目前购物车添加商品、删除商品、修改商品数量、购物车过期库存解冻、成单后清空购物车,都涉及库存变化。以添加商品为例,目前实现逻辑为:1、调用库存系统扣减库存2、购物车写库3、第2步失败时,调...博文来自:weixin_43029798的博客

  分布式服务下的交易一致性解决方案银行很强势,我们什么都不管(1.调一次,我出款一次;2.不提交任何冥等操作)我们什么都没有(没有分布式事务)用户只提交一次我们只能成功一次一、远程调用与本地事务区分开(...博文来自:昨天

  前言分布式数据库的数据一致性管理是其最重要的内核技术之一,也是保证分布式数据库满足数据库最基本的ACID特性中的“一致性”(Consistency)的保障。在分布式技术发展下,数据一致性的解决方法和技...博文来自:巨杉数据库

  分布式系统中的一致性协议之两阶段提交协议(2PC)     两阶段提交协议是很常见的解决分布式事务的方式,他可以保证分布式事务中,要么所有参与的进程都提交事务成功,要么都取消事务,这样做可以在分布式环...博文来自:chenglinhust的专栏

  上篇文章:分布式系统漫谈【拾】_分布式事务一致性:阿里方案本文说说分布式事务的经典场景:秒杀的实现。可以说秒杀是任何一个电商系统都无法避免的一个场景了,而在互联网公司面试过程中,也经常喜欢以这个场景来...博文来自:xinzun的专栏

  使用Redis缓存的模式的有很多种,下面就逐一介绍。一、数据库和redis分别处理不同的数据类型数据库处理要求强一致实时性的数据,例如金融数据、交易数据;redis处理不要求强一致实时性的数据,例如网...博文来自:Dustin_CDS的博客

  该文章来自于阿里巴巴技术协会(ATA)精选文章。背景可用性(Availability)和一致性(Consistency)是分布式系统的基本问题,先有著名的CAP理论定义过分布式环境下二者不可兼得的关系...博文来自:yizich的专栏

  高并发场景有抢红包,双十一抢商品等。如何去处理这些高并发场景呢?1.从存储介质考虑:有内存缓存和磁盘缓存,内存缓存的速度是比磁盘缓存要高出几十倍的,因此可以考虑存储介质在内存上。想象一下如果抢红包的时...博文来自:u012345683的博客

  问题背景前台(浏览器或app等)提交一个请求到A系统,A系统调B系统创建订单,同时A系统需要扣除金币(数据库操作)。这是一个跨进程事务,需要保持两个系统的数据一致性。如果数据都保存在B系统,则没有系统...博文来自:Kingson_Wu

  分布式系统介绍了分布式系统的定义、实现原则和几种形式,详细介绍了微服务架构的分布式系统,并使用SpringCloud框架演示了一个完整的微服务系统的实现过程。5-1CAP原则和BASE理论简介5-2分...博文来自:小炫的博客

  今天在看书的时候,看到了分布式事务的一致性问题,就赶紧记下来。一、分布式事务介绍在我们平时写的代码中,我们可以用一个事务包含许多个SQL调用,如果某一个数据库操作发生异常,就可以将之前的SQL操纵全部...博文来自:yanghan1222的博客

  幂等操作:是其任意多次执行所产生的影响均与一次执行的影响相同(不用担心重复执行会对系统造成改变)业务场景:1.绑定银行卡发送短信接口。如果APP重复点击调用后台接口,后台重复调用第三方接口,造成用户收...博文来自:感冒石头的博客

  问题:一台MySQL,一台Redis,两台应用服务器,用户的数据存储持久化在MySQL中,缓存在Redis,有请求的时候从Redis中获取缓存的用户数据,有修改则同时修改MySQL和Redis中的数据...博文来自:猪猪

  对于单机系统和集中系统是指一台或多台主计算机组成的中心节点,并数据和业务处理逻辑都集中于这个中心节点上,客户端仅仅负责数据的录入和展示。集中式系统的最大优点就是部署简单,同时不需要考虑分布式系统的协作...博文来自:CWeeYii的专栏

  在分布式系统中,选择采用多副本方案,就要面对数据一致性问题;数据一致性主要是指在多副本的情况下,如何保证各个副本间数据的一致性。...博文来自:动静之间

  为啥出现一致性问题在传统单体架构中,数据状态的处理都在同一个服务和数据库中,而具有ACID特性的数据库支持强一致性,就是说数据库本身是不会出现不一致的状态的,比如我们常用的关系型数据库MySQL就是通...博文来自:Vioaos Blog

  1.一致性协议和算法2PC协议:两阶段提交协议3PC协议:Paxos算法:ZAP协议:2.远程通信...博文来自:Owen Fang的博客

  从本文开始,笔者将花三到四篇文章的篇幅,介绍Paxos算法。包括它的理论基础、基本实现、变种实现,其它保证最终一致性的算法,等等。...博文来自:JAVA入门中

  Eureka是springcloud中的一个组件,提供注册发现功能。它是一个分布式应用,用于管理微服务地址。通过部署多个EurekaServer避免单点故障。     随着微服务的规模越来越...博文来自:wk022的专栏

  分布式事务实现:消息驱动模式详细介绍3种分布式事务实现的模式中的消息驱动模式并通过完整实例演示了消息驱动模式下,实现微服务系统的分布式事务的完整过程。7-1分布式事务实现:消息驱动模式7-2消息驱动模...博文来自:小炫的博客

  前言:所谓的redis数据一致性即当进行修改或者保存、删除之后,redis中的数据也应该进行相应变化,不然用户再次查询的时候很可能查询出已经删除过的脏数据。一、缓存一致的必要性还是接上篇来说,我们已经...博文来自:润青

  大体方案1.双写优点:简单,灵活缺点:a.业务代码耦合严重.b.如何保证双写成功?c.同步双写会增加响应时间2.消息队列优点:简单缺点:a.业务代码耦合b.需要保证写入MQ成功c.需要保证MQ集群的稳...博文来自:一千个哈利波特

  在开发中遇到的问题:项目中订单服务的订单数据量太大,mysql中查询订单过慢,如何保证快速的查询并且不会影响订单下单的速度?当时想到的是使用ElasticSearch搜索引擎来解决查询过慢的问题,大概...博文来自:lp2388163的博客

  为了提升性能,缓存在系统开发中具有普遍的应用。常见的模式是先查询/更新db后再去更新缓存,那么如何保证db和缓存的数据一致性的问题是实际开发中经常遇到的问题。这种场景下容易造成数据不一致的问题主要是缓...博文来自:技术进阶之路

  1.概述在上一篇文章《缓存读取术之防止缓存雪崩》里我们解决了引入缓存后读数据的问题,本文分析写数据要考虑的问题。数据变更时是更新缓存还是淘汰缓存?是先写DB再写Cache,还是先写Cache再写DB?...博文来自:思码堂

  一、读写过程1、读:(1)先读cache,如果数据命中则返回(2)如果数据未命中则读db(3)将db中读取出来的数据入缓存2、写:(1)先淘汰cache(2)再写db二、数据不一致原因amp...博文来自:码农云帆哥的博客

  在系统服务化的过程中,我们不得不面临的一个问题是多个子系统间业务数据的一致性如何保证,解决这个问题有多种方式。XA可能很多人首先会想到XA规范中定义的分布式事务,下图是XA规范中定义的DTP(Dist...博文来自:高爽Coder

  ElasticSearch汇总请查看:ElasticSearch教程——汇总篇 一致性概念在分布式环境下,一致性指的是多个数据副本是否能保持一致的特性。在一致性的条件下,系统在执行数据更新操作之后能够...博文来自:东天里的冬天

  对于分布式系统了解的不是很多,今天学习了一下分布式系统中CAP,记录一下,希望能对分布式系统的学习有所帮助Consistency(一致性),数据一致更新,所有数据变动都是同步的Availability...博文来自:沉迷代码无法自拔

  1,什么是分布式系统的数据一致性在分布式应用系统中,同一份数据保存在各个子系统中,当其中一份数据发生变化的时候,需要确保其他系统中的相同数据保持一致。即关联数据逻辑关系是否正确和完整,数据的一致性模型...博文来自:letempsar的专栏

  在一些对数据有强一致性要求的应用中,数据库宕机导致数据丢失是我们一定要避免的情况。所以保证数据的一致性对我们而言非常重要。如何做到主从的强一致性呢?在单机数据库中为了保证事务更新操作不会丢失会使用WA...博文来自:的博客

  本文分享了MySQL复制数据一致性校验和修复的详细步骤及其自动化实现思路和方法,对MySQL复制架构运维中该项工作的实施及其自动化具有较好的借鉴意义。...博文来自:hangxing_2015的博客

  MySQL一主多从时如何保证从库读到的数据是最新的?等主库位点方案主库事务更新后,马上执行showmasterstatus得到当前主库执行的File和position;选定一个从库执行查询操作;在从库...博文来自:greensea669的博客

  通常在项目中会有业务需求需要调用第三方的接口或者合作平台,这时会有一个喜闻乐见的问题:在调用三方接口后,如果更新本地数据失败了,怎么办?示例:本地项目需要推送订单的状态到第三方接口,并根据返回值更新本...博文来自:m0_38030271的博客

  jquery/js实现一个网页同时调用多个倒计时(最新的)nn最近需要网页添加多个倒计时. 查阅网络,基本上都是千遍一律的不好用. 自己按需写了个.希望对大家有用. 有用请赞一个哦!nnnn//jsn...博文来自:Websites

  前言:前面几章都是分析MediaCodec相关源码,有收到提问,说MediaCodec到底是硬解码还是软解码?看下今天的Agenda:nMediaCodec到底是硬解码还是软解码nMediaMuxer...博文来自:何俊林

  最近比较有空,大四出来实习几个月了,作为实习狗的我,被叫去研究Docker了,汗汗!nnDocker的三大核心概念:镜像、容器、仓库n镜像:类似虚拟机的镜像、用俗话说就是安装文件。n容器:类似一个轻量...博文来自:我走小路的博客

  突发奇想:n  今天坐在工位上,玩着电脑,突然回想起自己刚开始接触计算机的画面,很是感慨。感慨时光飞逝的同时,也感慨自己从事计算机行业原来都是有渊源的呀。n  想起了那么多珍贵的回忆,决定写篇文章记录...博文来自:赵亚兰的博客

本文链接:http://ravynhart.com/qiangyizhixing/339.html