网站建设怎么接单,红包网站开发,VM2008 做网站,免费网站设计模板微信搜一搜架构师修行之路菜菜哥#xff0c;帮忙解决一个问题是不是面试又被虐了#xff1f;是的呢#xff0c;这次面试官问我什么是CAP#xff1f;这个可就说来话长了......01PARTCAP说到CAP#xff0c;首先不能不说分布式系统#xff0c;前面几篇也说过#xff0c;分布… 微信搜一搜架构师修行之路菜菜哥帮忙解决一个问题是不是面试又被虐了是的呢这次面试官问我什么是CAP这个可就说来话长了......01PARTCAP说到CAP首先不能不说分布式系统前面几篇也说过分布式系统的出现很大的一个原因是要解决单机系统的瓶颈问题但是工作模式上还需要保证系统的可用性一致性性能等。一个分布式系统网络不可靠的特性必然存在这就导致了分布式系统比单机系统要面对更多的不确定因素的挑战。CAP是针对分布式系统提出的一个重要理论在很多开发者眼里被视为金律。CAP理论是对分布式系统特点的一个高度抽象也是我们设计一个分布式系统很好的参考框架。在CAP理论提出初期有很多人提出各种质疑后来CAP之父又再次给CAP理论做出了重要修正。很多架构师在设计系统的时候都以CAP理论为重要参考依据其中CAP不可能三角是最重要的指导思想。CAP把一个分布式系统抽象为三个固有属性1. 一致性Consistency:客户端无论访问系统的哪个节点要么读到的数据都是最新的要么读取失败。这本质上是说分布式系统的所有节点上的数据都是实时同步的一致性强调的是数据正确性。2. 可用性Availability当系统内任意一个节点发生了故障非故障的节点仍然能响应客户端的请求无论这个响应返回的是最新数据还是旧数据。这个特性可以看做是对客户端的一个保证无论何时我都能给你响应。3. 分区容错性Partition Tolerance即使系统内部某个节点有消息丢失或者高延迟系统仍然能持续提供服务。这个指标强调的是对分布式系统的容错能力。分布式系统是由通过网络通信的多个节点组成因为系统需要持续对外提供服务所以分区容错性P是分布式系统必须要保证的。三角理论这个时候就尴尬到只需要从一致性和可用性这两个指标中选择一个所以有人根据这个特点提出基于CAP理论的分布式系统分区容错是固有而且必须要保证的一个指标设计分布式系统要根据业务的场景来选择一致性还是可用性。02PART使用CAP理论设计系统当我们在设计一个分布式系统的时候由于分区容错性必须要保证所以就演化成了是选择AP还是选择CP指标。当我们选择了CP(一致性)的时候客户端的每次请求一定会读取到最新的数据但是因为消息丢失节点通信高延迟等原因被读取的节点中的数据不一定是最新数据所以为了保证一致性这个时候返回给客户端的是出错信息换句话说这个节点在这个时候是不可用的。当我们选择了AP可用性的时候为了始终响应客户端的请求哪怕节点上的信息不是最新数据也要给客户端响应这个时候客户端得到的可能是过时的数据。真实的线上系统环境中其实还存在另外一个场景随着节点的不断增加严格的一致性会导致系统的响应时间变慢系统资源消耗的增加这个时候为了维护强一致性的成本可能要超出我们的预期在这种情况下我们就只剩下了一种选择更多的选择可用性放弃强一致性采用最终一致性。退一步说在分布式系统节点不是很多的情况下CAP三个指标在一定程度上是可以同时能够保证的。但是针对分布式数据库事务领域后来的专家已经证实并不适用于CAP。举一个很简单的例子如果要设计一套分布式的日志收集系统改如何选择呢俗话说脱离业务的架构就是耍流氓具体的系统设计还要看每个业务的场景。日志收集的分布式系统很典型的一个特点是读少写多数据重要性级别低数据量大可以容忍部分数据丢失。这样的场景下我们可以优先选择AP能持续的提供服务比数据一致性要重要很多。再举一个简单例子每个公司有自己的配置中心配置中心中可能会存储分布式系统重要的配置信息比如每个节点的IP和端口信息等。在这样的系统中客户端每次读取配置中心的信息要求必须为最新数据如果不是最新数据会发生业务错误信息比如一个分布式系统中A节点挂掉了配置中心中所有的节点数据必须要保证一致删除A节点信息不然的话客户端还能读到A节点的信息然后去访问A节点会发生业务异常的。03PARTBASE理论由于CAP原则在只能在AP和CP之间二选一而且在选择强一致性的同时会大大牺牲性能这对于并发和响应时间都有要求的系统都是难以接受的。于是eBay公司尝试选择了不同的方案提出了一套名为BASE的理论。BASE理论基本思想是牺牲了数据一致性来满足系统的可用性在系统发生故障或者部分数据不一致的时候扔能提供系统“主要可用”。BASE全称Basically Available(基本可用)Soft state软状态,和 Eventually consistent最终一致性三个短语的缩写BASE理论是对CAP理论的一个延伸或者说是对AP模型的一个延伸它是对互联网大规模分布式系统的一个总结强调的是可用性。Basically Available(基本可用)基本可用不同的系统有不同的解释但是总体思想是保证系统大部分可用。在一个分片的分布式存储系统中假设有10个节点来存储数据假设其中两个节点发生故障那么其他8个节点仍然能提供服务既系统的80%仍然可用。我们平时用的流量削峰策略其实本质上也是要保证系统的主要可用。服务降级服务熔断也是通过牺牲一部分系统的可用性来保证核心功能可用。以上所说都说明了一个事实基本可用本质上是一种妥协在节点出现故障的时候通过牺牲非核心功能的可用性来保证核心功能的可用性。Soft state软状态对于服务端的系统来说每个节点或者服务都可以设计为有状态stateful和无状态stateless这在根本上决定了一个分布式系统是否具有良好的扩展性故障恢复等高级特性。对于完全无状态的服务来说具有更好的水平扩展性而对于有状态的服务来说如果要实现水平扩展可能涉及到状态的迁移等过程比较复杂。基于有状态和无状态的思想BASE理论提出一个介于中间的状态soft state服务端会维护数据的状态但是有一个期限过了这个期限服务端将会丢弃这些状态信息恢复正常的状态。Eventually consistent最终一致性最终一致性是指系统在经过一段时间内每个节点的数据会达到一个一致的状态换句话说它是必须经过一段时间才能达到强一致性的过程。由于强一致性的缺陷现在几乎所有的互联网系统都是基于最终一致性来设计架构当然如果最终一致性不满足业务场景的情况下才会使用牺牲性能和可用性来采用强一致性。比如在支付的场景中必须要采用强一致性来设计系统不然这个锅是程序员背不起的。至于如何实现最终一致性有很多的解决方案目前最常用的是利用MQ消息来实现前提是你的MQ需要保证不丢失消息。举个很简单的例子一个典型的电商场景商品管理系统和订单系统是两个物理上隔离的两个系统可以看做是两个微服务当一个订单支付成功之后商品管理系统需要把对应的商品减少库存这个过程可以采用最终一致性来设计。当订单支付成功发一个mq消息当商品管理系统接收到这个消息会把对应商品的库存扣掉。04PART写在最后CAP理论是分布式设计中一个重要的参考指标但是这个理论并非放之四海而皆准的思想它的适用场景仅仅在非数据库系统的原子读写。在互联网高速发展的今天分布式系统早已不是之前的简单系统了架构师在设计系统中还需要考虑安全性扩展性自动化等诸多因素所以现在做程序员多累呀BASE理论绕过了难以实现的分布式强一致性采用一种权衡的策略来达到业务要求。BASE理论主要针对数据分片场景让不同的数据分布在不同的节点以提升系统的可用性。END●程序员修神之路--为什么我会了SOA你们还要逼我学微服务●程序员过关斩将--数据库的乐观锁和悲观锁并非真实的锁●程序员修神之路--设计一套RPC框架并非易事●程序员过关斩将--要想获取我的用户信息就得按照规矩来●程序员过关斩将--更加优雅的Token认证方式JWT●程序员过关斩将--cookie和session的关系其实很简单●程序员修神之路--用NOSql给高并发系统加速●程序员修神之路--高并发系统设计负载均衡架构●程序员过关斩将--你为什么还在用存储过程●程序员修神之路--问世间异步为何物●程序员修神之路--提高网站的吞吐长按添加菜菜好友关注后回复“大礼包”和“福利”领取惊喜点分享点点赞点在看
