

实现

CAP 封装了在 ASP.NET Core 中的使用依赖注入来获取 Publisher （ICapPublisher）的接口。而启动方式类似于 “中间件” 的形式，通过在 Startup.cs 配置 ConfigureServices 和 Configure 进行启动。

消息表¶

当系统引入CAP之后并首次启动后，CAP会在客户端生成 2 个表，分别是 Cap.Published, Cap.Received 。注意表名可能在不同的数据库具有不同的大小写区分，如果你在运行项目的时候没有显式的指定数据库生成架构(Schema)或者表名前缀(TableNamePrefix)的话，默认情况下就是以上的名字。

Cap.Published：这个表主要是用来存储 CAP 发送到MQ(Message Queue)的客户端消息，也就是说你使用 ICapPublisher 接口 Publish 的消息内容。

Cap.Received：这个表主要是用来存储 CAP 接收到 MQ(Message Queue) 的客户端订阅的消息，也就是使用 CapSubscribe[] 订阅的那些消息。

2.2 版本以前： Cap.Queue：这个表主要是CAP内部用来处理发送和接收消息的一个临时表，通常情况下，如果系统不出现问题，这个表将是空的。

Published 和 Received 表具有 StatusName 字段，这个字段用来标识当前消息的状态。目前共有 Scheduled，Successed，Failed 等几个状态。

在 2.2 版本以前的所有状态为：Scheduled，Enqueued，Processing，Successed，Failed

CAP 在处理消息的过程中会依次从Scheduled 到 Successed 来改变这些消息状态的值。如果是状态值为 Successed，代表该消息已经成功的发送到了 MQ 中。如果为 Failed 则代表消息发送失败。

CAP 2.2 以上版本中会针对 Scheduled,Failed 状态的消息 CAP 会于消息持久化过后 4 分钟后开始进行重试，重试的间隔默认为 60 秒，你可以在 CapOptions 中配置的FailedRetryInterval 来调整默认间隔时间。

2.2 版本以前， CAP 会对状态为 Failed 的消息默认进行 100 次重试。

消息格式¶

CAP 采用 JSON 格式进行消息传输，以下是消息的对象模型：

NAME	DESCRIPTION	TYPE
Id	消息编号	int
Version	消息版本	string
Name	消息名称	string
Content	内容	string
Group	所属消费组	string
Added	创建时间	DateTime
ExpiresAt	过期时间	DateTime
Retries	重试次数	int
StatusName	状态	string

对于 Cap.Received 中的消息，会多一个 Group 字段来标记所属的消费者组。

对于消息内容 Content 属性里面的内容CAP 使用 Message 对象进行了一次二次包装。一下为Message对象的信息

NAME	DESCRIPTION	TYPE
Id	CAP生成的消息编号	string
Timestamp	消息创建时间	string
Content	内容	string
CallbackName	回调的订阅者名称	string

其中 Id 字段，CAP 采用的 MongoDB 中的 ObjectId 分布式Id生成算法生成。

EventBus¶

EventBus 采用发布-订阅风格进行组件之间的通讯，它不需要显式在组件中进行注册。

上图是EventBus的一个Event的流程，关于 EventBus 的更多信息就不在这里介绍了...

在 CAP 中，为什么说 CAP 实现了 EventBus 中的全部特性，因为 EventBus 具有的两个大功能就是发布和订阅，在 CAP 中使用了另外一种优雅的方式来实现的，另外一个 CAP 提供的强大功能就是消息的持久化，以及在任何异常情况下消息的可靠性，这是EventBus不具有的功能。

CAP 里面发送一个消息可以看做是一个 “Event”，一个使用了CAP的ASP.NET Core 应用程序既可以进行发送也可以进行订阅接收。

重试¶

重试在整个CAP架构设计中具有重要作用，CAP 中会针对发送失败或者执行失败的消息进行重试。在整个 CAP 的设计过程中有以下几处采用的重试策略。

1、发送重试

在消息发送过程中，当出现 Broker 宕机或者连接失败的情况亦或者出现异常的情况下，这个时候 CAP 会对发送的重试，第一次重试次数为 3，4分钟后以后每分钟重试一次，进行次数 +1，当总次数达到50次后，CAP将不对其进行重试。

你可以在 CapOptions 中设置FailedRetryCount来调整默认重试的总次数。

当失败总次数达到默认失败总次数后，就不会进行重试了，你可以在 Dashboard 中查看消息失败的原因，然后进行人工重试处理。

2、消费重试

当 Consumer 接收到消息时，会执行消费者方法，在执行消费者方法出现异常时，会进行重试。这个重试策略和上面的 发送重试 是相同的。

数据清理¶

数据库消息表中具有一个 ExpiresAt 字段表示消息的过期时间，当消息发送成功或者消费成功后，CAP会将消息状态为 Successed 的 ExpiresAt 设置为 1小时 后过期，会将消息状态为 Failed 的 ExpiresAt 设置为 15天 后过期。

CAP 默认情况下会每隔一个小时将消息表的数据进行清理删除，避免数据量过多导致性能的降低。清理规则为 ExpiresAt 不为空并且小于当前时间的数据。也就是说状态为Failed的消息（正常情况他们已经被重试了 50 次），如果你15天没有人工介入处理，同样会被清理掉。