Não pode escolher mais do que 25 tópicos Os tópicos devem começar com uma letra ou um número, podem incluir traços ('-') e podem ter até 35 caracteres.

5.实现.md 4.3 KiB

1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768
  1. ## 5、实现
  2. CAP 封装了在 ASP.NET Core 中的使用依赖注入来获取 Publisher (`ICapPublisher`)的接口。而启动方式类似于 “中间件” 的形式,通过在 Startup.cs 配置 `ConfigureServices` 和 `Configure` 进行启动。
  3. ### 5.1 消息表
  4. 当系统引入CAP之后并首次启动后,CAP会在客户端生成 3 个表,分别是 Cap.Published, Cap.Received, Cap.Queue。注意表名可能在不同的数据库具有不同的大小写区分,如果你在运行项目的时候没有显式的指定数据库生成架构(SQL Server)或者表名前缀(MySql)的话,默认情况下就是以上3个名字。
  5. **Cap.Published**:这个表主要是用来存储 CAP 发送到MQ(Message Queue)的客户端消息,也就是说你使用 `ICapPublisher` 接口 Publish 的消息内容。
  6. **Cap.Received**:这个表主要是用来存储 CAP 接收到 MQ(Message Queue) 的客户端订阅的消息,也就是使用 `CapSubscribe[]` 订阅的那些消息。
  7. **Cap.Queue**: 这个表主要是CAP内部用来处理发送和接收消息的一个临时表,通常情况下,如果系统不出现问题,这个表将是空的。
  8. `Published` 和 `Received` 表具有 StatusName 字段,这个字段用来标识当前消息的状态。目前共有 Scheduled,Enqueued,Processing,Successed,Failed 等几个状态。CAP 在处理消息的过程中会依次从 Scheduled 到 Successed 来改变这些消息状态的值。如果是状态值为 Successed,代表该消息已经成功的发送到了 MQ 中。如果为 Failed 则代表消息发送失败,消息发送失败后 CAP 会对消息进行重试,直到成功。
  9. **关于数据清理**: CAP 默认情况下会每隔一个小时将消息表的数据进行清理删除,避免数据量过多导致性能的降低。清理规则为 ExpiresAt 不为空并且小于当前时间的数据。
  10. ### 5.2 消息格式
  11. CAP 采用 JSON 格式进行消息传输,以下是消息的对象模型:
  12. NAME | DESCRIPTION | TYPE
  13. :---|:---|:---
  14. Id | 消息编号 | int
  15. Name | 消息名称 | string
  16. Content | 内容 | string
  17. Group | 所属消费组 | string
  18. Added | 创建时间 | DateTime
  19. ExpiresAt | 过期时间 | DateTime
  20. Retries | 重试次数 | int
  21. StatusName | 状态 | string
  22. >对于 Cap.Received 中的消息,会多一个 `Group` 字段来标记所属的消费者组。
  23. ### 5.3 EventBus
  24. EventBus 采用 发布-订阅 风格进行组件之间的通讯,它不需要显式在组件中进行注册。
  25. ![](http://images2017.cnblogs.com/blog/250417/201708/250417-20170804153901240-1774287236.png)
  26. 上图是EventBus的一个Event的流程,关于 EventBus 的更多信息就不在这里介绍了...
  27. 在 CAP 中,为什么说 CAP 实现了 EventBus 中的全部特性,因为 EventBus 具有的两个大功能就是发布和订阅, 在 CAP 中 使用了另外一种优雅的方式来实现的,另外一个 CAP 提供的强大功能就是消息的持久化,以及在任何异常情况下消息的可靠性,这是EventBus不具有的功能。
  28. ![](https://camo.githubusercontent.com/452505edb71d41f2c1bd18907275b76291621e46/687474703a2f2f696d61676573323031352e636e626c6f67732e636f6d2f626c6f672f3235303431372f3230313730372f3235303431372d32303137303730353137353832373132382d313230333239313436392e706e67)
  29. CAP 里面发送一个消息可以看做是一个 “Event”,一个使用了CAP的ASP.NET Core 应用程序既可以进行发送也可以进行订阅接收。
  30. ### 5.4 重试
  31. 重试在实现分布式事务中具有重要作用,CAP 中会针对发送失败或者执行失败的消息进行重试。在整个 CAP 的设计过程中有以下几处采用的重试策略。
  32. **① 消息发送重试**
  33. 在消息发送过程中,当出现 Broker 宕机或者连接失败的情况亦或者出现异常的情况下,这个时候 CAP 会对发送的重试,重试策略为默认 **15** 次失败重试,当15次过后仍然失败时,CAP会将此消息状态标记为失败。
  34. **② 消息消费重试**
  35. 当 Consumer 接收到消息时,会执行消费者方法,在执行消费者方法出现异常时,会进行重试。这个重试策略和 ① 是相同的。
  36. **③ 失败消息重试**
  37. CAP 会定期针对 ① 和 ② 中状态为“失败的”消息进行重试,CAP会对他们进行重新“入队(Enqueue)”,入队时会将消息中的重试次数标记为0,状态置为 Enqueued。