网站维护的具体问题,绍兴市网站建设公司,拉新app推广平台排名,如何查询网站开发21天学会C语言#xff1f;3天学会弹钢琴#xff1f;放弃一切错误方法#xff0c;从今天开始“刻意练习”#xff0c;因为这才是最强大的#xff0c;也是唯一正确的学习方法。--《刻意练习》Anders Ericsson引言CAP问题已经成了计算机科学中一个研究领域#xff0c;之前说… 21天学会C语言3天学会弹钢琴放弃一切错误方法从今天开始“刻意练习”因为这才是最强大的也是唯一正确的学习方法。--《刻意练习》Anders Ericsson引言CAP问题已经成了计算机科学中一个研究领域之前说到分布式系统有哪些优势时讲到三个提升1.系统可用性提升。2.系统并发能力提升3.系统容错能力提升。那么这三方面在实施起来可以同时满足吗答案是不能设计分布式系统的时候设计者需要理解一个重要的理论概念CAP定理。BASE: Basically Available基本可用, Soft state软状态和 Eventually consistent最终一致性2012年Brewer发表了一篇文章重新解释了他对CAP定理的理解首先网络分区的发生是小概率事件当网络没有发生分区的时候没有任何理由放弃C或者A其次在同一个系统中C和A的选择可能发生多次不同的子系统可以做不一样的选择当条件不同时做出的选择可以不一样例如不同的操作、数据、用户可能会导致不同的选择最后这三个属性不是0和1的选择而是线性的。可用性很明显可以从0%到100%其实一致性甚至分区容忍性也是有差别的CAP分别代表什么吗关于CAP它是2000 年 7 月加州大学伯克利分校的 Eric Brewer 教授在 ACM PODC 会议上提出 CAP 猜想。2 年后麻省理工学院的 Seth Gilbert 和 Nancy Lynch 从理论上证明了 CAP。之后CAP 理论正式成为分布式计算领域的公认定理。C的全拼是 Consistency代表一致性的意思。A的全拼是Availability代表可用性的意思。P的全拼是Partition tolerance代表分区容错性的意思。三选二CP、AP、CA一个分布式系统最多同时满足一致性 (Consistency)可用性 (Availability) 和分区容忍性 (Partition Tolerance) 这三项中的两项。同时满足一致性C和可用性A就要牺牲掉容错性P同时满足可用性A和分区容错性P就要牺牲掉一致性C同时满足一致性C和分区容错性P就要牺牲掉可用性A这三个象限只能同时满足其中两个圆圈的交集。举个例子用 Redis Cluster高可用架构举例redis就能会将数据分片到多个实例(按照slot存储)中即一个机房分担一部分数据。Master 负责写Master会自动同步到 Slava。Reids去中心集群架构优点无中心架构三机房部署其中一主一从构成一个分片之间通过异步复制同步数据异步复制存在数据不一致的时间窗口保证高性能的同时牺牲了部分一致性一旦某个机房掉线则分片上位于另一个机房的 slave 会被提升为 master 从而可以继续提供服务可扩展性可线性扩展到1000多个节点节点可动态添加或删除。降低运维成本提高系统的扩展性和可用性。分析这个分布式架构中满足了CAP中哪个两个定理优点1中讲到三机房部署每个机房有一主一从即一个 Master 对应一个 Slave 但是你会发现机房1中的 Master 1 连接的 Slave 在机房2机房2中的 Master 2 连接的 Slave 在机房3机房3中的 Master 3 连接的 Slave 在机房1这样构成一个环为什么要这样设计假设机房断电or火灾or其他各种原因反正就是机房1所有机器都不能用了。这个时候那机房1的全部数据都不能访问了吗这显然是我们不希望的。前面已经说了Master 负责写Master会自动同步到 Slava如果 Master写服务宕机Slave 读服务会被提升为 master 也就是说机房1的数据在机房2的Slava2上还有备份数据还在在宕机的master没有恢复前 Slave 要同时承担读写服务虽然累一点但是还能用这样设计是为了提高可用性A和容错性P。系统准许你一台机器或者整个机房都宕机。系统仍然能。公众号【转行程序员】回复”加群“我会拉你进技术群。但是你会发现单个机房如果距离很远 Master 1 的数据同步到 Slave2 上是跨机房跨机房同步肯定不如同机房块这样一来 Slave2 负责的读就会有延迟Master1 要更新的数据还没有同步到他在另一个机房的备份前读操作就是不一致的这样设计显然是牺牲掉一致性C。相信这样分析应该能理解CAP定理了。进一步分析让同一组 Master - Slave 放在一个机房同机房复制数据不是更快这样能不能解决数据一致C问题答案是能还有更好的解决一致性的办法就是不要Master - Slave 组合就一台机器一台机器同时担任读写请求没有延迟不存在数据一致性问题。这是时候如果宕机了怎么办这样的架构下那就真的是不可用了解决了一致性C却牺牲了可用性A和容错性P太不划算了。总之分布式系统下CAP确实无法同时满足在Reids去中心集群架构中最优的解决方案还是满足可用性A和分区容错性P就要牺牲掉一致性C即使跨机房同步数据延迟也不过1s数据不一致的问题只出现在1s内日常开发中很少遇到要求强一致性的场景。例如订单系统用户更新了订单支付状态读订单状态是在从库有什么读场景等不来这一秒如果真的必须要求强一致性那可能就必须调整分布式架构方案来。总结本文主要讲解了CAP定理的概念为什么要学习这个概念设计高可用分布式系统时你必须知道系统的短处懂得CAP能让你根据实际情况有舍有得。面试会被经常问到比如你说你使用了消息队列解决了系统耦合问题提高了响应速度那面试官问题使用消息队列有啥缺点如果你知道CAP定理这个问题还难吗显然消息的延迟会带来数据不一致问题。理想情况下消息不丢失那数据会最终一致你能保证消息不丢失吗如何解决机问题如果是我我会选择“最终一致性”就是说不管消息延迟多久甚至丢失设计一个离线定时任务定期去扫描两个系统的数据有不一致的情况就主动刷新同步这样保证最终一致。参考资料CAP theorem – WikipediaCAP Twelve Years Later: How the “Rules” Have Changed联系我VX搜索【转行程序员】回复”加群“我会拉你进技术群。讲真的在这个群哪怕您不说话光看聊天记录也是一种成长。阿里/腾讯/百度资深工程师、Google技术大神、IBM工程师、还有我王炸、敖丙、各路大牛都在有任何不明白的都进群提问。最后觉得王炸的文章不错就来个三连吧关注 转发 点赞