什么是cap
cap理论是分布式系统中非常重要的一个理念
什么是cap理论：
Consistency一致性
Availability可用性
Partition-tolerance分区容忍性
CP: 高一致性C和分区容忍性P的系统，放弃可用性A。
AP: 可用性A和分区容忍性P的系统，放弃高一致性C。
AC: 可用性A和高一致性C系统，放弃分区容忍性P。
根据CAP定理，存在网络分区的情况下，只能在可用性和一致性之间选择。
说一个例子：
以下面一个简单案例为例，写操作在主节点服务器，读操作在从节点服务器：
CLient ----> Web-API -----> 分布式缓存/DB(写操作在主节点+读操作在从节点)
假设有一个网络分区：
CLient ----> Web-API -----> 分布式缓存/DB(主节点+ 这里增加了网络分区 +从节点)
如果因为网络分区通讯出错，导致主从服务器节点无法同步数据，写入主节点的数据，无法在从节点服务器读出。
我们只能做两件事，在事务完成后发送500错误响应给用户，放弃了可用性，破坏用户体验，这是一种悲观做法，另外一个乐观做法是早点发送200正确响应给用户，放弃一致性，保住可用性，保住了用户体验。
哪个更好？没有哪个更好，完全取决于场景情况决定。
知乎有两个大神的回答感觉很不错，分享一下
P是分布式系统的起点，全称：network partition，常指拔网线和宕机，因为这两种现象，同伴是无法区分的，所以归为一类。分布式系统下，P是大概率事件，假设服务器开一年必宕机一次，则365台的集群必然天天宕机。数据分存这365台之上，则数据必然天天不完整。你设计的分布式系统能容忍吗？绝大多数是不能，不能则
2，复制，是解决这一问题的标准做法
3，复制，引发了C
4，C引发了A
作者：赵老师
链接：https://www.zhihu.com/question/54105974/answer/138151325
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
一个分布式系统里面，节点组成的网络本来应该是连通的。然而可能因为一些故障，使得有些节点之间不连通了，整个网络就分成了几块区域。数据就散布在了这些不连通的区域中。这就叫分区。
当你一个数据项只在一个节点中保存，那么分区出现后，和这个节点不连通的部分就访问不到这个数据了。这时分区就是无法容忍的。
提高分区容忍性的办法就是一个数据项复制到多个节点上，那么出现分区之后，这一数据项就可能分布到各个区里。容忍性就提高了。
然而，要把数据复制到多个节点，就会带来一致性的问题，就是多个节点上面的数据可能是不一致的。要保证一致，每次写操作就都要等待全部节点写成功，而这等待又会带来可用性的问题。
总的来说就是，数据存在的节点越多，分区容忍性越高，但要复制更新的数据就越多，一致性就越难保证。为了保证一致性，更新所有节点数据所需要的时间就越长，可用性就会降低。
作者：知乎用户
链接：https://www.zhihu.com/question/54105974/answer/139037688
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
结论
在系统设计中考虑CAP定理是重要的。必须考虑整个系统的所有故障点。Casandra，Zoo Keeper，Kafka等技术可以在数据层面实现最终一致性。在AP和CP之间选择并不容易。在大多数情况下，它取决于业务要求。
最新文章
- spring定时任务之quartz
- lvs+keepalived+nginx实现高性能负载均衡集群
- Android高性能ORM数据库DBFlow入门
- android:layout_gravity和android:gravity属性的区别（转）
- About_MySQL Select--来自copy_03
- spring属性依赖注入
- 深拷贝 vs 浅拷贝 释放多次
- 表视图控制器(TableViewController)(二)
- 开始写自己的iOS技术博客了
- Nginx 301重定向域名
- 对student进行增删改
- iOS 实现类似QQ分组样式的几种方式
- flume 1.7在windows下的安装与测试
- node.js-v6新版安装过程
- Spring Boot 2 - 使用CommandLineRunner与ApplicationRunner
- 莫烦theano学习自修第十天【保存神经网络及加载神经网络】
- Python Django框架笔记（四）：数据分页和CSRF跨站点请求伪造
- java注解 @SuppressWarnings注解用法
- [APP] Android 开发笔记 003-使用Ant Release 打包与keystore加密说明
- Web 通信 之 长连接、长轮询(转）