4.3 KiB
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 采用 发布-订阅 风格进行组件之间的通讯，它不需要显式在组件中进行注册。
上图是EventBus的一个Event的流程，关于 EventBus 的更多信息就不在这里介绍了...
在 CAP 中，为什么说 CAP 实现了 EventBus 中的全部特性，因为 EventBus 具有的两个大功能就是发布和订阅， 在 CAP 中 使用了另外一种优雅的方式来实现的，另外一个 CAP 提供的强大功能就是消息的持久化，以及在任何异常情况下消息的可靠性，这是EventBus不具有的功能。
CAP 里面发送一个消息可以看做是一个 “Event”，一个使用了CAP的ASP.NET Core 应用程序既可以进行发送也可以进行订阅接收。
5.4 重试
重试在实现分布式事务中具有重要作用，CAP 中会针对发送失败或者执行失败的消息进行重试。在整个 CAP 的设计过程中有以下几处采用的重试策略。
① 消息发送重试
在消息发送过程中，当出现 Broker 宕机或者连接失败的情况亦或者出现异常的情况下，这个时候 CAP 会对发送的重试，重试策略为默认 15 次失败重试，当15次过后仍然失败时，CAP会将此消息状态标记为失败。
② 消息消费重试
当 Consumer 接收到消息时，会执行消费者方法，在执行消费者方法出现异常时，会进行重试。这个重试策略和 ① 是相同的。
③ 失败消息重试
CAP 会定期针对 ① 和 ② 中状态为“失败的”消息进行重试，CAP会对他们进行重新“入队(Enqueue)”，入队时会将消息中的重试次数标记为0，状态置为 Enqueued。