This article refers to network, assault and deletion

This series of articles will be organized into my GitHub repository for the Java Interview Guide. Check out my repository for more highlights

https://github.com/h2pl/Java-Tutorial

If you like, please click Star

The article was first posted on my personal blog:

www.how2playlife.com

This series of posts will tell you what is a distributed system, it is very important for the back-end engineer a business, we will gradually learn common distributed technology, and some of the more common distributed system concept, but also need to further understand the zookeeper, distributed transaction, distributed lock and load balancing technology, In order to give you a more complete understanding of the actual practice of distributed technology, ready for the real application of distributed technology.

If you have any suggestions or questions about this series of articles, you can also contact the author on the public account “Java Technology Jianghu”. You are welcome to participate in the creation and revision of this series of blog posts.

First, the raising of questions

1. What is Session?

Users need to use a browser to interact with the Web server multiple times to use the Web service. The HTTP protocol itself is stateless and needs to support the mechanism of Session State based on the HTTP protocol. The specific implementation is: at the beginning of the session, a unique SessionID (SessionID) is allocated, and this id is told to the browser through the Cookie. In the future, the browser will bring this SessionID to tell the Web server which session the request belongs to. On the Web server, each session has a separate store for information about different sessions. When cookies are disabled, it is common practice to put the session id in the URL’s parameters.

2. What is the Session consistency problem?

Session consistency issues occur when Web servers go from one to multiple.

As shown in the figure above, when an HTTP request with Session id arrives at the Web server, the corresponding Session data (Session) needs to be found during the processing of the HTTP request. The problem, however, is that if the first time I visit the site, the request lands on the left server, my Session is created on the left server, and if we don’t do that, there is no guarantee that subsequent requests will land on the same server every time. This is Session consistency.

Second, Session consistency solution

1. Session Stiky

In the case of a single machine, the session is stored on the single machine and the request is processed by that machine, so there is no problem. When multiple Web servers are deployed, ensuring that all requests for the same session are processed on the same Web server is the same for that session as it was for a single server.

To do this, you need the load balancer to be able to forward requests based on the SessionID SessionID of each request, as shown in the figure below. This approach is called Session Stiky approach.

The solution itself is very simple, and for a Web server it is the same as for a standalone server, except that we tinker with the load balancer. This scheme allows the same Session requests to be sent to the same Web server each time, which is very convenient for local caching of the server for the Session.

Its problems include:

• If a Web server goes down or restarts, session data on that machine is lost. If there is login status data in the session, the user needs to log in again.
• Session identifiers are information at the application layer, so if the load balancer wants to save all requests for the same session to the same Web server, it needs to parse the application layer (layer 7), which is more expensive than layer 4 switching.
• The load balancer becomes a stateful node that saves sessions to a map of a specific Web server, so memory consumption is greater and disaster recovery more troublesome.

For example, for Session Stiky, if the Web server is the restaurant where we eat every meal, Session data is the dish we eat with. To make sure I use my own utensils for every meal, IT’s a good idea to store my utensils at a certain restaurant and eat there every time.

2. Session Replication

If we continue with the restaurant analogy, in addition to the previous approach, I have more freedom to choose a restaurant if I store my own set of utensils at each restaurant. Session Replication is one such approach, as shown in the figure below.

As you can see, in the Session Replication scenario, the load balancer is no longer required to ensure that multiple requests for the same Session must go to the same Web server. We added session data synchronization between our Web servers. Synchronization ensures the consistency of Session data between different Web servers.

However, there are some issues with the Session Replication scenario, including:

• Synchronizing Session data incurs network bandwidth overhead. As long as the Session data changes, the data needs to be synchronized to all other machines. The more machines there are, the higher the network bandwidth cost of synchronization will be.
• Each Web server must store all Session data. If there are many sessions in the cluster, the content used to store Session data on each machine will be heavily occupied.

This is the Session Replication scheme. This solution relies on the application container to copy sessions so that the application can solve the Session problem, and the application itself does not care about this matter. However, this solution is not suitable for scenarios with a large number of clustered machines. If there are only a few machines, this scheme can be used.

3. Session Centralized data storage

Session Replication is one solution to the same request for the same Session being sent to different Web servers. Another solution is to store Session data centrally and then obtain sessions from different Web servers from the same place. Its general structure is shown in the figure below:

As you can see, part of the Session Replication scenario is that Session requests are not pinned to the same Web server after they pass through the load balancer. The difference is that there is no replication of Session data between Web servers, and Session data is not stored locally, but in another centralized storage location. In this way, no matter which Web server or Session data is modified, the final modification takes place in the centralized storage place, and the Web server uses the Session data from the centralized storage place. For the specific mode of Session data storage, you can use databases or other distributed storage systems. This solution solves the memory problem in the Session Replication solution, which is also better for network bandwidth than Session Replication.

However, there are still some problems with the scheme, including:

• Reading and writing Session data introduces network operations. Compared with reading and writing data on the local machine, the problem lies in delay and instability. However, since communication basically takes place on the Intranet, the problem is not big.
• If there is a problem with the machine or cluster that centrally stores sessions, this can affect our application.

The advantages of centralized storage over Session Replication are significant when the number of Web servers is large and the number of sessions is large.

4. Cookie Based

For the cookie-based scheme, different requests for the same session are not limited to the specific processing machine. Unlike Session Replication and centralized Session data management, this solution delivers Session data through cookies. The details are shown in the following figure.

As can be seen, our Session data is stored in cookies, and the corresponding Session data is generated from cookies on the Web server. It’s like I bring my own dishes with me every time, so I can choose which restaurant TO go to. Compared with the previous centralized storage, this solution does not depend on an external storage system, so there is no network delay and instability of retrieving and writing Session data from external systems.

However, the scheme still has shortcomings, including:

• Cookie length limit. Since cookies are limited in length, this also limits the length of Session data.
• Security. Session data is originally server-side data, but this scheme allows these server-side data to be sent to the external network and the client, so there are security problems.
• Bandwidth consumption. This is not the consumption of bandwidth between internal Web servers, but the overall consumption of external loans in our data center.
• Performance consumption. Each HTTP request and response carries Session data, and the Web server can support more concurrent requests with less output of the response in the same processing situation.

Third, summary

Generally speaking, all the above schemes are the solutions to solve the session problem. For large websites, session Sticky and centralized session management are better schemes.

One, foreword

When solving the problem of load balancing in distributed system, the Hash algorithm can be used to make a fixed part of the requests fall on the same server, so that each server can handle a fixed part of the requests (and maintain the information of these requests) to play the role of load balancing.

However, the normal remainder hash(such as user ID)% number of servers) algorithm scalability is poor, when the server machine is added or offline, the mapping between user ID and server will be largely invalid. Consistent hash is improved with hash rings.

2. Consistency Hash Overview

In order to intuitively understand the consistency hash principle, a simple example is used here. Assume that there are four servers with IP addresses of IP1, IP2, IP3, and IP4.

Consistent hash is the hash(ip1),hash(ip2),hash(ip3), and hash(ip3) corresponding to the four IP addresses. The calculated hash value is a direct value from 0 to the largest positive integer. The four values are displayed on the consistent hash ring as shown in the following figure:

Clockwise from the integer 0 to the largest positive integer, the hash value calculated from the four IP addresses must fall to some point on the hash ring. At this point, we map the four IP addresses of the server to the consistent hash ring. When the user makes a request on the client, The routing rule (hash value) is calculated based on the hash(user ID). Then, the route is routed to the nearest IP address clockwise based on the hash value on the hash ring.

As shown in the figure above, the requests of user1 and user2 will be processed by ip2, the requests of User3 will be processed by IP3, the requests of user4 will be processed by IP4, and the requests of user5 and user6 will be processed by IP1.

Now consider what happens when the IP2 server dies.

When the ip2 server hangs, the consistent hash ring looks like this:

According to the clockwise rule, the request of user1 and user2 will be processed by server IP3, while the processing server corresponding to the request of other users remains unchanged, that is, only the mapping relationship of some users previously processed by IP2 is broken, and the request processed by user2 is entrusted by the next node clockwise.

Now, what happens when you add machines?

When an IP5 server is added, the consistent hash ring is shown as follows:

According to the clockwise rule, the request of user1 should be processed by ip1 server, but now it is processed by ip5 server. The request processing server of other users remains unchanged, that is, some requests of the nearest server will be replaced by the new server.

3. Features of consistent Hash

Monotone means that if a number of requests are hashed to a certain server for processing and a new server is added to the system, the original requests must be mapped to the original or new server and not to another server. This can be proved by the addition of server IP5 above. After the addition of IP5, user6 that was previously processed by IP1 is now processed by IP1. User5 that was previously processed by IP1 is now processed by ip5. Spread: In distributed environment, the client may not know the existence of all servers when requesting, and may only know some of them. In the view of the client, some of the servers he sees will form a complete hash ring. If multiple clients use part of the server as a complete hash ring, requests from the same user may be routed to different servers for processing. This situation should obviously be avoided because it does not guarantee that requests from the same user will end up on the same server. Dispersion refers to the severity of these occurrences. Balance: Balance means load balancing. Clients should be able to distribute hash requests to different servers. Consistent hash allows each server to process requests, but there is no guarantee that each server will process roughly the same number of requests, as shown in the figure below

Server IP1, IP2, and IP3 hash to the consistent hash ring. According to the hash value distribution in the figure, IP1 is responsible for processing about 80% of the requests, while IP2 and IP3 are only responsible for processing about 20% of the requests. Although the three machines are processing requests, the load of each machine is obviously unbalanced. This is called a consistent hash tilt, and virtual nodes are designed to solve this problem.

5. Virtual nodes

When there are fewer server nodes, the problem of consistent hash tilt described in the previous section will occur. One solution is to add more machines, but it costs to add machines, so add virtual nodes, for example, the three machines above, and the consistent hash ring after each machine introduces one virtual node is shown as follows:

Ip1-1 is a virtual ip1 node, IP2-1 is a virtual IP2 node, and IP3-1 is a virtual IP3 node.

If the number of physical machines is M and the number of virtual nodes is N, the actual number of nodes in the Hash ring is M x (N+1). For example, if the hash value calculated by the client is between IP2 and IP3 or between IP2-1 and IP3-1, the IP3 server is used to process the hash value.

6. Uniformly consistent Hash

The graph we used in the previous section looks fairly balanced, but if the algorithm for generating virtual nodes is not good enough, it is possible to get the following ring:

After one virtual node is added to each service node, the balance is improved, but not balanced.

A balanced consistent hash would look like this:

The goal of uniform hash is that if there are N servers with M hash values for clients, then each server should handle approximately M/N users. That is, the load on each server is balanced as much as possible. The consistent hash load balancing algorithm provided by Dubbo is not uniform. We implemented dubbo’s SPI extension ourselves to implement uniform consistent hash.

Seven,

Consistent hash plays an important role in distributed system, which is used in both distributed cache and load balancing strategy of distributed Rpc framework.