0x0 前言

之前看过很多关于CAP的文章，一直很懵逼，今天谈谈我在项目中遇到的问题以及对于CAP的理解

0x1 什么是CAP

image

1998年，加州大学的计算机科学家 Eric Brewer 提出，分布式系统有三个指标。

Consistency

Availability

Partition tolerance

它们的第一个字母分别是 C、A、P。

Eric Brewer 说，这三个指标不可能同时做到。这个结论就叫做 CAP 定理。

0x2 工作中遇到的分布式问题

在去年项目微服务化时，遇到一个问题：
各个微服务组件虽然在业务上尽力解耦，但是仍然有部分数据是公共的，例如：人员信息，区域组织信息，设备信息等。
这些基础信息如何处理呢？有两种方案：

使用时通过rest调用查询到本地；

直接在本地也保存一份副本；

使用第一种方案，显然效率是一个大问题，而且该方案有个严重的问题是：当某个基础服务挂掉或和其他服务连接出现问题时，其他服务都无法继续提供服务，即不满足分区容错（Partition tolerance）。
若使用第二种方案，那么每个服务不会受到其他服务挂掉或者与其他服务网络不通的影响（因为本地有业务所需的全部数据），但是引入了另一个问题：各个服务数据可能存在不一致（Consistency）。
这时，我们需要看是否要保障数各个微服务据一致性，若需要保障一致性，那么每次基础数据服务在接收到变更、删除、增加请求时，都要对其他微服务也进行相应的更新，此时引入了一个新的问题：如果有一个服务挂掉，则本次用户的变更请求就会失败，不满足可用性（Availability）。

最终，决定使用mq通知的形式：当基础数据变更后，发送MQ通知到Topic，各个微服务监听topic来修改本地存储的相应数据。这个方案虽然不能保证强一致性，但是数据最终是一致的。