Bladeren bron

Updates english documentation (#606)

master
Marko Zorec 4 jaren geleden
committed by GitHub
bovenliggende
commit
13f4258760
Geen bekende sleutel gevonden voor deze handtekening in de database GPG sleutel-ID: 4AEE18F83AFDEB23
23 gewijzigde bestanden met toevoegingen van 89 en 89 verwijderingen
  1. +1
    -1
      README.md
  2. +3
    -3
      docs/content/index.md
  3. +16
    -16
      docs/content/user-guide/en/cap/configuration.md
  4. +7
    -7
      docs/content/user-guide/en/cap/idempotence.md
  5. +8
    -8
      docs/content/user-guide/en/cap/messaging.md
  6. +3
    -3
      docs/content/user-guide/en/cap/serialization.md
  7. +7
    -7
      docs/content/user-guide/en/cap/transactions.md
  8. +4
    -4
      docs/content/user-guide/en/getting-started/introduction.md
  9. +4
    -4
      docs/content/user-guide/en/monitoring/dashboard.md
  10. +1
    -1
      docs/content/user-guide/en/monitoring/diagnostics.md
  11. +5
    -5
      docs/content/user-guide/en/persistent/general.md
  12. +3
    -3
      docs/content/user-guide/en/persistent/in-memory-storage.md
  13. +2
    -2
      docs/content/user-guide/en/persistent/mongodb.md
  14. +2
    -2
      docs/content/user-guide/en/persistent/mysql.md
  15. +2
    -2
      docs/content/user-guide/en/persistent/postgresql.md
  16. +2
    -2
      docs/content/user-guide/en/persistent/sqlserver.md
  17. +1
    -1
      docs/content/user-guide/en/samples/faq.md
  18. +1
    -1
      docs/content/user-guide/en/samples/github.md
  19. +4
    -4
      docs/content/user-guide/en/transports/aws-sqs.md
  20. +3
    -3
      docs/content/user-guide/en/transports/azure-service-bus.md
  21. +2
    -2
      docs/content/user-guide/en/transports/in-memory-queue.md
  22. +5
    -5
      docs/content/user-guide/en/transports/kafka.md
  23. +3
    -3
      docs/content/user-guide/en/transports/rabbitmq.md

+ 1
- 1
README.md Bestand weergeven

@@ -151,7 +151,7 @@ public class PublishController : Controller

**In Business Logic Service**

If your subscription method is not in the Controller,then your subscribe class needs to implement `ICapSubscribe` interface:
If your subscription method is not in the Controller, then your subscribe class needs to implement `ICapSubscribe` interface:

```c#



+ 3
- 3
docs/content/index.md Bestand weergeven

@@ -10,13 +10,13 @@ Title: CAP - A distributed transaction solution in micro-service base on eventua
[![GitHub license](https://img.shields.io/badge/license-MIT-blue.svg)](https://raw.githubusercontent.com/dotnetcore/CAP/master/LICENSE.txt)
[![Member project of .NET Core Community](https://img.shields.io/badge/member%20project%20of-NCC-9e20c9.svg)](https://github.com/dotnetcore)

CAP is a library based on .net standard, which is a solution to deal with distributed transactions, also has the function of EventBus, it is lightweight, easy to use, and efficiently.
CAP is a library based on .net standard, which is a solution to deal with distributed transactions, also has the function of EventBus, it is lightweight, easy to use, and efficient.

## Introduction

In the process of building an SOA or MicroService system, we usually need to use the event to integrate each services. In the process, the simple use of message queue does not guarantee the reliability. CAP is adopted the local message table program integrated with the current database to solve the exception may occur in the process of the distributed system calling each other. It can ensure that the event messages are not lost in any case.
In the process of building an SOA or MicroService system, we usually need to use the event to integrate each service. In the process, the simple use of message queue does not guarantee the reliability. CAP adopts local message table program integrated with the current database to solve exceptions that may occur in the process of the distributed system calling each other. It can ensure that the event messages are not lost in any case.

You can also use the CAP as an EventBus. The CAP provides a simpler way to implement event publishing and subscriptions. You do not need to inherit or implement any interface during the process of subscription and sending.
You can also use CAP as an EventBus. CAP provides a simpler way to implement event publishing and subscriptions. You do not need to inherit or implement any interface during subscription and sending process.

!!! Tip "CAP implements the Outbox Pattern described in the [eShop ebook](https://docs.microsoft.com/en-us/dotnet/standard/microservices-architecture/multi-container-microservice-net-applications/subscribe-events#designing-atomicity-and-resiliency-when-publishing-to-the-event-bus)"
<img src="img/architecture-eshop.png">


+ 16
- 16
docs/content/user-guide/en/cap/configuration.md Bestand weergeven

@@ -1,6 +1,6 @@
# Configuration

By default, you can specify the configuration when you register the CAP service into the IoC container for ASP.NET Core project.
By default, you can specify configuration when you register CAP services into the IoC container for ASP.NET Core project.

```c#
services.AddCap(config=>
@@ -9,13 +9,13 @@ services.AddCap(config=>
});
```

The `services` is `IServiceCollection` interface,which is under the `Microsoft.Extensions.DependencyInjection`.
`services` is `IServiceCollection` interface, which can be found in the `Microsoft.Extensions.DependencyInjection` package.

If you don't want to use Microsoft's IoC container, you can view ASP.NET Core documentation [here](https://docs.microsoft.com/en-us/aspnet/core/fundamentals/dependency-injection?view=aspnetcore-2.2#default-service-container-replacement) to learn how to replace the default container implementation.
If you don't want to use Microsoft's IoC container, you can take a look at ASP.NET Core documentation [here](https://docs.microsoft.com/en-us/aspnet/core/fundamentals/dependency-injection?view=aspnetcore-2.2#default-service-container-replacement) to learn how to replace the default container implementation.

## What is the minimum configuration?
## what is minimum configuration required for CAP

The simplest answer is that at least you have to configure a transport and a storage. If you want to get started quickly you can use the following configuration:
you have to configure at least a transport and a storage. If you want to get started quickly you can use the following configuration:

```C#
services.AddCap(capOptions =>
@@ -25,47 +25,47 @@ services.AddCap(capOptions =>
});
```

For specific transport and storage configuration, you can view the configuration items provided by the specific components in the [Transports](../transports/general.md) section and the [Persistent](../persistent/general.md) section.
For specific transport and storage configuration, you can take a look at the configuration options provided by the specific components in the [Transports](../transports/general.md) section and the [Persistent](../persistent/general.md) section.

## Custom configuration

The `CapOptions` is used to store configuration information. By default they have the default values, and sometimes you may need to customize them.
The `CapOptions` is used to store configuration information. By default they have default values, sometimes you may need to customize them.

#### DefaultGroup

> Default: cap.queue.{assembly name}

The default consumer group name, corresponding to different names in different Transports, you can customize this value to customize the names in Transports for easy viewing.
The default consumer group name, corresponds to different names in different Transports, you can customize this value to customize the names in Transports for easy viewing.

!!! info "Mapping"
Map to [Queue Names](https://www.rabbitmq.com/queues.html#names) in RabbitMQ.
Map to [Consumer Group Id](http://kafka.apache.org/documentation/#group.id) in Apache Kafka.
Map to Subscription Name in Azure Service Bus.

#### Version
#### Versioning

> Default: v1

This is a new configuration item introduced in the CAP v2.4 version. It is used to specify a version of a message to isolate messages of different versions of the service. It is often used in A/B testing or multi-service version scenarios. The following is its application scenario:
This is a new configuration option introduced in the CAP v2.4 version. It is used to specify a version of a message to isolate messages of different versions of the service. It is often used in A/B testing or multi-service version scenarios. Following are application scenarios that needs versioning:

!!! info "Business Iterative and compatible"
Due to the rapid iteration of services, the data structure of the message is not fixed during each service integration process. Sometimes we add or modify certain data structures to accommodate the newly introduced requirements. If you're a brand new system, there's no problem, but if your system is deployed to a production environment and serves customers, this will cause new features to be incompatible with the old data structure when they go online, and then these changes can cause serious problems. To work around this issue, you can only clean up message queues and persistent messages before starting the application, which is obviously fatal for production environments.
Due to the rapid iteration of services, the data structure of the message is not fixed during each service integration process. Sometimes we add or modify certain data structures to accommodate the newly introduced requirements. If you have a brand new system, there's no problem, but if your system is already deployed to a production environment and serves customers, this will cause new features to be incompatible with the old data structure when they go online, and then these changes can cause serious problems. To work around this issue, you can only clean up message queues and persistent messages before starting the application, which is obviously fatal for production environments.

!!! info "Multiple versions of the server"
Sometimes, the server's server needs to provide multiple sets of interfaces to support different versions of the app. The data structures of the same interface and server interaction of these different versions of the app may be different, so usually the server does not provide the same. Routing addresses to adapt to different versions of App calls.
Sometimes, the server's server needs to provide multiple sets of interfaces to support different versions of the app. Data structures of the same interface and server interaction of these different versions of the app may be different, so usually server does not provide the same routing addresses to adapt to different versions of App calls.

!!! info "Using the same persistent table/collection in different instance"
If you want multiple different instance services to use the same database, in versions prior to 2.4, we could isolate database tables for different instances by specifying different table names. That is to say, when configuring the CAP, it is implemented by configuring different table name prefixes.

> Check out the blog to learn more about Version feature: https://www.cnblogs.com/savorboard/p/cap-2-4.html
> Check out the blog to learn more about the Versioning feature: https://www.cnblogs.com/savorboard/p/cap-2-4.html

#### FailedRetryInterval

> Default: 60 sec

In the process of message message sent to transport failed, the CAP will be retry to sent. This configuration item is used to configure the interval between each retry.
During the message sending process if message transport fails, CAP will try to send the message again. This configuration option is used to configure the interval between each retry.

In the process of message consumption failed, the CAP will retry to execute. This configuration item is used to configure the interval between each retry.
During the message sending process if consumption method fails, CAP will try to execute the method again. This configuration option is used to configure the interval between each retry.

!!! WARNING "Retry & Interval"
By default, retry will start after **4 minutes** of failure to send or consume, in order to avoid possible problems caused by setting message state delays.
@@ -94,7 +94,7 @@ T1 : Message Type
T2 : Message Name
T3 : Message Content

Failure threshold callback. This action is called when the retry reaches the value set by `FailedRetryCount`, and you can receive the notification by specifying this parameter to make a manual intervention. For example, send an email or notify.
Failure threshold callback. This action is called when the retry reaches the value set by `FailedRetryCount`, you can receive notification by specifying this parameter to make a manual intervention. For example, send an email or notify.

#### SucceedMessageExpiredAfter



+ 7
- 7
docs/content/user-guide/en/cap/idempotence.md Bestand weergeven

@@ -8,7 +8,7 @@ Imdempotence (which you may read a formal definition of on [Wikipedia](https://e

Before we talk about idempotency, let's talk about the delivery of messages on the consumer side.

Since CAP is not a used MS DTC or other type of 2PC distributed transaction mechanism, there is a problem that at least the message is strictly delivered once. Specifically, in a message-based system, there are three possibilities:
Since CAP doesn't uses MS DTC or other type of 2PC distributed transaction mechanism, there is a problem that the message is strictly delivered at least once. Specifically, in a message-based system, there are three possibilities:

* Exactly Once(*)
* At Most Once
@@ -35,9 +35,9 @@ This type of delivery guarantee can arise from your messaging system and your co
2. Put message back into the queue
```

In the sunshine scenario, this is all well and good – your messages will be received, and work transactions will be committed, and you will be happy.
In the best case scenario, this is all well and good – your messages will be received, and work transactions will be committed, and you will be happy.

However, the sun does not always shine, and stuff tends to fail – especially if you do enough stuff. Consider e.g. what would happen if anything fails after having performed step (1), and then – when you try to execute step (4)/(2) (i.e. put the message back into the queue) – the network was temporarily unavailable, or the message broker restarted, or the host machine decided to reboot because it had installed an update.
However, the sun does not always shine, and stuff tends to fail – especially if you do alot of stuff. Consider e.g. what would happen if anything fails after having performed step (1), and then – when you try to execute step (4)/(2) (i.e. put the message back into the queue) – the network was temporarily unavailable, or the message broker restarted, or the host machine decided to reboot because it had installed an update.

This can be OK if it's what you want, but most things in CAP revolve around the concept of DURABLE messages, i.e. messages whose contents is just as important as the data in your database.

@@ -72,7 +72,7 @@ The fact that the "work transaction" is just a conceptual thing is what makes it

## Idempotence at CAP

In the CAP, the delivery guarantees we use is **At Least Once**.
In CAP, **At Least Once** delivery guarantee is used.

Since we have a temporary storage medium (database table), we may be able to do At Most Once, but in order to strictly guarantee that the message will not be lost, we do not provide related functions or configurations.

@@ -83,9 +83,9 @@ Since we have a temporary storage medium (database table), we may be able to do
There are a lot of reasons why the Consumer method fails. I don't know if the specific scene is blindly retrying or not retrying is an incorrect choice.
For example, if the consumer is debiting service, if the execution of the debit is successful, but fails to write the debit log, the CAP will judge that the consumer failed to execute and try again. If the client does not guarantee idempotency, the framework will retry it, which will inevitably lead to serious consequences for multiple debits.

2. The implementation of the Consumer method succeeded, but received the same message.
2. The execution of the Consumer method succeeded, but received the same message.

The scenario is also possible here. If the Consumer has been successfully executed at the beginning, but for some reason, such as the Broker recovery, and received the same message, the CAP will consider this a new after receiving the Broker message. The message will be executed again by the Consumer. Because it is a new message, the CAP cannot be idempotent at this time.
This scenario is also possible. If the Consumer has been successfully executed at the beginning, but for some reason, such as the Broker recovery, same message has been received, CAP will consider this as a new message after receiving the Broker message. Message will be executed again by the Consumer. Because it is a new message, CAP cannot be idempotent at this time.

3. The current data storage mode can not be idempotent.

@@ -95,7 +95,7 @@ Since we have a temporary storage medium (database table), we may be able to do

Many event-driven frameworks require users to ensure idempotent operations, such as ENode, RocketMQ, etc...

From an implementation point of view, CAP can do some less stringent idempotence, but strict idempotent cannot.
From an implementation point of view, CAP can do some less stringent idempotence, but strict idempotent can not be guaranteed.

### Naturally idempotent message processing



+ 8
- 8
docs/content/user-guide/en/cap/messaging.md Bestand weergeven

@@ -4,25 +4,25 @@ The data sent by using the `ICapPublisher` interface is called `Message`.

## Scheduling

After the CAP receives the message, it sends the message to Transport, which is transported by transport.
After CAP receives a message, it sends the message to Transport, which is transported by transport.
When you send using the `ICapPublisher` interface, the CAP will dispatch the message to the corresponding Transport. Currently, bulk messaging is not supported.
When you send message using the `ICapPublisher` interface, CAP will dispatch message to the corresponding Transport. Currently, bulk messaging is not supported.

For more information on transports, see the [Transports](../transports/general.md) section.
For more information on transports, see [Transports](../transports/general.md) section.

## Persistent

The CAP will storage after receiving the message. For more information on storage, see the [Persistent](../persistent/general.md) section.
CAP will store the message after receiving it. For more information on storage, see the [Persistent](../persistent/general.md) section.

## Retry

Retrying plays an important role in the overall CAP architecture design, and CAPs retry for messages that fail to send or fail to execute. There are several retry strategies used throughout the CAP design process.
Retrying plays an important role in the overall CAP architecture design, CAP retry messages that fail to send or fail to execute. There are several retry strategies used throughout the CAP design process.

### Send retry

During the message sending process, when the broker crashes or the connection fails or an abnormality occurs, the CAP will retry the sending. Retry 3 times for the first time, retry every minute after 4 minutes, and +1 retries. When the total number of times reaches 50, the CAP will stop retrying.
During the message sending process, when the broker crashes or the connection fails or an abnormality occurs, the CAP will retry the sending. Retry 3 times for the first time, retry every minute after 4 minutes, and +1 retries. When the total number of times reaches 50,CAP will stop retrying.

You can adjust the total number of default retries by setting `FailedRetryCount` in CapOptions.
You can adjust the total number of retries by setting `FailedRetryCount` in CapOptions.

It will stop when the maximum number of times is reached. You can see the reason for the failure in Dashboard and choose whether to manually retry.

@@ -36,6 +36,6 @@ There is an `ExpiresAt` field in the database message table indicating the expir

Consuming failure will change the message status to `Failed` and `ExpiresAt` will be set to **15 days** later.

By default, the data of the message table is deleted **every hour** to avoid performance degradation caused by too much data. The cleanup strategy is `ExpiresAt` is not empty and is less than the current time.
By default, the data of the message in the table is deleted **every hour** to avoid performance degradation caused by too much data. The cleanup strategy `ExpiresAt` is performed when field is not empty and is less than the current time.

That is to say, the message with the status Failed (normally they have been retried 50 times), if you do not have manual intervention for 15 days, it will **also be** cleaned up.

+ 3
- 3
docs/content/user-guide/en/cap/serialization.md Bestand weergeven

@@ -1,6 +1,6 @@
# Serialization

We provide the `ISerializer` interface to support serialization of messages. By default, we use json to serialize messages and store them in the database.
We provide the `ISerializer` interface to support serialization of messages. By default, json is used to serialize messages and store them in the database.

## Custom Serialization

@@ -34,7 +34,7 @@ services.AddCap

In heterogeneous systems, sometimes you need to communicate with other systems, but other systems use message objects that may be different from CAP's [**Wrapper Object**](../persistent/general.md#_7). This time maybe you need to customize the message wapper.

The CAP provides the `IMessagePacker` interface for customizing the [**Wrapper Object**](../persistent/general.md#_7). The custom MessagePacker usually packs and unpacks the `CapMessage` In this process you can add your own business objects.
CAP provides the `IMessagePacker` interface for customizing the [**Wrapper Object**](../persistent/general.md#_7). Custom MessagePacker usually packs and unpacks the `CapMessage` In this process you can add your own business objects.

Usage :

@@ -76,7 +76,7 @@ class MyMessagePacker : IMessagePacker
}
```

Next, configure the custom `MyMessagePacker` to the service.
Next, add the custom `MyMessagePacker` to the service.

```csharp



+ 7
- 7
docs/content/user-guide/en/cap/transactions.md Bestand weergeven

@@ -27,9 +27,9 @@ For example, suppose we need to solve the following task:
* register a user profile
* do some automated background check that the user can actually access the system

The second task is to ensure, for example, that this user wasn’t banned from our servers for some reason.
Second task is to ensure, for example, that this user wasn’t banned from our servers for some reason.

But it could take time, and we’d like to extract it to a separate microservice. It wouldn’t be reasonable to keep the user waiting for so long just to know that she was registered successfully.
But it could take time, and we’d like to extract it to a separate microservice. It wouldn’t be reasonable to keep the user waiting for so long just to know that he was registered successfully.

**One way to solve it would be with a message-driven approach including compensation**. Let’s consider the following architecture:

@@ -37,13 +37,13 @@ But it could take time, and we’d like to extract it to a separate microservice
* the validation microservice tasked with doing a background check
* the messaging platform that supports persistent queues

The messaging platform could ensure that the messages sent by the microservices are persisted. Then they would be delivered at a later time if the receiver weren’t currently available
The messaging platform could ensure that the messages sent by the microservices are persisted. Then they would be delivered at a later time if the receiver wasn't currently available

#### Happy Scenario
#### Best case scenario

In this architecture, a happy scenario would be:
In this architecture, best case scenario would be:

* the user microservice registers a user, saving information about her in its local database
* the user microservice registers a user, saving information about him in its local database
* the user microservice marks this user with a flag. It could signify that this user hasn’t yet been validated and doesn’t have access to full system functionality
* a confirmation of registration is sent to the user with a warning that not all functionality of the system is accessible right away
* the user microservice sends a message to the validation microservice to do the background check of a user
@@ -51,7 +51,7 @@ In this architecture, a happy scenario would be:
* if the results are positive, the user microservice unblocks the user
* if the results are negative, the user microservice deletes the user account

After we’ve gone through all these steps, the system should be in a consistent state. However, for some period of time, the user entity appeared to be in an incomplete state.
After we’ve gone through all these steps, the system should be in a consistent state. However, for some period of time, user entity appeared to be in an incomplete state.

The last step, when the user microservice removes the invalid account, is a compensation phase.



+ 4
- 4
docs/content/user-guide/en/getting-started/introduction.md Bestand weergeven

@@ -2,16 +2,16 @@

CAP is an EventBus and a solution for solving distributed transaction problems in microservices or SOA systems. It helps create a microservices system that is scalable, reliable, and easy to change.

In Microsoft's [eShopOnContainer](https://github.com/dotnet-architecture/eShopOnContainers) microservices sample project, it is recommended to use CAP as the EventBus available in the production environment.
In Microsoft's [eShopOnContainer](https://github.com/dotnet-architecture/eShopOnContainers) microservices sample project, it is recommended to use CAP as the EventBus in the production environment.


!!! question "What is EventBus?"

An Eventbus is a mechanism that allows different components to communicate with each other without knowing about each other. A component can send an Event to the Eventbus without knowing who will pick it up or how many others will pick it up. Components can also listen to Events on an Eventbus, without knowing who sent the Events. That way, components can communicate without depending on each other. Also, it is very easy to substitute a component. As long as the new component understands the Events that are being sent and received, the other components will never know.
An Eventbus is a mechanism that allows different components to communicate with each other without knowing about each other. A component can send an Event to the Eventbus without knowing who will pick it up or how many others will pick it up. Components can also listen to Events on an Eventbus, without knowing who sent the Events. That way, components can communicate without depending on each other. Also, it is very easy to substitute a component. As long as the new component understands events that are being sent and received, other components will never know about the substitution.

Compared to other Service Bus or Event Bus, CAP has its own characteristics. It does not require users to implement or inherit any interface when sending messages or processing messages. It has very high flexibility. We have always believed that the appointment is greater than the configuration, so the CAP is very simple to use, very friendly to the novice, and lightweight.
Compared to other Services Bus or Event Bus, CAP has its own characteristics. It does not require users to implement or inherit any interface when sending messages or processing messages. It has very high flexibility. We have always believed that the appointment is greater than the configuration, so the CAP is very simple to use, very friendly to the novice, and lightweight.

The CAP is modular in design and highly scalable. You have many options to choose from, including message queues, storage, serialization, etc. Many elements of the system can be replaced with custom implementations.
CAP is modular in design and highly scalable. You have many options to choose from, including message queues, storage, serialization, etc. Many elements of the system can be replaced with custom implementations.

## Related videos



+ 4
- 4
docs/content/user-guide/en/monitoring/dashboard.md Bestand weergeven

@@ -1,6 +1,6 @@
# Dashboard

The CAP provides a Dashboard for viewing messages, and the features provided by Dashboard make it easy to view and manage messages.
CAP provides a Dashboard for viewing messages, and features provided by Dashboard make it easy to view and manage messages.

## Enable Dashboard

@@ -24,17 +24,17 @@ By default, you can open the Dashboard by visiting the url `http://localhost:xxx

> Default :'/cap'

You can change the path of the Dashboard by modifying this configuration item.
You can change the path of the Dashboard by modifying this configuration option.

* StatsPollingInterval

> Default: 2000ms

This configuration item is used to configure the Dashboard front end to get the polling time of the status interface (/stats).
This configuration option is used to configure the Dashboard front end to get the polling time of the status interface (/stats).

* Authorization

This configuration item is used to configure the authorization filter when accessing the Dashboard. The default filter allows LAN access. When your application wants to provide external network access, you can customize the authentication rules by setting this configuration. See the next section for details.
This configuration option is used to configure the authorization filter when accessing the Dashboard. The default filter allows LAN access. When your application wants to provide external network access, you can customize authentication rules by setting this configuration. See the next section for details.

### Custom authentication



+ 1
- 1
docs/content/user-guide/en/monitoring/diagnostics.md Bestand weergeven

@@ -1,6 +1,6 @@
# Diagnostics

Diagnostics provides a set of features that make it easy for us to document the critical operations that occur during the application's operation, their execution time, etc., allowing administrators to find the root cause of problems, especially in production environments.
Diagnostics provides a set of features that make it easy for us to document critical operations that occurs during the application's operation, their execution time, etc., allowing administrators to find the root cause of problems, especially in production environments.

## Diagnostics events



+ 5
- 5
docs/content/user-guide/en/persistent/general.md Bestand weergeven

@@ -1,18 +1,18 @@
# General

CAP need to use storage media with persistence capabilities to store event messages, such as through databases or other NoSql facilities. CAP uses this approach to deal with the loss of messages in all environments or network anomalies. The reliability of messages is the cornerstone of distributed transactions, so messages cannot be lost under any circumstances.
CAP needs to use storage media with persistence capabilities to store event messages, such as through databases or other NoSql facilities. CAP uses this approach to deal with loss of messages in all environments or network anomalies. Reliability of messages is the cornerstone of distributed transactions, so messages cannot be lost under any circumstances.

## Persistent

### Before sent

Before the message enters the message queue, the CAP uses the local database table to persist the message, which ensures that the message is not lost when the message queue is abnormal or a network error occurs.
Before message enters the message queue, CAP uses the local database table to persist the message, which ensures that the message is not lost when the message queue is abnormal or a network error occurs.

To ensure the reliability of this mechanism, CAP uses the same database transactions as the business code to ensure that business operations and CAP messages are consistent in the persistence process. That is to say, in the process of message persistence, the database will be rolled back when any one of the exceptions occurs.

### After sent

After the message enters the message queue, the CAP will start the persistence function of the message queue. We need to explain how the CAP message is persisted in RabbitMQ and Kafka.
After the message enters the message queue, CAP will start the persistence function of the message queue. We need to explain how CAP message is persisted in RabbitMQ and Kafka.

For message persistence in RabbitMQ, CAP uses a consumer queue with message persistence, but there may be exceptions here.

@@ -23,7 +23,7 @@ Since Kafka is born with message persistence using files, Kafka will ensure that

## Storage

After the CAP started, two tables are generated into the persistent, by default the name is `Cap.Published` and `Cap.Received`.
After CAP is started, two tables are generated into the persistent, by default the name is `Cap.Published` and `Cap.Received`.

### Storage Data Structure

@@ -56,7 +56,7 @@ StatusName | Status Name | string
### Wapper Object

When the CAP sends a message, it will store the original message object in a second package in the `Content` field.
When CAP sends a message, it will store original message object in a second package in the `Content` field.

The following is the **Wapper Object** data structure of Content field.



+ 3
- 3
docs/content/user-guide/en/persistent/in-memory-storage.md Bestand weergeven

@@ -4,7 +4,7 @@ Persistent storage of memory messages is often used in development and test envi

## Configuration

To use in-memory storage, you need to install the following extensions from NuGet:
To use in-memory storage, you need to install following package from NuGet:

```powershell
PM> Install-Package DotNetCore.CAP.InMemoryStorage
@@ -27,8 +27,8 @@ public void ConfigureServices(IServiceCollection services)

```

The successful message in memory, the CAP will be cleaned **every 5 minutes**.
CAP will clean **every 5 minutes** Successful messages in memory.

## Publish with transaction

In-Memory Storage **Not supported** Transaction mode to send messages.
In-Memory Storage **does not support** Transaction mode to send messages.

+ 2
- 2
docs/content/user-guide/en/persistent/mongodb.md Bestand weergeven

@@ -2,7 +2,7 @@

MongoDB is a cross-platform document-oriented database program. Classified as a NoSQL database program, MongoDB uses JSON-like documents with schema.

CAP has supported MongoDB as persistent since version 2.3 .
CAP supports MongoDB since version 2.3 .

MongoDB supports ACID transactions since version 4.0, so CAP only supports MongoDB above 4.0, and MongoDB needs to be deployed as a cluster, because MongoDB's ACID transaction requires a cluster to be used.

@@ -10,7 +10,7 @@ For a quick development of the MongoDB 4.0+ cluster for the development environm

## Configuration

To use MongoDB storage, you need to install the following extensions from NuGet:
To use MongoDB storage, you need to install the following package from NuGet:

```powershell
PM> Install-Package DotNetCore.CAP.MongoDB


+ 2
- 2
docs/content/user-guide/en/persistent/mysql.md Bestand weergeven

@@ -1,10 +1,10 @@
# MySQL

MySQL is an open-source relational database management system. CAP has supported MySQL as persistent.
MySQL is an open-source relational database management system. CAP supports MySQL database.

## Configuration

To use MySQL storage, you need to install the following extensions from NuGet:
To use MySQL storage, you need to install the following package from NuGet:
```powershell
PM> Install-Package DotNetCore.CAP.MySql


+ 2
- 2
docs/content/user-guide/en/persistent/postgresql.md Bestand weergeven

@@ -1,10 +1,10 @@
# Postgre SQL

PostgreSQL is an open-source relational database management system. CAP has supported PostgreSQL as persistent.
PostgreSQL is an open-source relational database management system. CAP supports PostgreSQL database.

## Configuration

To use PostgreSQL storage, you need to install the following extensions from NuGet:
To use PostgreSQL storage, you need to install the following package from NuGet:

```powershell
PM> Install-Package DotNetCore.CAP.PostgreSql


+ 2
- 2
docs/content/user-guide/en/persistent/sqlserver.md Bestand weergeven

@@ -1,13 +1,13 @@
# SQL Server

SQL Server is a relational database management system developed by Microsoft. CAP has supported SQL Server as persistent.
SQL Server is a relational database management system developed by Microsoft. CAP supports SQL Server database.

!!! warning "Warning"
We currently use `Microsoft.Data.SqlClient` as the database driver, which is the future of SQL Server drivers, and we have abandoned `System.Data.SqlClient`, we suggest you switch into.

## Configuration

To use SQL Server storage, you need to install the following extensions from NuGet:
To use SQL Server storage, you need to install the following package from NuGet:

```powershell
PM> Install-Package DotNetCore.CAP.SqlServer


+ 1
- 1
docs/content/user-guide/en/samples/faq.md Bestand weergeven

@@ -6,7 +6,7 @@

!!! faq "Does it require certain different databases, one each for productor and resumer in CAP?"

Not requird differences necessary, a given advice is that using a special database for each program.
Not required differences necessary, a given advice is that using a special database for each program.

Otherwise, look at Q&A below.



+ 1
- 1
docs/content/user-guide/en/samples/github.md Bestand weergeven

@@ -1,5 +1,5 @@
# Github Samples

You can find the sample code at Github repository :
You can find the sample code at the Github repository:

https://github.com/dotnetcore/CAP/tree/master/samples

+ 4
- 4
docs/content/user-guide/en/transports/aws-sqs.md Bestand weergeven

@@ -10,12 +10,12 @@ AWS SNS is a highly available, durable, secure, fully managed pub/sub messaging

Because CAP works based on the topic pattern, it needs to use AWS SNS, which simplifies the publish and subscribe architecture of messages.

When the CAP startup, all subscription names will be registered as SNS topics, and you will see a list of all registered topics in the management console.
When CAP startups, all subscription names will be registered as SNS topics, and you will see a list of all registered topics in the management console.

SNS does not support the use of symbols such as `.` `:` as the name of the topic, so we replaced it. We replaced `.` with `-` and `:` with `_`
SNS does not support use of symbols such as `.` `:` as the name of the topic, so we replaced it. We replaced `.` with `-` and `:` with `_`

!!! note "Precautions"
Amazon SNS currently allows the maximum size of published messages to be 256KB
Amazon SNS currently allows maximum size of published messages to be 256KB

For example, you have the following two subscriber methods in your current project

@@ -30,7 +30,7 @@ public void TestBar(DateTime value)
{
}
```
After the CAP startup, you will see in SNS management console:
After CAP startups, you will see in SNS management console:

![img](/img/aws-sns-demo.png)



+ 3
- 3
docs/content/user-guide/en/transports/azure-service-bus.md Bestand weergeven

@@ -2,14 +2,14 @@

Microsoft Azure Service Bus is a fully managed enterprise integration message broker. Service Bus is most commonly used to decouple applications and services from each other, and is a reliable and secure platform for asynchronous data and state transfer.

CAP supports Azure Service Bus as a message transporter.
Azure services can be used in CAP as a message transporter.

## Configuration

!!! warning "Requirement"
For the Service Bus pricing layer, CAP requires "standard" or "advanced" to support Topic functionality.

To use Azure Service Bus as a message transport, you need to install the following extensions from NuGet:
To use Azure Service Bus as a message transport, you need to install the following package from NuGet:

```powershell
PM> Install-Package DotNetCore.CAP.AzureServiceBus
@@ -36,7 +36,7 @@ public void ConfigureServices(IServiceCollection services)

#### AzureServiceBus Options

The AzureServiceBus configuration options provided directly by the CAP are as follows:
The AzureServiceBus configuration options provided directly by the CAP:

NAME | DESCRIPTION | TYPE | DEFAULT
:---|:---|---|:---


+ 2
- 2
docs/content/user-guide/en/transports/in-memory-queue.md Bestand weergeven

@@ -4,14 +4,14 @@ In Memory Queue is a memory-based message queue provided by [Community](https://

## Configuration

To use In Memory Queue as a message transporter, you need to install the following extensions from NuGet:
To use In Memory Queue as a message transporter, you need to install the following package from NuGet:

```powershell
PM> Install-Package Savorboard.CAP.InMemoryMessageQueue

```

Next, add configuration items to the `ConfigureServices` method of `Startup.cs`:
Next, add configuration options to the `ConfigureServices` method of `Startup.cs`:

```csharp



+ 5
- 5
docs/content/user-guide/en/transports/kafka.md Bestand weergeven

@@ -2,11 +2,11 @@

[Apache Kafka®](https://kafka.apache.org/) is an open-source stream-processing software platform developed by LinkedIn and donated to the Apache Software Foundation, written in Scala and Java.

CAP has supported Kafka® as message transporter.
Kafka® can be used in CAP as a message transporter.

## Configuration

To use Kafka transporter, you need to install the following extensions from NuGet:
To use Kafka transporter, you need to install the following package from NuGet:

```powershell
PM> Install-Package DotNetCore.CAP.Kafka
@@ -34,7 +34,7 @@ public void ConfigureServices(IServiceCollection services)

#### Kafka Options

The Kafka configuration parameters provided directly by the CAP are as follows:
The Kafka configuration parameters provided directly by the CAP:

NAME | DESCRIPTION | TYPE | DEFAULT
:---|:---|---|:---
@@ -43,7 +43,7 @@ ConnectionPoolSize | connection pool size | int | 10

#### Kafka MainConfig Options

If you need **more** native Kakfa related configuration items, you can set it with the `MainConfig` configuration option:
If you need **more** native Kakfa related configuration options, you can set them in the `MainConfig` configuration option:

```csharp
services.AddCap(capOptions =>
@@ -56,6 +56,6 @@ services.AddCap(capOptions =>
});
```

`MainConfig` is a configuration dictionary, you can find a list of supported configuration items through the following link.
`MainConfig` is a configuration dictionary, you can find a list of supported configuration options through the following link.

[https://github.com/edenhill/librdkafka/blob/master/CONFIGURATION.md](https://github.com/edenhill/librdkafka/blob/master/CONFIGURATION.md)

+ 3
- 3
docs/content/user-guide/en/transports/rabbitmq.md Bestand weergeven

@@ -2,11 +2,11 @@

RabbitMQ is an open-source message-broker software that originally implemented the Advanced Message Queuing Protocol and has since been extended with a plug-in architecture to support Streaming Text Oriented Messaging Protocol, Message Queuing Telemetry Transport, and other protocols.

CAP has supported RabbitMQ as message transporter.
RabbitMQ can be used in CAP as a message transporter.

## Configuration

To use RabbitMQ transporter, you need to install the following extensions from NuGet:
To use RabbitMQ transporter, you need to install the following package from NuGet:

```powershell
PM> Install-Package DotNetCore.CAP.RabbitMQ
@@ -35,7 +35,7 @@ public void ConfigureServices(IServiceCollection services)

#### RabbitMQ Options

The RabbitMQ configuration parameters provided directly by the CAP are as follows:
The RabbitMQ configuration parameters provided directly by CAP:

NAME | DESCRIPTION | TYPE | DEFAULT
:---|:---|---|:---


Laden…
Annuleren
Opslaan