BPA.CAP/document/5.实现.md

## 5、实现

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

### 5.1 消息表

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

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

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

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

`Published` 和 `Received` 表具有 StatusName 字段，这个字段用来标识当前消息的状态。目前共有 Scheduled，Enqueued，Processing，Successed，Failed 等几个状态。CAP 在处理消息的过程中会依次从 Scheduled 到 Successed 来改变这些消息状态的值。如果是状态值为 Successed，代表该消息已经成功的发送到了 MQ 中。如果为 Failed 则代表消息发送失败，消息发送失败后 CAP 会对消息进行重试，直到成功。

**关于数据清理**： CAP 默认情况下会每隔一个小时将消息表的数据进行清理删除，避免数据量过多导致性能的降低。清理规则为 ExpiresAt 不为空并且小于当前时间的数据。

### 5.2 消息格式

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

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

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



### 5.3 EventBus 

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

![](http://images2017.cnblogs.com/blog/250417/201708/250417-20170804153901240-1774287236.png)

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

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

![](https://camo.githubusercontent.com/452505edb71d41f2c1bd18907275b76291621e46/687474703a2f2f696d61676573323031352e636e626c6f67732e636f6d2f626c6f672f3235303431372f3230313730372f3235303431372d32303137303730353137353832373132382d313230333239313436392e706e67)

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


### 5.4 重试

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

**① 消息发送重试**

在消息发送过程中，当出现 Broker 宕机或者连接失败的情况亦或者出现异常的情况下，这个时候 CAP 会对发送的重试，重试策略为默认 **15** 次失败重试，当15次过后仍然失败时，CAP会将此消息状态标记为失败。

**② 消息消费重试**

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

**③ 失败消息重试**

CAP 会定期针对 ① 和 ② 中状态为“失败的”消息进行重试，CAP会对他们进行重新“入队(Enqueue)”，入队时会将消息中的重试次数标记为0，状态置为 Enqueued。