Talk about the use of distributed business scenarios.

1. talk about the business scenario used in distributed.

First, why the need to connect systems using distributed.
With the development of the Internet, the performance bottleneck of traditional single project more and more prominent, performance bottlenecks may exist in the following aspects:

Application service layer: With the increase of users, the concurrent increase in the amount of the monomer project bear such a large performance bottleneck caused by concurrent requests.
The underlying database layer: As your business grows, pressure is also growing database performance bottleneck caused.

Scene 1: Session application clusters share.

The simplest application cluster is a cluster of servers, such as:. Tomcat cluster application cluster when the comparison is to highlight the problems shared Session, Session One is that we can to solve shared by server plug-in, the other can also Redis and other intermediaries Resolving a (generally use Redis middleware, server plug-in using the copy, then the Session real-time synchronization to each server, this can only support Session relatively small number of cases, the use of middleware storage Redis words, high performance, and stability better.).

Scenario 2: split service application system.

Services of Split, is the more fiery one way and now are talking about micro-services through traditional service project of the split, to separate decoupled service, single service but also the lateral expansion. Services of Split encounter . the classic problem is the distributed transaction issues present, the more commonly used distributed transaction there are several solutions: news eventual consistency, TCC compensatory affairs.

Scenario 3: sharing the underlying database pressure

If the performance of the system pressure appears in the database that we can use to read and write separation, sub-library sub-table and other programs to resolve.

2. Session distributed program

Here only two commonly used.

2.1 Cookie-based Session Sharing

After the session encryption serializing users to Cookie way to save under the root domain of the site when the user access to all second-level domain names, which are passed Cookie nostalgia root domain name information for all matches, achieved the user Cookie Session of multi-service sharing. this program can save a lot of server resources, the drawback is the length of the stored information will be subject to restrictions http protocol, but a site can only save about 20 Cookie, and every request will bring the session , so will cause some network bandwidth waste.

Redis 2.2 based shared storage of Session

These keys have a higher performance for non-relational database, you can easily hit 2000qps, built-in expiration mechanism just to meet time-sensitive features of the Session.

Used on a separate server or cache server cluster art using Redis Session data storage, the management of all the several Session, Redis can do high-availability cluster, all of the Web server reads the corresponding Session from the storage medium realize Session sharing.

Advantages: high reliability, can be extended laterally in the face of performance bottlenecks.
Disadvantages: slightly more complicated to achieve.
Applicable scene: Web servers are more high availability requirements of the state.
Available options: Open Source program Spring Session, you can also achieve their own.

3. distributed lock scenes and implementation.

scenes to be used

First, we look at a scenario under a single customer, we call centers reduce inventory stock, then our general operation is;

update store set num=${num} where id = ${id}

This way by setting inventory changes, we know that there is a higher return than the concurrent update the database of lost time, if A, B two things, check out the inventory are 5, a list it under the three inventory change 2, b down a list of inventory change 4, this time there has been a return to the update coverage b. the end result error occurs, the remaining inventory is 2.

This time we need to take CAS optimistic locking to solve this problem.
CAS no need to consider the ABA problem here, because even though this time the addition of inventory, intermediate changes, but will not affect the final result.

update store set num = ${num} where id = ${id} and num = ${query_num}

This update is only a table, if it involves more than one table, and we hope that all the tables at the same time this list can only be associated with a thread to handle updates, multiple threads in a different order to update a list associated with different data, the probability of deadlock is relatively large. If the project is distributed, then we need to ensure that multi-threaded multi-process at the same time only one thread to one of the treatment, this time we need to use distributed lock. there are many distributed lock implementations, we are through today, Zookeeper, Redis and implement the logic of Tair.

Zookeeper achieve

Acquire a lock

An existing lock root, lockRootNode, this can be a permanent root.
Client gets the lock, now create a sequence of instantaneous node lockRootNode below, ensure that the client is disconnected, the node is also automatically deleted.
Call lockRootNode parent node getChildren () method to get all of the root node, and from small to large, the smallest node if the current node is created, it returns true, acquire the lock success.
Talk about the use of distributed business scenarios.

Application service layer: With the increase of users, the concurrent increase in the amount of the monomer project bear such a large performance bottleneck caused by concurrent requests.
Underlying database layer: As your business grows, pressure is also growing database, cause performance bottlenecks.
scene 1: Session application clusters share.

Scenario 2: split service application system.

Scenario 3: sharing the underlying database pressure

If the performance of the system pressure appears in the database that we can use to read and write separation, sub-library sub-table and other programs to resolve.

Session distributed program

Here only two commonly used.

2.1 Cookie-based Session Sharing

Redis 2.2 based shared storage of Session

These keys have a higher performance for non-relational database, you can easily hit 2000qps, built-in expiration mechanism just to meet time-sensitive features of the Session.

Advantages: high reliability, can scale in the face of performance bottlenecks.
Disadvantages: slightly more complicated to achieve.
Applicable scene: Web servers are more high availability requirements of the state.
Available options: open source program Spring Session, can achieve their own .

Scenarios, and implementation of distributed locks.

scenes to be used

First, we look at a scenario under a single customer, we call centers reduce inventory stock, then our general operation is;

update store set num = $ {num } where id = $ {id}
this way by setting inventory changes, we know that there is a higher return than the concurrent update the database of lost time, if A, B two things query out of stocks are 5, a list it under the three stocks changed to 2, b down a list of inventory change 4, this time there has been a return to the update coverage b. the end result error occurs, the remaining stocks of 2 .

update store set num = $ {num } where id = $ {id} and num = $ {query_num}
This is the only update a table, if it involves more than one table, and we hope this list of all the tables associated with the same time can only be updated a thread to handle multiple threads in a different order to update a list of the different data associated with the time, the probability of deadlock is relatively large. If the project is distributed, then we need to ensure that multi-threaded multi-process only one thread to one of the treatment, this time we need to use distributed lock. there are many distributed lock implementations, we are through today, Zookeeper, Redis and implement the logic of Tair.

Zookeeper achieve

Acquire a lock

An existing lock root, lockRootNode, this can be a permanent root node.
Client gets the lock, now create lockRootNode following a sequence of instantaneous node, ensure that the client is disconnected, the node is also automatically deleted.
Call lockRootNode parent node getChildren () method to get all of the root node, and from small to large, the smallest node if the current node is created, it returns true, acquire the lock success.

Search for files