做旅游信息的网站能赚钱吗,百度上如何发广告,网站公司上海,wordpress landx在计算机领域#xff0c;如果是初入行就算了#xff0c;如果是多年的老码农还不懂 CAP 定理#xff0c;那就真的说不过去了。CAP可是每一名技术架构师都必须掌握的基础原则啊。现在只要是稍微大一点的互联网项目都是采用 分布式 结构了#xff0c;一个系统可能有多个节点组…在计算机领域如果是初入行就算了如果是多年的老码农还不懂 CAP 定理那就真的说不过去了。CAP可是每一名技术架构师都必须掌握的基础原则啊。现在只要是稍微大一点的互联网项目都是采用 分布式 结构了一个系统可能有多个节点组成每个节点都可能需要维护一份数据。那么如何维护各个节点之间的状态如何保障各个节点之间数据的同步问题就是大家急需关注的事情了。CAP定理是分布式系统中最基础的原则。所以理解和掌握了CAP对系统架构的设计至关重要。一、什么是 CAP「 CAP定理 」又被称为 布鲁尔定理它提出对于一个分布式系统而言不能同时满足以下三点Consisteny一致性Availability可用性Partition tolerance分区容错性也就是说CAP定理指明了任何分布式系统只能同时满足这三项中的两项。如上图如果是最多同时满足两项那我们可以有三个组合CA、CP、AP。在聊这三个组合之前我们先分别看一下 Consisteny一致性、Availability可用性、Partition tolerance分区容错性的含义。假设某个系统当前有两个节点A和B两个节点分别可以由Actor进行读写两个节点之间的数据会自动完成同步。Consisteny一致性一致性的要求是指对于任何客户端上图Actor来说每次的读操作都能获得最新的数据。即当有客户端向A节点写入了新数据之后其它客户端从B节点中进行读操作所获得的数据必须也是最新的是与A节点数据保持一致的。Availability可用性可用性的要求是指每个请求都能在合理的时间内获得符合预期的响应不保证获取的结果是最新的数据。按照上图来看就是客户端只要向A节点或B节点发起请求后只要这两个节点收到了请求就必须响应给客户端但不需要保证响应的值是否正确。Partition tolerance分区容错性分区容错性是指当节点之间的网络出现问题之后系统依然能正常提供服务。讲完了C、A、P的含义和要求我们继续来看看它们之间如何组合使用。二、CAP 怎么应用先把视野回到这张图上虽然我们知道有 CA、CP、AP 三种组合方式但是在分布式系统的结构下网络是不可能做到100%可靠的。既然网络不能保证绝对可靠那 P分区容错性就是一个必选项了。原因如下如果选择 CA组合放弃 P分区容错性。还是以最上面的图中A和B节点来举例当发生节点间网络故障时为了保证 C一致性那么就必须将系统锁住不允许任何写入操作否者就会出现节点之间数据不一致了。但是锁住了系统就意味着当有写请求进来的时候系统是不可用的这一点又违背了 A可用性原则。因此分布式系统理论上是不可能有CA组合的所以我们只能选择 CP 和 AP组合架构。下面我们来详细看一下 CP架构 和 AP架构的特点CP 架构CP架构即 Consisteny一致性与 Partition tolerance分区容错性的组合。如上图由于网络问题节点A和节点B之前不能互相通讯。当有客户端上图Actor向节点A进行写入请求时准备写入Message 2节点A会不接收写入操作导致写入失败这样就保证了节点A和节点B的数据一致性即保证了Consisteny一致性。然后如果有另一个客户端上图另一个Actor向B节点进行读请求的时候B请求返回的是网络故障之前所保存的信息Message 1并且这个信息是与节点A一致的是整个系统最后一次成功写入的信息是能正常提供服务的即保证了Partition tolerance分区容错性。上述情况就是保障了CP架构但放弃了Availability可用性的方案。AP 架构AP架构即 Availability可用性与 Partition tolerance分区容错性的组合架构。如上图由于网络问题节点A和节点B之前不能互相通讯。当有客户端上图Actor向节点A进行写入请求时准备写入Message 2节点A允许写入请求操作成功。但此时由于A和B节点之前无法通讯所以B节点的数据还是旧的Message 1。当有客户端向B节点发起读请求时候读到的数据是旧数据与在A节点读到的数据不一致。但由于系统能照常提供服务所以满足了Availability可用性要求。因此这种情况下就是保障了AP架构但其放弃了 Consisteny一致性。三、CAP 注意事项了解了CAP定理后对于开发者而言当我们构建服务的时候就需要根据业务特性作出权衡考虑哪些点是当前系统可以取舍的哪些是应该重点保障的。即使是在同一个系统中不同模块的数据可能应用的CAP架构都是不同的。举个例子在某个电商系统中属于用户模块的数据账密、钱包余额等对一致性的要求很高就可以采用CP架构。而对于一些商品信息方面的数据对一致性要求没那么高但为了照顾用户体验所以对可用性要求更高一些那么这个模块的数据就可以采用AP架构。另外虽然上面第二节讲到过我们只能选择CP和AP无法选择CA。但这句话成立的前提条件是在系统发生了网络故障的情况下。然而网络故障的概率在系统的整个生命周期中占比是很小的因此我们在设计的时候虽然要考虑网络问题下的方案但也要考虑网络正常情况下的方案即在网络正常情况下CA是可以实现的我们也需要去保证在绝大多数时间下的CA架构。再者即使我们按照CAP定理三个中只能取其二但不代表我们只需要保障其中的两点而完全的放弃第三点我们应该为不能保障的第三点也做一些防备措施或者冗余方案来使系统更加的完善健全。以上就是对CAP定理的一些思考。本文原创发布于微信公众号「 不止思考 」欢迎关注一起提升 认知、工作成长、大数据、架构、Web等技术。码字不易啊喜欢的话各位看官不妨转发朋友吧。
