架构师速成8.3-架构师必须要了解的规则

简介: 作为一个架构师,有些规则是必须要掌握的,这就想软件的公理,如果你学物理不知道牛顿定律,那就不要学了。在软件行业也有类似的东西,我称之为软件定律。例如: ACID,CAP,BASE ACID 传统数据库系统中,事务具有ACID 4个属性 (1)原子性(Atomicity):事务是一个原子操作单元,其对数据的修改,要么全都执行,要么全都不执行。 (2)一致性

作为一个架构师,有些规则是必须要掌握的,这就想软件的公理,如果你学物理不知道牛顿定律,那就不要学了。在软件行业也有类似的东西,我称之为软件定律。例如:

ACID,CAP,BASE

ACID

传统数据库系统中,事务具有ACID 4个属性

(1)原子性(Atomicity):事务是一个原子操作单元,其对数据的修改,要么全都执行,要么全都不执行。

(2)一致性(Consistent):在事务开始和完成时,数据都必须保持一致状态。这意味着所有相关的数据规则都必须应用于事务的修改,以保持数据的完整性;事务结束时,所有的内部数据结构(如B树索引或双向链表)也都必须是正确的。

(3)隔离性(Isolation):数据库系统提供一定的隔离机制,保证事务在不受外部并发操作影响的“独立”环境执行。这意味着事务处理过程中的中间状态对外部是不可见的,反之亦然。

(4)持久性(Durable):事务完成之后,它对于数据的修改是永久性的,即使出现系统故障也能够保持。

可以说,数据库系统是伴随着金融业的需求而快速发展起来。对于金融业,可用性和性能都不是最重要的,而一致性是最重要的,用户可以容忍系统故障而停止服务,但绝不能容忍帐户上的钱无故减少,而强一致性的事务是这一切的根本保证。

CAP

在2000的PODC(Principles of Distributed Computing)会议上,Brewer提出了著名的CAP理论。CAP指的是:Consistency、Availability和Partition Tolerance。

(1)Consistency(一致性):一致性是说数据的原子性,这种原子性在经典的数据库中是通过事务来保证的,当事务完成时,无论其是成功还是回滚,数据都会处于一致的状态。在分布式环境中,一致性是说多个节点的数据是否一致。

(2)Availability(可用性):可用性是说服务能一直保证是可用的状态,当用户发出一个请求,服务能在有限时间内返回结果。

(3)Partition Tolerance(分区容错性):Partition是指网络的分区。可以这样理解,一般来说,关键的数据和服务都会位于不同的IDC。

CAP理论告诉我们,一个分布式系统不可能同时满足一致性,可用性和分区容错性这三个需求,三个要素中最多只能同时满足两点。三者不可兼顾,此所谓鱼与熊掌不可兼得也!而对于分布式数据系统而言,分区容错性是基本要求,否则就不称其为分布式系统了。因此架构设计师不要把精力浪费在设计如何能同时满足三者的完美分布式系统上,而是应该进行权衡取舍。这也意味着分布式系统的设计过程,也就是根据业务特点在C(一致性)和A(可用性)之间寻求平衡的过程,要求架构师真正理解系统需求,把握业务特点。

后来:CAP理论的作者终于给了我长久以来想要的答案:CAP理论并非严格的三选二,大多数情况下,A和C是可以兼得的,因为大多数情况下,P都不存在。
P只有在结点之间通信延迟大于可接受的范围时才出现(结点之间开始近似隔离,状态开始不一致),即P一旦出现,我们选择继续提供服务那么状态就肯定不一致,也就等于放弃了C;我们选择不提供服务,那么就等于放弃了A。通俗一点,P并不是目标,也不是手段,它是伴随着“多结点,网络,数据,共享”的要求而必然出现的,出现的原因是因为网络的不可靠性及结点通信延迟(延迟的原因可能是由于硬件,网络,或者压力太大而无法及时响应)。

弄清楚了CAP的P,也就弄清楚了CAP理论的实质,戴在头顶的紧箍咒便永久摘掉了。

CAP理论并不是要求我们悲观地放弃A和C任何一方,相反,它可以乐观地指导我们将C和A最大化;ACID和BASE分别处于CAP理论的两个极端,ACID强调强一致性,BASE强调高可用性,两者把重点都放在A和C上,淡化了P也可变的事实;通过对P的出现检测,发现P之后的限制和约束,P结束之后的补偿和恢复,通过采用千差万别的策略,我们可以避免P带来的C和A的严重损失,实现A和C的最大化来提高整个系统的正确性和可用性。ACID和BASE并非水火不容,我们可以在同一个系统中,既使用ACID,又使用BASE。

 

 

BASE

BASE来自于互联网的电子商务领域的实践,它是基于CAP理论逐步演化而来,核心思想是即便不能达到强一致性(Strong consistency),但可以根据应用特点采用适当的方式来达到最终一致性(Eventual consistency)的效果。BASE是Basically Available、Soft state、Eventually consistent三个词组的简写,是对CAP中C & A的延伸。BASE的含义:

(1)Basically Available:基本可用;

(2)Soft-state:软状态/柔性事务,即状态可以有一段时间的不同步;

(3)Eventual consistency:最终一致性;

BASE是反ACID的,它完全不同于ACID模型,牺牲强一致性,获得基本可用性和柔性可靠性并要求达到最终一致性。

后面我会不断充实这本软件定律。
作者:arrowcat
出处:http://www.cnblogs.com/hustcat/
本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。

本文为Gleasy原创文章,转载请指明引自Gleasy团队博客

目录
相关文章
|
2月前
|
存储 架构师 测试技术
架构之道——人人都是架构师
本文的探讨和编写主要围绕三个方面:架构是什么?架构师要解决的问题有哪些?解决这些问题的方法论是什么?最后作者希望人人都能具备架构师思维。
|
5月前
|
机器学习/深度学习 人工智能 架构师
【架构师】AI时代架构师必备技能
【架构师】AI时代架构师必备技能
129 5
|
6天前
|
缓存 NoSQL Java
秒杀圣经:10Wqps秒杀,16大架构绝招,一文帮你秒变架构师 (2)
高并发下的秒杀系统设计是一个复杂的挑战,涉及多个关键技术点。40岁老架构师尼恩在其读者交流群中分享了16个关键架构要点,帮助解决高并发下的秒杀问题,如每秒上万次下单请求的处理、超卖问题的解决等。这些要点包括业务架构设计、流量控制、异步处理、缓存策略、限流熔断、分布式锁、消息队列、数据一致性、存储架构等多个方面。尼恩还提供了详细的实战案例和代码示例,帮助读者全面理解和掌握秒杀系统的架构设计。此外,他还分享了《尼恩Java面试宝典》等资源,帮助读者在面试中脱颖而出。如果你对高并发秒杀系统感兴趣,可以关注尼恩的技术自由圈,获取更多详细资料。
秒杀圣经:10Wqps秒杀,16大架构绝招,一文帮你秒变架构师 (2)
|
6天前
|
缓存 NoSQL Java
秒杀圣经:10Wqps高并发秒杀,16大架构杀招,帮你秒变架构师 (1)
高并发下,如何设计秒杀系统?这是一个高频面试题。40岁老架构师尼恩的读者交流群中,近期有小伙伴在面试Shopee时遇到了这个问题,未能很好地回答,导致面试失败。为此,尼恩进行了系统化、体系化的梳理,帮助大家提升“技术肌肉”,让面试官刮目相看。秒杀系统设计涉及16个架构要点,涵盖业务架构、流量架构、异步架构、分层架构、缓存架构、库存扣减、MQ异步处理、限流、熔断、降级、存储架构等多个方面。掌握这些要点,可以有效应对高并发场景下的秒杀系统设计挑战。
秒杀圣经:10Wqps高并发秒杀,16大架构杀招,帮你秒变架构师 (1)
|
3月前
|
存储 架构师 测试技术
架构之道:人人都是架构师(2)
每个业务系统的开发者都应该具备一定的架构师素养,架构师的重要职责不仅仅是做决策,更重要的是提升团队的整体能力。一个好的架构师应该聚焦于业务和系统,定义问题和结果,设计系统、模块和代码,同时也需要解决跨域问题,确定团队间的边界,制定规范,统一语言,并创建一个让每个人都能成长为架构师的环境,以促进团队的敏捷性。本文旨在探讨如何培养架构思维,并阐述了架构师的职责、能力模型、方法论,以及如何成为架构师。
128 10
|
3月前
|
存储 运维 架构师
架构之道:人人都是架构师(1)
架构之道:人人都是架构师
152 8
|
3月前
|
监控 安全 前端开发
交易所系统开发(源码正式版)/需求逻辑/玩法详情/规则架构
交易所源码开发是指基于特定的需求和要求,从头开始构建一个自定义的交易所平台的开发过程。这种开发可以包括以下几个关键方面:
|
3月前
|
监控 算法 Java
高并发架构设计三大利器:缓存、限流和降级问题之配置Sentinel的流量控制规则问题如何解决
高并发架构设计三大利器:缓存、限流和降级问题之配置Sentinel的流量控制规则问题如何解决
|
5月前
|
运维 架构师 安全
架构师养成手册:架构师职责
小米是一名热情的技术爱好者和架构师,他探讨了架构师的角色和职责。主要涉及六个方面:顶层设计,需与企业战略目标对齐,制定架构原则;规划可适应未来变化的企业架构,分析需求并关注技术趋势;全局视角制定可落地的架构方案,兼顾全局与局部优化;技术选型与难题解决,选择合适技术并解决实际问题;关注方案与代码的广度与深度,确保宏观设计与微观实现的统一;同时,架构师还需具备管理能力,包括团队协作、资源调配和风险管理。
175 11
|
5月前
|
XML 存储 JSON
软件体系结构 - 架构风格(9)基于规则的系统架构风格
【4月更文挑战第21天】软件体系结构 - 架构风格(9)基于规则的系统架构风格
482 0