写点什么

代价与平衡

用户头像
林昱榕
关注
发布于: 2020 年 07 月 08 日

本文从缓存和 CAP 理论两个方面来谈谈关于代价与平衡的意识。


缓存


缓存可以说是系统性能优化的第一利器,应用非常广泛,比如 cpu 缓存、操作系统缓存、数据库换成、jvm 缓存、CDN、反向代理、分布式缓存系统等等。在目前的软件系统架构中,缓存基本是标配了,几乎无处不在。但同时,缓存使用不当也是会带来负面效应的。


缓存常见的一些问题:

  • 频繁修改的数据:缓存这类数据,应用来不及读取就失效或被更新,徒增系统负担;

  • 没有热点的访问:这种情况会导致大部分数据还没被再次访问就被挤出缓存了;

  • 数据不一致和脏读:缓存数据一般设置失效时间,这段时间内可能会产生数据不一致,故需根据实际应用场景来应对该问题,比如:容忍、数据更新时立即更新缓存(带来系统开销和事务一致性问题)、通知缓存失效,删除缓存(更加稳妥)。

  • 缓存雪崩(大面积失效)

  • 缓存穿透(访问内容不存在)

  • 缓存击穿(热点失效,并发大)

  • 缓存预热


由此可见,缓存给系统带来收益的同时,也是需要我们付出一定的代价的,我们需要慎重地应对上述问题。其中有一个指导原则是:尽可能简单地使用缓存,而不是过分依赖它


CAP 理论


CAP 理论对分布式系统的特性做了高度抽象,形成了以下三个指标:

  • 一致性(Consistency):每次读取要么获得最近写入的数据,要么获得一个错误。

  • 可用性(Availability):请求在限定时间内从非失败的节点得到非失败的响应,但不保证返回的是最新写入的数据(正确结果只能通过一致性保证)。

这里需要强调的是:

  • 非失败”的响应(注意不是“正确”响应)是指不是光有响应就可以了,系统得是在实实在在地提供服务,而不是在报错;

  • 在限定时间内返回是指这个响应是在预期时间内返回的,而不出现请求超时。

  • 分区容错性(Partition Tolerance):尽管任意数量的消息被节点间的网络丢失(或延迟),系统仍继续运行。


CAP 定理表明,在存在网络分区的情况下,一致性和可用性必须二选一。而在没有发生网络故障时,即分布式系统正常运行时,一致性和可用性是可以同时被满足的。


对此,我们需要根据具体应用场景进行权衡选择:例如,对于大多数互联网应用来说(如门户网站),因为机器数量庞大,部署节点分散,网络故障是常态,可用性是必须要保证的,所以只有舍弃一致性来保证服务的 AP。而对于银行等,需要确保一致性的场景,通常会权衡 CA 和 CP 模型,CA 模型网络故障时完全不可用,CP 模型具备部分可用性。



  • CA (consistency + availability),这样的系统关注一致性和可用性,它需要非常严格的全体一致的协议,比如“两阶段提交”(2PC)。CA 系统不能容忍网络错误或节点错误,一旦出现这样的问题,整个系统就会拒绝写请求,因为它并不知道对面的那个结点是否挂掉了,还是只是网络问题。唯一安全的做法就是把自己变成只读的。

  • CP (consistency + partition tolerance),这样的系统关注一致性和分区容忍性。它关注的是系统里大多数人的一致性协议,比如:Paxos 算法(Quorum 类的算法)。这样的系统只需要保证大多数结点数据一致,而少数的结点会在没有同步到最新版本的数据时变成不可用的状态。这样能够提供一部分的可用性。

  • AP (availability + partition tolerance),这样的系统关心可用性和分区容忍性。因此,这样的系统不能达成一致性,需要给出数据冲突,给出数据冲突就需要维护数据版本。Dynamo 就是这样的系统。


此外,我们还需要明确以下两点:

  • CAP 理论关心的对象需满足:interconnected 和 share data,即互联和数据共享。它关注的是对数据的读写操作,而不是分布式系统的所有功能。


  • CAP 关注的粒度是数据,而不是整个系统。


CAP 理论的定义和解释中,用的都是 system、node 这类系统级的概念,这就给很多人造成了很大的误导,认为我们在进行架构设计时,整个系统要么选择 CP,要么选择 AP。但在实际设计过程中,每个系统不可能只处理一种数据,而是包含多种类型的数据,有的数据必须选择 CP,有的数据必须选择 AP。而如果我们做设计时,从整个系统的角度去选择 CP 还是 AP,就会发现顾此失彼,无论怎么做都是有问题的。


所以在 CAP 理论落地实践时,我们需要将系统内的数据按照不同的应用场景和要求进行分类,每类数据选择不同的策略(CP 还是 AP),而不是直接限定整个系统所有数据都是同一策略。


由此可见,CAP 定理就是一个指导我们在实际落地分布式系统过程中如何根据场景来权衡一致性和可用性需求的理论,可见不存在完美的方案,每种选择背后都难免需要付出一定的代价。


而在互联网大规模分布式系统的实践中,还延伸出另外一个重量级的理论:BASE 理论。不过,这个不是本文的重点了。


总结

分布式系统设计过程中需要考虑各种细节,而实际上,我们无法满足所有的细节,因此,平衡就不可避免。


参考资料

想成为架构师,你必须知道CAP理论

想成为架构师,你必须掌握的CAP细节

推荐阅读:分布式系统架构经典资料

CAP理论:怎样舍弃一致性去换取性能

尺有所短,寸有所长:CAP和数据存储技术选择

CAP理论:这顶帽子我不想要

CAP理论:分布式系统的PH试纸,用它来测酸碱度


发布于: 2020 年 07 月 08 日阅读数: 117
用户头像

林昱榕

关注

开心生活,努力工作。 2018.02.13 加入

还未添加个人简介

评论

发布
暂无评论
代价与平衡