cap分布式理论-纯实际场景讲解

cap分布式理论-纯实际场景讲解  ,视频可以看小破站 cap分布式理论-纯实际场景讲解_哔哩哔哩_bilibili

CAP理论是分布式架构中重要的理论
下面的解释都是在分布式场景下进行,也就是一个服务部署到了多台机器上,并且会有很多不同的服务之间会相互调用.这样你才能组成分布式

同一个服务部署到多台机器上,数据库是一样的
那样不就浪费空间了?关键是我们现在访问量太大,返回数据太慢了.
要是访问同一个数据库,那你还拆分出来服务干嘛.那么多请求全请求到一个DB上.那和没单体没区别了.

一致性(Consistency)
数据的一致性,当一个findUserById请求发送过来,发送到nginx上
nginx转用户服务,但是用户服务可能会部署到多台机器上(高可用,但是数据是相同的,部署多台机器上提高可用性)
此时不管从哪台机器上返回的数据,都必须要是相等的.
不能出现,我一个服务,在不同的机器上,返回了不同的数据.nginx转发到了A这台机器返回用户名称为admin
而转发到B返回了admin1,这肯定就不对了.所以我们要保证数据的一致性
通过mq等手段来实现数据一致性.

可用性(Availability) 
也就是高可用,我们的服务部署到了多台机器上,一个user_service挂了,其它机器还能提供服务
其实上面的案例已经说明了.用户服务可能会部署到多台机器上.
上面的案例很美好了.但是有一个场景
比如A,B 2台服务器,分别放了一个用户服务,
我们update name by id,nginx负载均衡到A机器的用户服务上,A写进了数据库的同时,发送消息给其它机器
让它们也去写入这个数据.假如A写入到数据库成功了.其它机器收到了消息后,突然就挂了.
然后又重启了.而mq已经消费完了.不会再进行数据同步了.此时用户去请求select user by id.只有一台机器之前成功修改了.
此时每次负载均衡返回回来的数据,不就不一致了嘛.
而如果我们要搞分布式系统,那么一定会出现这种情况.那么我们保证可用性的同时,一致性肯定是不保证不了的.
所以C和A是冲突的.

分区容忍性(Partition tolerance) 
也就是一个服务挂掉了,不会影响其它服务的运行.
继续之前的案例.
那么当B挂了的时候,A如果不同时挂掉,等下B重启了.
nginx负载均衡,返回出来的数据,就又不一样了.如果要返回回来的数据一样
那么最好的办法是把A也挂掉,然后在内网悄悄同步完数据后再全部一起上线.
但是整个用户服务不就凉凉了.那么P不就不能成立了(挂了1个服务,影响到了第1个服务).
所以CAP永远不能同时出现.要么是AP,要么是CP