10分钟了解分布式CAP、BASE理论

CAP理论指出在分布式系统中,一致性、可用性和分区容错性不可同时满足,最多只能满足两个。本文详细解释了CAP理论的三个特性,并介绍了在设计分布式系统时如何选择权衡。
CAP理论

2000年7月,Eric Brewer教授提出CAP猜想;2年后,Seth Gilbert和Nancy Lynch从理论上证明了CAP;之后,CAP理论正式成为分布式计算领域的公认定理。CAP定律说的是在一个分布式计算机系统中,一致性,可用性和分区容错性这三种保证无法同时得到满足,最多满足两个。CAP:C :Consistency(一致性)A:(Availability)可用性P:(Partition Tolerance)分区容错性

让我们构造一个非常简单的分布式系统。

  • 两台服务器G1和G2

  • 两台服务器可以相互通讯

  • 客户端可以随机访问任何一台服务器 

640?wx_fmt=png

Consistency(一致性)

Gilbert and Lynch 这样描述的一致性.

any read operation that begins after a write operation completes must return that value, or the result of a later write operation

在写操作完成之后的任何读操作都必须返回该值。

客户端向G1服务器发起一个写操作,把变量初始值v0 改为v1,接下来客户端可能向节点G1读取也可能向节点G2读取;

  • 向G1发起一个读操作,得到更改后的值V1。这就是满足了一致性 

640?wx_fmt=png640?wx_fmt=png

向G2发起一个读操作,此时G1向G2发送同步消息

  1. 如果同步完成 ,那么读到的结果是v1,这样也满足了一致性 

640?wx_fmt=png640?wx_fmt=png

还未同步完成,这是G2还是v0,这就不满足一致性。

640?wx_fmt=png

(Partition Tolerance)分区容错

Gilbert and Lynch 这样描述的分区容错.

the network will be allowed to lose arbitrarily many messages sent from one node to another

网络允许丢失任意多的消息从一个节点发送到另外一个节点

在分布式环境中,节点之间的通信可能出现问题,整个系统就产生所谓的分区。所以我们在设计的时候需要考虑这种情况;剩下来的 A和C满足好,我们就可以说我们的系统有很好的分区容错性。

(Availability)可用性

Gilbert and Lynch 对 availability的描述原文. every request received by a non-failing node in the system must result in a response 系统中非失败节点收到的每个请求都必须导致响应 在可用性系统中,只要服务器没有奔溃,客户端发送请求,服务器必须返回一个相应给客户端。

为什么要CAP不能同时满足

通过上述的定义和描述知道分区无法避免,p总是要考虑的。为什么c和a无法同时做到呢?其实都是分区惹的祸。

如果我们保证一致性;那么G1写入操作之后,必须保证数据同步给G2之后,G2才能对外提供响应,这显然就没有可用性了。

反之 我们保证可用性,那就没法保证一致性了,既生瑜何生亮的悲剧。

小结

经过上面分析,在分布式系统中,我们一般会选择AP而牺牲一致性。牺牲并不意味着不关心一致性,而是首先满足A和P,如何解决C的问题。参考以下BASE理论

BASE 理论

eBay的架构师Dan Pritchett源于对大规模分布式系统的实践总结,在ACM上发表文章提出BASE理论,BASE理论是对CAP理论的延伸,核心思想是即使无法做到强一致性(StrongConsistency,CAP的一致性就是强一致性),但应用可以采用适合的方式达到最终一致性(Eventual Consitency)。

(Basically Available)基本可用

在分布式系统出现故障的时候,允许损失部分可用性,即保证核心可用。

(Soft State)软状态

接受一段时间的状态不同步,及中间状态,而改中间状态不影响系统整体可用性。这里的中间状态就是CAP理论中的数据不一致性。

(Eventually Consistent)最终一致性

上面说软状态,然后不可能一直是软状态,必须有个时间期限。在期限过后系统能够保证在没有其他新的更新操作的情况下,数据最终一定能够达到一致的状态,因此所有客户端对系统的数据访问最终都能够获取到最新的值。

总结

CAP是分布式系统设计理论,BASE是CAP理论中AP方案的延伸,对于C我们采用的方式和策略就是保证最终一致性;

参考

英文版的:https://mwhittaker.github.io/blog/an_illustrated_proof_of_the_cap_theorem/

CAP 理论十二年回顾:"规则"变了:https://www.infoq.cn/article/cap-twelve-years-later-how-the-rules-have-changed

CAP 定理的含义:http://www.ruanyifeng.com/blog/2018/07/cap.html

从零开始学架构PDF

640?wx_fmt=jpeg


### 光流法C++源代码解析与应用 #### 光流法原理 光流法是一种在计算机视觉领域中用于追踪视频序列中运动物体的方法。它基于亮度不变性假设,即场景中的点在时间上保持相同的灰度值,从而通过分析连续帧之间的像素变化来估计运动方向和速度。在数学上,光流场可以表示为像素位置和时间的一阶导数,即Ex、Ey(空间梯度)和Et(时间梯度),它们共同构成光流方程的基础。 #### C++实现细节 在给定的C++源代码片段中,`calculate`函数负责计算光流场。该函数接收一个图像缓冲区`buf`作为输入,并初始化了几个关键变量:`Ex`、`Ey`和`Et`分别代表沿x轴、y轴和时间轴的像素强度变化;`gray1`和`gray2`用于存储当前帧和前一帧的平均灰度值;`u`则表示计算出的光流矢量大小。 #### 图像处理流程 1. **初始化和预处理**:`memset`函数被用来清零`opticalflow`数组,它将保存计算出的光流数据。同时,`output`数组被填充为白色,这通常用于可视化结果。 2. **灰度计算**:对每一像素点进行处理,计算其灰度值。这里采用的是RGB通道平均值的计算方法,将每个像素的R、G、B值相加后除以3,得到一个近似灰度值。此步骤确保了计算过程的鲁棒性和效率。 3. **光流向量计算**:通过比较当前帧和前一帧的灰度值,计算出每个像素点的Ex、Ey和Et值。这里值得注意的是,光流向量的大小`u`是通过`Et`除以`sqrt(Ex^2 + Ey^2)`得到的,再乘以10进行量化处理,以减少计算复杂度。 4. **结果存储与阈值处理**:计算出的光流值被存储在`opticalflow`数组中。如果`u`的绝对值超过10,则认为该点存在显著运动,因此在`output`数组中将对应位置标记为黑色,形成运动区域的可视化效果。 5. **状态更新**:通过`memcpy`函数将当前帧复制到`prevframe`中,为下一次迭代做准备。 #### 扩展应用:Lukas-Kanade算法 除了上述基础的光流计算外,代码还提到了Lukas-Kanade算法的应用。这是一种更高级的光流计算方法,能够提供更精确的运动估计。在`ImgOpticalFlow`函数中,通过调用`cvCalcOpticalFlowLK`函数实现了这一算法,该函数接受前一帧和当前帧的灰度图,以及窗口大小等参数,返回像素级别的光流场信息。 在实际应用中,光流法常用于目标跟踪、运动检测、视频压缩等领域。通过深入理解和优化光流算法,可以进一步提升视频分析的准确性和实时性能。 光流法及其C++实现是计算机视觉领域的一个重要组成部分,通过对连续帧间像素变化的精细分析,能够有效捕捉和理解动态场景中的运动信息
微信小程序作为腾讯推出的一种轻型应用形式,因其便捷性与高效性,已广泛应用于日常生活中。以下为该平台的主要特性及配套资源说明: 特性方面: 操作便捷,即开即用:用户通过微信内搜索或扫描二维码即可直接使用,无需额外下载安装,减少了对手机存储空间的占用,也简化了使用流程。 多端兼容,统一开发:该平台支持在多种操作系统与设备上运行,开发者无需针对不同平台进行重复适配,可在一个统一的环境中完成开发工作。 功能丰富,接口完善:平台提供了多样化的API接口,便于开发者实现如支付功能、用户身份验证及消息通知等多样化需求。 社交整合,传播高效:小程序深度嵌入微信生态,能有效利用社交关系链,促进用户之间的互动与传播。 开发成本低,周期短:相比传统应用程序,小程序的开发投入更少,开发周期更短,有助于企业快速实现产品上线。 资源内容: “微信小程序-项目源码-原生开发框架-含效果截图示例”这一资料包,提供了完整的项目源码,并基于原生开发方式构建,确保了代码的稳定性与可维护性。内容涵盖项目结构、页面设计、功能模块等关键部分,配有详细说明与注释,便于使用者迅速理解并掌握开发方法。此外,还附有多个实际运行效果的截图,帮助用户直观了解功能实现情况,评估其在实际应用中的表现与价值。该资源适用于前端开发人员、技术爱好者及希望拓展业务的机构,具有较高的参考与使用价值。欢迎查阅,助力小程序开发实践。资源来源于网络分享,仅用于学习交流使用,请勿用于商业,如有侵权请联系我删除!
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值