CAP

CAP原理按照定义，指的是C（Consistency）一致性，A（Availability）可用性，P（Partition tolerance）分区容错性在一个完整的计算机系统中三种特性不能同时得到完全满足。

Consistency（（强）一致性）：指的是在同一时间点，所有的数据状态是否是一致的。对于一致性的理解，可以从关系型数据库的事务概念出发来进行理解。例如：一次银行账户的转账，双方账户

的金额必须同时增加，和减少。不能出现转账账户已经扣钱，而被转账账户未能增加金额的情况。

Availability（（高）可用性）：大并发请求的场景下对服务器的要求特别高，可以接受更多请求，响应更快，拥有非常高的非故障运行时间百分率。

Partition tolerance（分区容错性）：指的是在整个系统拥有两台或以上数量的计算机单元提供服务，当其中部分分区节点故障时，整个系统依然可以向用户提供可靠的服务。

在保证分区容错性的前提下，同时只能满足 一致性或可用性

强一致性 --- 牺牲可用性 阻塞数据库 并发高的项目不适用

高可用性 --- 成本高

最终一致性 -- 通过本地消息表事务将一个大事务拆分成多个环节，基于消息 队列完成转发，每个节点单独处理，完成最终一致性

* 期间放弃了一致性 并且需要人去维护

↓

BASE 理论 :

Basically Available 基本可用

Availability 一致性

Soft State 软状态（数据不一致 最终一致）

Eventually consistent - 最终一致

Docker部署 RabbitMQ

使用 management版本 因为有管理页面

docker pull rabbitmq:management

docker run -d -p 5672:5672 -p 15672:15672 --name rabbitmq rabbitmq:management

 http://10.31.60.13:15672

账号 密码都是guest

dotnet run --urls=http://*:11111

Nuget包

DotNetCore.CAP

DotNetCore.CAP.RabbitMQ

DotNetCore.CAP.SqlServer

开源的 .NET 标准库，用于处理分布式事务

Appsettings 配置

Program

上游发布消息

Publish 之后 数据库会多两张表

RabbitMQ 上游往交换机里写 不关心队列

交换机下游有多个队列

根据规则将数据转发到不同队列

如果没有指定下游队列 数据会丢失

如果是在Controller中，直接添加[CapSubscribe("")] 来订阅相关消息。

在 xxxService中：

如果方法没有位于Controller 中，那么订阅的类需要继承 ICapSubscribe，然后添加[CapSubscribe("")]标记

注入

builder.Services.AddScoped<RecordService>();

原创作者: u_16904651 转载于: https://blog.51cto.com/u_16904651/11607953