BASE theory is proposed by Dan Pritchett in a paper published in ACM. It is a more practical theoretical guidance proposed on the basis of CAP theory, which is somewhat similar to PACELC theory.

BASE refers to Basically Available, Soft State, and Eventual Consistency.

For the current Internet applications, it is not a single machine system, but a multi-machine distributed system, so P in CAP is a necessary feature. The rest depends on the actual scenario. BASE is a guide to alternatives.

Suppose our microservice system structure is:

Assume that our system has the following business requirements:

  1. Query account balance (involving account micro-service)
  2. Product ordering (involving account micro-service, order micro-service, product micro-service)
  3. Surplus inventory of goods (involving goods micro-services)
  4. View user orders (involving order micro-service and commodity micro-service)

1. They are Basically Available.

Basic availability mainly includes three points:

  1. Currently, the system can handle the requests within the pressure range, and the requests beyond the range may be processed abnormally, but these requests should not affect the normal requests.
  2. Response time is normal. During stressful times, response time may increase, but not beyond a certain amount of time
  3. It can tolerate some loss of function. When some systems go wrong, other systems should ensure the normal operation of their business interfaces.

1.1. Requests within the pressure range that the system can withstand are normally processed

On Double 11, the number of users will suddenly increase, and this amount is hard to predict, especially the business pressure of ordering goods will increase a lot, which may exceed the limit of the system. When the system limit is exceeded, the entire system may become unusable (for example, exceeding the timeout limit causes many requests to queue up and subsequent requests to queue up and avalanche), which is not desirable.

Therefore, dynamic capacity expansion is generally considered and corresponding system microservices are expanded according to service pressure. In addition, due to the lag of dynamic expansion, it is necessary to add a current limiter to dynamically limit some sensitive service requests based on the number of microservices to prevent avalanches.

1.2. Response time is normal

When the user requests to place an order, it may be returned in milliseconds. When the system is under great pressure, the response time can be appropriately increased, such as 3s return. However, the response timeout time should not be set too long. Firstly, the user experience will be affected, and secondly, more requests will queue up.

It is better to set different response timeout times for different service interfaces. For example, the timeout time for querying account balance is shorter, and the timeout time for viewing user orders is longer.

You can set a system capacity expansion policy based on the average response time of system interfaces and the number of requests

1.3. Can tolerate certain functional loss

This mainly lies in the unbundling of microservices and service degradation strategies

For example, now the product micro-service hangs because of too much pressure, or restarts, at this time of business:

  1. Query account balance (involving account microservice), this is not affected due to microservice isolation
  2. To query the remaining inventory of goods (involving goods microservice), the system is down and the service needs to be degraded, such as returning goods inventory loading (front-end timing query), or goods inventory is 0.
  3. Product order, not available at present
  4. View the user’s order, the product information may not be displayed (service degradation), but the order list, as well as the order amount, transaction time information, etc., should be displayed, rather than the whole interface reported an exception.

2. Soft State

This refers to allowing intermediate states of data in a system that do not affect the overall availability of the system, i.e. allowing data delays in copies of data on multiple different nodes.

For example, the order can be initialized -> frozen amount -> withheld inventory -> deducted -> successful order these states, if the inventory failed to become unfrozen amount -> failed order state, corresponding to the order of several intermediate logic. Except for order success and order failure, the rest are soft states, not final states. Almost all soft states require a corresponding compensation task. With these intermediate states, the order logic can be retried with compensation through these intermediate states even if the system is restarted.

When querying an order, the order after the frozen amount state can be displayed to the user, and it can be displayed as processing until the order is placed successfully. After failing to deduct the inventory, it can be displayed as a refund.

3. Eventually Consistent

The soft state mentioned above will not remain in this soft state all the time, but will eventually go to the final state through the normal logic or compensation logic of the system, and each node will also synchronize this final state, which is the final consistency.

For this final consistency, Werner Vogels summarized five different scenarios to achieve the final consistency:

  • Causal consistency
  • Read-your-index consistency
  • Session consistency (Session level consistency)
  • Monotonic read consistency
  • Monotonic write consistency

In practice, these five designs are often used together to build a distributed system with ultimate consistency.

In vitro and in vitro results should be consistent.

Causality means that A change in process A notifies process B, while A change in process A does not notify process C without causal consistency. For processes that have a causal relationship, the data they access should be strongly consistent, and those that do not have this relationship will be ultimately consistent.

For example, a user’s request to see the inventory of an item is huge and can tolerate inconsistencies for a while. Assumptions in order to deal with such a big request, the inventory in micro service instances of local goods but also a cache, and will be received as order request will cache invalidation button to get the inventory after the latest inventory, at the same time, the cache will be expired after 5 s (real buckle inventory will not use this cache, this just display). Then the inventory on the microservice instance of goods with order request through the order microservice RPC is the latest inventory, while the inventory of other instances may be a little lag.

3.2. Read-your-index consistency

After updating A data item, process A always accesses the updated value and never sees the old value. This is a special case of the causal consistency model.

3.3. Session consistency (Session level consistency)

Changes made in the same session can be read immediately to the final changes. It may not be read immediately in other sessions.

For example, if a database synchronization request is written to the master database within this session, the master database session can read the change immediately. By default, the change can be read only after the synchronization is complete, according to the database double-1 synchronization configuration.

3.4. Monotonic read consistency

If a node reads a value of a data item from the system, the system should not return the value of the older version for any subsequent data access to the node.

3.5. Monotonic write consistency

The system must execute the write operations on the same node in sequence.

Wechat search “my programming meow” public account, a daily brush, easy to improve skills, won a variety of offers