Nie możesz wybrać więcej, niż 25 tematów Tematy muszą się zaczynać od litery lub cyfry, mogą zawierać myślniki ('-') i mogą mieć do 35 znaków.

configuration.md 4.7 KiB

1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192939495
  1. # 配置
  2. 默认情况下,你在向IoC容器中注册CAP服务的时候指定配置。
  3. ```c#
  4. services.AddCap(config=> {
  5. // config.XXX
  6. });
  7. ```
  8. 其中 `services` 代表的是 `IServiceCollection` 接口对象,它位于 `Microsoft.Extensions.DependencyInjection` 下面。
  9. 如果你不想使用微软的IoC容器,那么你可以查看 [ASP.NET Core 这里的文档](https://docs.microsoft.com/en-us/aspnet/core/fundamentals/dependency-injection?view=aspnetcore-2.2#default-service-container-replacement) 来了解如何替换默认的容器实现。
  10. ## 什么是最低配置?
  11. 最简单的回答就是,至少你要配置一个消息队列和一个事件存储,如果你想快速开始你可以使用下面的配置:
  12. ```C#
  13. services.AddCap(config =>
  14. {
  15. config.UseInMemoryQueue();
  16. config.UseInmemoryStorage();
  17. });
  18. ```
  19. 有关具体的消息队列的配置和存储的配置,你可以查看 Transports 章节和 Persistent 章节中具体组件提供的配置项。
  20. ## CAP 中的自定义配置
  21. 在 `AddCap` 中 `CapOptions` 对象是用来存储配置相关信息,默认情况下它们都具有一些默认值,有些时候你可能需要自定义。
  22. #### DefaultGroup
  23. 默认值:cap.queue.{程序集名称}
  24. 默认的消费者组的名字,在不同的 Transports 中对应不同的名字,可以通过自定义此值来自定义不同 Transports 中的名字,以便于查看。
  25. > 在 RabbitMQ 中映射到 [Queue Names](https://www.rabbitmq.com/queues.html#names)。
  26. > 在 Apache Kafka 中映射到 Topic Name。
  27. > 在 Azure Service Bus 中映射到 Subscription Name。
  28. #### Version
  29. 默认值:v1
  30. 这是在CAP v2.4 版本中引入的新配置项,用于给消息指定版本来隔离不同版本服务的消息,常用于A/B测试或者多服务版本的场景。以下是其应用场景:
  31. !!! info "业务快速迭代,需要向前兼容"
  32. 由于业务的快速迭代,在各个服务集成的过程中,消息的数据结构并不是固定不变的,有些时候我们为了适应新引入的需求,会添加或者修改一些数据结构。如果你是一套全新的系统这没有什么问题,但是如果你的系统已经部署到生产环境了并且正在服务客户,这就会导致新的功能在上线的时候和旧的数据结构发生不兼容,那么这些改变可能会导致出现严重的问题,要想解决这个问题,只能把消息队列和持久化的消息全部清空,然后才能启动应用程序,这对于生产环境来说显然是致命的。
  33. !!! info "多个版本的服务端"
  34. 有些时候,App的服务端需要提供多套接口,来支持不同版本的App,这些不同版本的App相同的接口和服务端交互的数据结构可能是不一样的,所以通常情况下服务端提供不用的路由地址来适配不同版本的App调用。
  35. !!! info "不同实例,使用相同的持久化表/集合"
  36. 希望多个不同实例的程序可以公用相同的数据库,在 2.4 之前的版本,我们可以通过指定不同的表名来隔离不同实例的数据库表,即在CAP配置的时候通过配置不同的表名前缀来实现。
  37. > 查看博客来了解更多关于 Version 的信息: https://www.cnblogs.com/savorboard/p/cap-2-4.html
  38. #### FailedRetryInterval
  39. 默认值:60 秒
  40. 在消息发送的时候,如果发送失败,CAP将会对消息进行重试,此配置项用来配置每次重试的间隔时间。
  41. 在消息消费的过程中,如果消费失败,CAP将会对消息进行重试消费,此配置项用来配置每次重试的间隔时间。
  42. !!! WARNING "重试 & 间隔"
  43. 在默认情况下,重试将在发送和消费消息失败的 **4分钟后** 开始,这是为了避免设置消息状态延迟导致可能出现的问题。
  44. 发送和消费消息的过程中失败会立即重试 3 次,在 3 次以后将进入重试轮询,此时 FailedRetryInterval 配置才会生效。
  45. #### FailedRetryCount
  46. 默认值:50
  47. 重试的最大次数。当达到此设置值时,将不会再继续重试,通过改变此参数来设置重试的最大次数。
  48. #### FailedThresholdCallback
  49. 默认值:NULL
  50. 类型:`Action<MessageType, string, string>`
  51. >
  52. T1 : Message Type
  53. T2 : Message Name
  54. T3 : Message Content
  55. 重试阈值的失败回调。当重试达到 FailedRetryCount 设置的值的时候,将调用此 Action 回调,你可以通过指定此回调来接收失败达到最大的通知,以做出人工介入。例如发送邮件或者短信。
  56. #### SucceedMessageExpiredAfter
  57. 默认值:24*3600 秒(1天后)
  58. 成功消息的过期时间(秒)。 当消息发送或者消费成功时候,在时间达到 `SucceedMessageExpiredAfter` 秒时候将会从 Persistent 中删除,你可以通过指定此值来设置过期的时间。