初识CAP定理

今天与何总讨论问题,听到了CAP定理这个名词。于是查了一下相关资料,整理一下,纪念那些不好好学习的日子:

根据相关资料,个人对CAP定理理解如下:

  • Consistency(一致性):在分布式系统中,某一时间点,数据在各节点上完全一致的程度
  • Availability(可用性):数据的执行效率,无论成功还是失败,要快速的返回结果。不要由于你的系统引起其他系统的雪崩
  • Partition tolerance(分区容错性):当分布式系统或复杂的网络环境中,某一节点(或某一机房)不可用时,其余节点(机房)可以继续提供服务的程度
  • CAP定理描述的事实:上面三个特性不可能同时满足,需要在三者间进行取舍。如何在设计模型来满足业务的需求是一门高深又恶心的学问

结合当前业务简单思考:

设想基础服务系统对CAP的不同需求,简单思考如下:

问题一:系统对一致性的要求如何,是否可以接受“最终一致性”,还是一定要强调“高度一致性”?

需要思考自己返回的数据是否会由于数据错误,而导致整体系统错乱?甚至用户会感觉自己由A变成了B,那么哪个孙子现在是A?

这时系统则需要保持高度一致性,否则是否最终一致性足矣?

问题二:系统对可用性的要求如何?

由于基础服务面临大量的业务查询请求。

一旦返回速度较慢,直接影响各业务的处理时间及用户的最终感受。我们需要对可用性心怀畏惧,小心处理,争取不当最短的那个板!

问题三:系统对分区容错性的需求如何?

任何系统都要避免单点,电信和网通都可能随时死掉。

如果由于网络原因而让某网络的用户全部舍弃、相信某老大的微博会被@个遍。手机只好关机!

让人蛋疼的结论

看来我们现在的系统对CAP很难取舍,只好对内部再进行模块区分。判断哪些模块一定要保证强一致性及容错性,又有哪些模块需要可用性及容错性,套用万金油说法就是:具体问题具体分析吧。

补充一点:设计预案是个苦B的活~

此日志为后来根据feed找回,之前的日志由于系统回滚(单点,没有分区容错性)丢失~

发表评论

电子邮件地址不会被公开。 必填项已用*标注