做网站的需要哪些职位,给公司创建网站,网络营销品牌推广公司哪家好,wordpress 首页显示分类文章互联网行业是大势所趋#xff0c;从招聘工资水平即可看出#xff0c;那么如何提升自我技能#xff0c;满足互联网行业技能要求#xff1f;需要以目标为导向#xff0c;进行技能提升。 本文主要针对分布式系统设计、架构(数据一致性)做了分析#xff0c;祝各位早日走上属于… 互联网行业是大势所趋从招聘工资水平即可看出那么如何提升自我技能满足互联网行业技能要求需要以目标为导向进行技能提升。 本文主要针对分布式系统设计、架构(数据一致性)做了分析祝各位早日走上属于自己的成金之路。 目录 问题分析概念解读Most Simple原理解读eBey、去哪儿、蘑菇街分布式事务案例分析参考资料 1.问题解析 要想做架构必须识别出问题即是谁的问题什么问题。 明显的分布式架构解决的是高并发的问题。 高并发下服务高可用和数据一致性问题当规模规模较小时单库 HA 即可满足请求当业务规模持续增加单库已经无法满足业务需求业界主流做法是对业务进行分表、分库那么原来的有些业务现在则要在一个事务中保证两个库同时操作成功或操作不成功(一个库成功一个库失败要么重新尝试失败库操作直到成功要么回滚成功库)。 随之而来的问题既是如何保证分库时业务操作的数据一致性。理解分布式架构、分布式系统数据一致性的问题、起源是第一步。 这里多啰嗦一点分库后每个库可以采取不同的语言以时下很流行的微服务向外提供服务但是业务量不大的情况下使用微服务到增加了复杂性及技术成本。明白技术的起源针对不同的业务量采取适当的架构、以最恰当的方式承载业务是架构师必须具备的能力。 2.常见概念解读 关系型数据库通常具有 ACID 特性原子性Atomicity、一致性Consistency、隔离性Isolation、持久性Durability。Base (basically available, soft state, eventually consistent)一种 Acid 的替代方案BASE 的可用性是通过支持局部故障而不是系统全局故障来实现的。化学理论中 ACID 是酸、Base 恰好是碱。CAP 定律在分布式系统中同时满足 CAP 定律中的一致性、可用性和分区容错性三者是不可能的。强一致当更新操作完成之后任何多个后续进程或者线程的访问都会返回最新的更新过的值。这种是对用户最友好的就是用户上一次写什么下一次就保证能读到什么。根据 CAP 理论这种实现需要牺牲可用性常见的 RDBMS。弱一致性系统并不保证续进程或者线程的访问都会返回最新的更新过的值。系统在数据写入成功之后不承诺立即可以读到最新写入的值也不会具体的承诺多久之后可以读到。最终一致性弱一致性的特定形式。系统保证在没有后续更新的前提下系统最终返回上一次更新操作的值。在没有故障发生的前提下不一致窗口的时间主要受通信延迟系统负载和复制副本的个数影响。DNS 是一个典型的最终一致性系统。 为保证可用性互联网分布式架构将强一致性需求转换成最终一致性的需求并通过系统执行幂等性的保证保证数据的最终一致性。 ※幂等性 (Idempotence)分布式架构的基石即同一个操作无论请求多少次其结果都相同。 典型的是HTTP 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. 每个概念实际所解决的是人遇到的某个特定的问题发现其背后所代表的问题是理解分布式架构、分布式系统数据一致性第二步。 3.Most Simple原理解读 假设有一个从账户取钱的远程 API可以是 HTTP 的也可以不是我们暂时用类函数的方式记为bool withdraw(account_id, amount) withdraw 的语义是从 account_id 对应的账户中扣除 amount 数额的钱如果扣除成功则返回 true账户余额减少 amount如果扣除失败则返回 false账户余额不变。 值得注意的是和本地环境相比我们不能轻易假设环境的可靠性。 一种典型的场景是 withdraw 请求已经被服务器端正确处理但服务器端的返回结果由于网络等原因被掉丢了导致客户端无法得知处理结果。 如果是在网页上一些不恰当的设计可能会使用户认为上一次操作失败了然后刷新页面这就导致了 withdraw 被调用两次账户也被多扣了一次钱。如图1所示 一种更轻量级的解决方案是幂等设计。我们可以通过一些技巧把 withdraw 变成幂等的比如 int create_ticket() bool idempotent_withdraw(ticket_id, account_id, amount) create_ticket 的语义是获取一个服务器端生成的唯一的处理号 ticket_id它将用于标识后续的操作。idempotent_withdraw和withdraw 的区别在于关联了一个 ticket_id一个 ticket_id 表示的操作至多只会被处理一次每次调用都将返回第一次调用时的处理结果。这样idempotent_withdraw 就符合幂等性了客户端就可以放心地多次调用。基于幂等性的解决方案中一个完整的取钱流程被分解成了两个步骤 调用create_ticket()获取ticket_id调用idempotent_withdraw(ticket_id, account_id, amount)。 虽然 create_ticket 不是幂等的但在这种设计下它对系统状态的影响可以忽略加上 idempotent_withdraw 是幂等的所以任何一步由于网络等原因失败或超时客户端都可以重试直到获得结果。如图所示 和分布式事务相比幂等设计的优势在于它的轻量级容易适应异构环境以及性能和可用性方面。在某些性能要求比较高的应用幂等设计往往是唯一的选择。 幂等性是分布式架构、分布式系统数据一致性的底层基本原理理解这一步是走上成金之路的关键。 4.案例分析 eBay 经典的 BASE 模式一个最常见的场景如果产生了一笔交易需要在交易表增加记录同时还要修改用户表的金额。这两个表属于不同的库及远程服务所以就涉及到分布式事务一致性的问题。核心思想是用两个事务来保证一致性同时用异步保证了可用性一个事务处理主要操作增加交易表记录与异步消息构建另外一个事务用来处理构建的异步消息第一个事务即处理主要业务又记录次要业务同时还能快速返回保证了高可用性第二个事务则用来保证数据的一致性。(即将 buyer 和 seller 表更新的处理转为线下处理消息日志可以存储到本地文本、数据库或消息队列再通过业务规则自动或人工发起重试。人工重试更多的是应用于支付场景通过对账系统对事后问题的处理类似与淘宝双11重复支付后续退款)。一个经典的解决方法将主要修改操作以及更新用户表的异步消息放在一个本地事务来完成。同时为了达到多次重试的幂等性避免重复消费用户表消息带来的问题增加一个更新记录表 updates_applied 来记录已经处理过的消息。在第一事务中通过本地的数据库的事务保障保证增加交易表记录、增加两条异步消息队列记录(一条处理 buyer 表、一条处理 seller 表)同时成功或同时失败。在第二事务中分别读出消息队列但不删除通过判断更新记录表 updates_applied 来检测相关消息是否被执行如没执行则执行相关业务逻辑(保证幂等性保证即使执行过程中异常重复执行没有任何问题)执行完所有消息后然后增加一条操作记录到 updates_applied事务到此结束。用事务保证两个异步消息执行及 updates_applied 的一致性操作(又称为分布式事务框架)。最后删除队列。去哪儿网分布式事务方案优先使用异步方案原理和a.eBay 经典的 BASE 模式类似对业务逻辑处理不能保证幂等性的增加去重表(即 a 中的 updates_applied) 来处理对于不适合异步消息处理的业务如 A、B、C 三方需要同步处理才能返回在 A、B、C 三个库中分别维护一个事务记录表 recorda/recordb/recordc当 A、B、C 业务事务处理完将结果存到对应的 recordx 中由一个中心服务对比查询三方的事物记录表有如下两种处理方式第一种A、B成功C失败了重试C知道C成功第二种C不可能成功时回滚A、B如C为扣库存当库存为0时则不能成功(不考虑补库存)。另这种 recordx 表由 RPC 框架层进行维护对业务是透明的。 蘑菇街交易创建过程场景将下单功能拆分为12个子业务(见参考资料b)对于非实时、非强一致性的关联业务使用 eBay 经典的 BASE 模式思想第一个本地事务执行成功后以发消息通知、关联事务异步化执行方案来避免 a 中第二个事务的分布式事务框架对业务带来的侵入和复杂性具体方案是基于DB事件变化通知给 MQ而 MQ 消费者通过 ACK保证消息一定消费成功完成强一致性(消息可能会被重发所以消息消费方要保证幂等性)。而对要求同步做、强一致性要求的场景(和 b 的 ii 相同场景)如优惠券和优惠券减库存可以引入a.eBay经典的 BASE 模式的第二个事务(分布式事务框架)来处理但是复杂性会急剧上升另一种方式是创建一个不可见订单然后在同步调用锁券和扣减库存时针对调用异常失败或者超时发出废单消息到 MQ。如果消息发送失败本地会做时间阶梯式的异步重试优惠券系统和库存系统收到消息后会进行判断是否需要做业务回滚这样就准实时地保证了多个本地事务的最终一致性。根据业务进行不同的方案处理解决了分布式架构、分布式系统的数据一致性问题。 整体来说蘑菇街的案例可迁移性强可移植性好可以尝试模拟下实际场景驾驭分布式架构、分布式系统数据一致性方案祝大家早日走上成金之路。 5.参考资料 a.幂等性 http://www.cnblogs.com/weidagang2046/archive/2011/06/04/idempotence.html b.架构案例详细 http://weibo.com/ttarticle/p/show?id2309403965965003062676 c.http://www.infoq.com/cn/articles/solution-of-distributed-system-transaction-consistenc 作者成金之路 链接http://www.cnblogs.com/uttu/p/6553307.html 本文已获得作者成金之路独家授权转载请标明作者及出处。 内容转载自公众号 51CTO博客 了解更多 赞赏
