The usage scenarios of CAP mainly include the following two:
The usage scenarios of CAP mainly include the following two:
<divclass="bs-callout bs-callout-primary">
**1. The scheme of eventual consistency in distributed transactions**
<h4>1. The scheme of eventual consistency in distributed transactions</h4><br>
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 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.
<br><br>
<br><br>
Distributed transactions are an inevitable requirement in a distributed system, and the current solution for distributed transactions is nothing more than just a few. Before understanding the CAP's distributed transaction scenarios, you can read the following [Articles](http://www.infoq.com/en/articles/solution-of-distributed-system-transaction-consistency).
Distributed transactions are an inevitable requirement in a distributed system, and the current solution for distributed transactions is nothing more than just a few. Before understanding the CAP's distributed transaction scenarios, you can read the following [Articles](http://www.infoq.com/en/articles/solution-of-distributed-system-transaction-consistency).
<br><br>
<br><br>
The CAP does not use the two-phase commit (2PC) transaction mechanism, but uses the classical message implementation of the local message table + MQ, which is also called asynchronous guarantee.
The CAP does not use the two-phase commit (2PC) transaction mechanism, but uses the classical message implementation of the local message table + MQ, which is also called asynchronous guarantee.
</div>
<divclass="bs-callout bs-callout-primary">
<h4>2. Highly usable EventBus</h4><br>
**2. Highly usable EventBus**
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 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.
<br><br>
<br><br>
CAP implements the publish and subscribe method of EventBus, which has all the features of EventBus. This means that you can use CAPs just like EventBus. In addition, CAP's EventBus is highly available. What does this mean?
CAP implements the publish and subscribe method of EventBus, which has all the features of EventBus. This means that you can use CAPs just like EventBus. In addition, CAP's EventBus is highly available. What does this mean?
<br><br>
<br><br>
The CAP uses the local message table to persist the messages in the EventBus. This ensures that the messages sent by the EventBus are reliable. When the message queue fails or fails, the messages are not lost.
The CAP uses the local message table to persist the messages in the EventBus. This ensures that the messages sent by the EventBus are reliable. When the message queue fails or fails, the messages are not lost.
</div>
## Quick Start
## Quick Start
...
@@ -191,4 +186,4 @@ public void ConfigureServices(IServiceCollection services)
...
@@ -191,4 +186,4 @@ public void ConfigureServices(IServiceCollection services)
