目录
1、分布式系统当中的CAP理论
1.1、CAP理论
1.2、Partitiontolerance
1.3、Consistency
1.4、Availability
2、Kafka中的CAP机制
C++软件异常排查从入门到精通系列教程（核心精品专栏，订阅量已达600多个，欢迎订阅，持续更新...）
https://blog.csdn.net/chenlycly/article/details/125529931C/C++实战专栏（重点专栏，专栏文章已更新500多篇，订阅量已达数百个，欢迎订阅，持续更新中...）https://blog.csdn.net/chenlycly/article/details/140824370C++ 软件开发从入门到实战（重点专栏，专栏文章已更新280多篇，欢迎订阅，持续更新中...）https://blog.csdn.net/chenlycly/category_12695902.htmlVC++常用功能开发汇总（专栏文章列表，欢迎订阅，持续更新...）https://blog.csdn.net/chenlycly/article/details/124272585C++软件分析工具从入门到精通案例集锦（专栏文章，持续更新中...）https://blog.csdn.net/chenlycly/article/details/131405795开源组件及数据库技术（专栏文章，持续更新中...）https://blog.csdn.net/chenlycly/category_12458859.html网络编程与网络问题分享（专栏文章，持续更新中...）https://blog.csdn.net/chenlycly/category_2276111.html
1、分布式系统当中的CAP理论
1.1、CAP理论
分布式系统(distributed system)正变得越来越重要，大型网站几乎都是分布式的。
分布式系统的最大难点，就是各个节点的状态如何同步。
为了解决各个节点之间的状态同步问题，在1998年，由加州大学的计算机科学家EricBrewer提出分布式系统的三个指标，分别是：
- Consistency：一致性
- Availability：可用性
- Partitiontolerance：分区容错性
EricBrewer说，这三个指标不可能同时做到。最多只能同时满足其中两个条件，这个结论就叫做CAP定理。
CAP理论是指：分布式系统中，一致性、可用性和分区容忍性最多只能同时满足两个。
一致性:Consistency
- 通过某个节点的写操作结果对后面通过其它节点的读操作可见。
- 如果更新数据后，并发访问情况下后续读操作可立即感知该更新，称为强一致性
- 如果允许之后部分或者全部感知不到该更新，称为弱一致性。
- 若在之后的一段时间(通常该时间不固定)后，一定可以感知到该更新，称为最终一致性。
可用性:Availability
任何一个没有发生故障的节点必须在有限的时间内返回合理的结果。
分区容错性:Partitiontolerance
- 部分节点宕机或者无法与其它节点通信时，各分区间还可保持分布式系统的功能
- 一般而言，都要求保证分区容忍性。所以在CAP理论下，更多的是需要在可用性和一致性之间做权衡。
1.2、Partitiontolerance
先看Partitiontolerance，中文叫做"分区容错"。
大多数分布式系统都分布在多个子网络。每个子网络就叫做一个区(partition)。分区容错的意思是，区间通信可能失败。比如，一台服务器放在中国，另一台服务器放在美国，这就是两个区，它们之间可能无法通信。
上图中，G1和G2是两台跨区的服务器。G1向G2发送一条消息，G2可能无法收到。系统设计的时候，必须考虑到这种情况。
一般来说，分区容错无法避免，因此可以认为CAP的P总是存在的。即永远可能存在分区容错这个问题。
在这里，给大家重点推荐一下我的几个热门畅销专栏，欢迎订阅：（博客主页还有其他专栏，可以去查看）
专栏1：（该精品技术专栏的订阅量已达到600多个，专栏中包含大量项目实战分析案例，有很强的实战参考价值，广受好评！专栏文章已经更新到200篇以上，持续更新中！欢迎订阅！）
C++软件调试与异常排查从入门到精通系列文章汇总（专栏文章，持续更新中...）https://blog.csdn.net/chenlycly/article/details/125529931
本专栏根据多年C++软件异常排查的项目实践，系统地总结了引发C++软件异常的常见原因以及排查C++软件异常的常用思路与方法，详细讲述了C++软件的调试方法与手段，以图文并茂的方式给出具体的项目问题实战分析实例（很有实战参考价值），带领大家逐步掌握C++软件调试与异常排查的相关技术，适合基础进阶和想做技术提升的相关C++开发人员！
考察一个开发人员的水平，一是看其编码及设计能力，二是要看其软件调试能力！所以软件调试能力（排查软件异常的能力）很重要，必须重视起来！能解决一般人解决不了的问题，既能提升个人能力及价值，也能体现对团队及公司的贡献！
专栏中的文章都是通过项目实战总结出来的，包含大量项目问题实战分析案例，有很强的实战参考价值！专栏文章还在持续更新中，预计文章篇数能更新到200篇以上！
专栏2：（本专栏涵盖了C++多方面的内容，是当前重点打造的专栏，订阅量已达300多个，专栏文章已经更新到500多篇，持续更新中！欢迎订阅！）
C/C++实战进阶（专栏文章，持续更新中...）https://blog.csdn.net/chenlycly/category_11931267.html
以多年的开发实战为基础，总结并讲解一些的C/C++基础与项目实战进阶内容，以图文并茂的方式对相关知识点进行详细地展开与阐述！专栏涉及了C/C++领域多个方面的内容，包括C++基础及编程要点（模版泛型编程、STL容器及算法函数的使用等）、数据结构与算法、C++11及以上新特性（不仅看开源代码会用到，日常编码中也会用到部分新特性，面试时也会涉及到）、常用C++开源库的介绍与使用、代码分享（调用系统API、使用开源库）、常用编程技术（动态库、多线程、多进程、数据库及网络编程等）、软件UI编程（Win32/duilib/QT/MFC）、C++软件调试技术（排查软件异常的手段与方法、分析C++软件异常的基础知识、常用软件分析工具使用、实战问题分析案例等）、设计模式、网络基础知识与网络问题分析进阶内容等。
专栏3：
C++常用软件分析工具从入门到精通案例集锦汇总（专栏文章，持续更新中...）https://blog.csdn.net/chenlycly/article/details/131405795
常用的C++软件辅助分析工具有SPY++、PE工具、Dependency Walker、GDIView、Process Explorer、Process Monitor、API Monitor、Clumsy、Windbg、IDA Pro等，本专栏详细介绍如何使用这些工具去巧妙地分析和解决日常工作中遇到的问题，很有实战参考价值！
专栏4：
VC++常用功能开发汇总（专栏文章，持续更新中...）https://blog.csdn.net/chenlycly/article/details/124272585
将10多年C++开发实践中常用的功能，以高质量的代码展现出来。这些常用的高质量规范代码，可以直接拿到项目中使用，能有效地解决软件开发过程中遇到的问题。
专栏5： （本专栏涵盖了C++多方面的内容，是当前重点打造的专栏，专栏文章已经更新到300多篇，持续更新中！欢迎订阅！）
C++ 软件开发从入门到实战（专栏文章，持续更新中...）https://blog.csdn.net/chenlycly/category_12695902.html
根据多年C++软件开发实践，详细地总结了C/C++软件开发相关技术实现细节，分享了大量的实战案例，很有实战参考价值。
1.3、Consistency
Consistency中文叫做"一致性"。意思是，写操作之后的读操作，必须返回该值。举例来说，某条记录是v0，用户向G1发起一个写操作，将其改为v1。接下来，用户的读操作就会得到v1。这就叫一致性。
问题是，用户有可能向G2发起读操作，由于G2的值没有发生变化，因此返回的是v0。G1和G2读操作的结果不一致，这就不满足一致性了。
为了让G2也能变为v1,就要在G1写操作的时候,让G1向G2发送一条消息,要求G2也改成v1
这样的话，用户向G2发起读操作，也能得到v1。
1.4、Availability
Availability中文叫做"可用性"，意思是只要收到用户的请求，服务器就必须给出回应。用户可以选择向G1或G2发起读操作。不管是哪台服务器，只要收到请求，就必须告诉用户，到底是v0还是v1，否则就不满足可用性。
2、Kafka中的CAP机制
kafka是一个分布式的消息队列系统，既然是一个分布式的系统，那么就一定满足CAP定律，那么在kafka当中是如何遵循CAP定律的呢？kafka满足CAP定律当中的哪两个呢？
kafka满足的是CAP定律当中的CA，其中Partitiontolerance通过的是一定的机制尽量的保证分区容错性。
其中C表示的是数据一致性。A表示数据可用性。
kafka首先将数据写入到不同的分区里面去，每个分区又可能有好多个副本，数据首先写入到leader分区里面去，读写的操作都是与leader分区进行通信，保证了数据的一致性原则，也就是满足了Consistency原则。
然后kafka通过分区副本机制，来保证了kafka当中数据的可用性。但是也存在另外一个问题，就是副本分区当中的数据与leader当中的数据存在差别的问题如何解决，这个就是Partitiontolerance的问题。
kafka为了解决Partitiontolerance的问题，使用了ISR的同步策略,来尽最大可能减少Partitiontolerance的问题。
每个leader会维护一个ISR(asetofin-syncreplicas,基本同步)列表。
ISR列表主要的作用就是决定哪些副本分区是可用的，也就是说可以将leader分区里面的数据同步到副本分区里面去，决定一个副本分区是否可用的条件有两个：
- replica.lag.time.max.ms=10000副本分区与主分区心跳时间延迟
- replica.lag.max.messages=4000副本分区与主分区消息同步最大差
produce请求被认为完成时的确认值:request.required.acks=0。
- ack=0：producer不等待broker同步完成的确认，继续发送下一条(批)信息。
- ack=1(默认)：producer要等待leader成功收到数据并得到确认，才发送下一条message。
- ack=-1：producer得到follower确认，才发送下一条数据。
