当前位置:网站首页>Fast learning distributed system and conformance protocol

Fast learning distributed system and conformance protocol

2020-11-10 11:27:33 osc_cyo5y1ey

summary

《 Concept and design of distributed system 》 In a Book Definition of distributed system concept as follows : Distributed system is a hardware or software component distributed on different network computers , Systems that communicate and coordinate with each other solely through messaging

The design goal of distributed system generally includes the following aspects

  • Usability : Usability is the core requirement of distributed system , It is used to measure the ability of a distributed system to provide services continuously .
  • Extensibility : Adding machines does not or rarely changes system behavior , And it can get near linear performance improvement .
  • Fault tolerance : When a system error occurs , Ability to avoid and recover from errors .
  • performance : The response delay and throughput of external services should meet the needs of users .

Distributed architecture has more challenges than monolithic architecture

  • Network communication between nodes is unreliable , There are network delay and packet loss .
  • There is a node processing error , The node itself may be down at any time .
  • Synchronous calls make the system non extensible .

CAP principle

When it comes to distributed systems , I have to say CAP principle .

CAP The complete definition of is :

  • C:Consistency( Uniformity ). Consistency here refers to strong consistency , In layman's terms , That is, the data on all nodes is kept synchronized at all times . The strict expression of consistency is atomic reading and writing , That is, all reading and writing should look like “ atom ” Of , Or serial . All read and write requests seem to be sorted globally , After writing, you can read what you have written before .
  • A:Availability( Usability ). Any non fault node should respond to the request in a limited time , Whether the request is successful or not .
  • P:Tolerance to the partition of network( Zone tolerance ). When a network partition occurs ( That is, nodes cannot communicate with each other ), In the case of loss of any number of messages , The system still works .

CAP The principle is of great importance Guiding significance : In any distributed system , Usability 、 Consistency and partition tolerance are contradictory , You can't have all three , At most, you can only take two .


The intuitive explanation is as follows :

1)AP Satisfied but C dissatisfaction : If both high availability and fault tolerance are required , So it's time to give up consistency . Because once a network partition happens (P), There will be no communication between nodes , For high availability (A), Each node can only provide services with local data , This will lead to inconsistent data (!C). Some believe in BASE(Basic Availability, Soft state, Eventually Consistency) principled NoSQL database ( for example ,Cassandra、CouchDB etc. ) The requirements for consistency are often relaxed ( The final consistency can be satisfied ), In exchange for basic usability .

2)CP Satisfied but A dissatisfaction : If data is required to be strongly consistent across servers (C), But the network partition (P) Will cause unlimited synchronization time , In this way, usability is not guaranteed (!A). Stick to business ACID( Atomicity 、 Uniformity 、 Isolation and persistence ) And applications that are very sensitive to result consistency ( for example , Financial business ) This choice is usually made .

3)CA Satisfied but P dissatisfaction : If there is no network partition , So strong consistency and usability can be satisfied at the same time .

Just as the second law of thermodynamics reveals that any attempt to invent a perpetual motion machine is futile ,CAP The principle explicitly states that perfect satisfaction CAP There is no distributed system with three properties .

understand CAP The purpose of the principle is , It can help us better understand The trade-offs in the implementation of the actual distributed protocol .

Uniformity

Distributed storage systems are usually fault tolerant by maintaining multiple copies , To improve system availability . This leads to the core problem of distributed storage system —— How to ensure the consistency of multiple replicas ?

“ Uniformity ” There are three meanings :

  • Coherence This word is only in Cache Coherence In the scene , It focuses on multi-core shared memory CPU Under the architecture , Nuclear Cache How the data on should be consistent .

  • Consensus It's a consensus , It emphasizes that multiple proponents reach a consensus on something , It focuses on the process of reaching consensus , for example Paxos agreement 、Raft Election, etc. .Consensus Belong to replication protocol The category of .

  • Consistency The meaning of expression is relatively complicated , In a broad sense , It describes the influence of the maintenance degree of the invariants of the system itself on the upper business clients , And what kind of abnormal behavior will the concurrent state of the system expose to the client .CAP、ACID Medium C All have this meaning .

This paper focuses on the issue of consistency in distributed systems , It belongs to the one mentioned above Consensus and Consistency Category .

The consistency of distributed system is a basic problem that a distributed system with fault tolerance needs to solve . informally , Consistency is that different replica servers recognize the same data . Once these servers agree on a piece of data , Then the decision is the final decision , And the future cannot be overturned .

Here's one thing to note : Consistency has nothing to do with the correctness of the results , It's about whether the system is consistent with the external state ( Unified ). for example , It is also a manifestation of consistency that all nodes reach a wrong consensus .

Consistency protocol is used to solve the problem of consistency , It makes a group of machines work as a whole , Even if some of the machines are wrong, they can work properly . Because of that , Consistency protocols play a key role in large-scale distributed systems .

The agreement of conformity is from 20 century 80 The years began to study , Conformance protocols have spawned many algorithms . The criteria for measuring consistency algorithms are as follows :

  • Severability : A non failing process can make decisions in a limited amount of time , Equivalent to liveness.
  • Uniformity : All processes have to agree on the final decision , Equivalent to safety.
  • Legitimacy : The decision value made by the algorithm must be in other processes ( client ) Within the expected range of . That is, the client requests to answer “ yes ” or “ no ” when , Can't return “ Not sure ”.

Consistency model

Given some rules about operations and states , The operating history in the system should always follow these rules . We call these rules consistency models

The consistency model is described separately

For consistency , It can be understood from two different perspectives of client and server .

From the client side , Consistency mainly refers to the problem of how to obtain the updated data when multiple concurrent access .

From the server side , It's how updates replicate and distribute across the system , To ensure the final consistency of the data .

therefore , You can look at the consistency model from two perspectives : Data centric consistency model and user centric consistency model .

Data centric consistency model

The difficulty of implementing the following consistency models decreases in turn , The requirements for consistency strength also decrease in turn .

  1. Strict consistency (Strong Consistency)

    Strict consistency is also called strong consistency , Atomic consistency or linearization (Linearizability), It's the most demanding model of consistency . The requirements for strict consistency are as follows :

    • Any reading can read the latest written data of a certain data .
    • All processes in the system , See the sequence of operations , They are in the same order as the global clock .

    ** Strict consistency maintains an absolute global time sequence .** Stand alone systems follow strict consistency , But for distributed systems , It is impossible to assign an accurate global timestamp to each operation , So strict consistency is just a consistent model in theory .

  2. Sequential consistency (Sequential Consistency)

    Sequential consistency , Also known as serializable , It's a little weaker than strict consistency requirements , But it's also the highest level of consistency model that can be implemented .

    Strict consistency is difficult to achieve because of the global clock , Therefore, sequential consistency abandons the global clock constraint , Change it to Distributed logic clock implementation . Sequential consistency means that all processes see all changes in the same order . The read operation may not be able to get the previous write update of the same data by other processes , But each process reads the data in the same order .

    Storage systems that satisfy sequential consistency require an additional logical clock service .

    The following figure illustrates strict and sequential consistency

    a) Sequential consistency , From the perspective of these two processes , The order should be like this :Write(y, 2)→Read(x, 0)→Write(x, 4)→Read(y, 2), There is no conflict at all

    b) Strict consistency , The sequence of operations seen from the two processes is the same as that of the global clock , All are Write(y, 2)→Write(x, 4)→Read(x, 4)→Read(y, 2).

    c) Not satisfied with sequence consistency ,Write(x, 4)→Read(y, 0)→Write(y, 2)→Read(x, 0), There's a conflict here


3. Causal consistency (Causal Consistency)

Causality can be described as follows :

  • Local order : In this process , The order of event execution is the local causal order .
  • Remote order : If the read operation returns the value of the write operation , Then the write operation must precede the read operation in order .
  • Closure passing : As defined in the clock vector , If a→b And b→c, So there must be a→c.

Not strictly speaking , Causal consistency is weaker than sequential consistency .

The contrast between causal consistency and sequential consistency


Causality can be difficult to understand , Let's explain

P2 Write x=7,P2 Synchronize to P3,P3 Read 7

P1 Write x=2,P1 Synchronize to P3,P3 Read 2

P1 Write x=4,P1 Synchronize to P4,P4 Read 4

P2 Synchronize to P4,P4 Read 7

It will never appear first 4, Read again 2 The situation of

Causality only guarantees that the order of causation is correct , The other order is ignored

  1. Serializable consistency (Serializable Consis-tency)

    If the history of an operation is equivalent to the history of a single atomic sequence , But there is no description of the call and completion time , The serializability of the model is called the consistency .

    In a serializable system , There is a program like this :

    x = 1

    x = x + 1

    puts x

    ad locum , Let's assume that each row represents an operation , And all the operations were successful . Because these operations can be done in any order , So it's possible to print out nil、1 or 2. therefore , Consistency seems weak .

    But on the other hand , The consistency of serialization is very strong , Because it requires a linear order . for example , The following program :

    print x if x = 3

    x = 1 if x = nil

    x = 2 if x = 1

    x = 3 if x = 2

    It may not happen exactly in the order we write it , But it can reliably put x from nil→1→2, Change to 3, Last printed out 3.

User centric consistency model

  1. Final consistency (Eventual Consistency)

    Final consistency means that if the update interval is long , So all the replicas can eventually be consistent .

    It takes a while for the user to read the update of a certain operation to the specific data of the system , We call this time “ Inconsistency window ”.

    In the context of reading more and writing less , for example CDN, The ratio of reading to writing is very different , If the operator of the website modifies a picture , It took the end user some time to see the update, and it wasn't really a big problem .

Copy state machine

The basic idea of replication state machine is : A distributed replication state machine system consists of multiple replication units , Each replication unit is a state machine , Its state is stored in a set of state variables . The state of a state machine can and can only be changed by external commands .

As mentioned above “ A set of state variables ” It is usually based on the operation log . Each copy unit stores a log containing a series of instructions , And execute the instructions on the log one by one in strict order .

therefore , In the replicated state machine model , The main job of the consistency algorithm is how to Ensure the consistency of operation log .

The running process of replication state machine is shown in the figure below :


The consistency module on the server is responsible for receiving external commands , Then add it to your own operation log . It communicates with the consistency module on other servers to ensure that the operation logs on each server contain the same instructions in the same order . Once the instruction is copied correctly , Then the state machine of each server will process them in the order of the operation logs , The output is then returned to the client .

In distributed systems, fault tolerant machines are often used to solve various problems , for example ,GFS、HDFS、Chubby、ZooKeeper and etcd Distributed systems are all based on the replication state machine model .

It should be noted that , The order in which instructions are executed on a state machine is not necessarily the same as the order in which they are issued or received .

Copying state machines simply ensures that all state machines execute these commands in the same order .

General Byzantine question

Byzantium is located in what is now Istanbul, Turkey , It was the capital of the Eastern Roman Empire . Because of the vast size of the Byzantine Roman Empire at that time , For defensive reasons , Every army is very far apart , Generals and generals can only pass messages by messenger . When there's a war , All generals in the Byzantine army had to reach a consensus , Decide whether to attack the enemy . But there may be traitors and enemy spies in the army to disrupt the generals' decisions , So when we have a consensus exchange , The results may not really represent the opinion of the majority . At this time , In the case of known unreliable members , How can the remaining loyal generals rule out the influence of traitors or spies to reach a consensus decision , It's the famous Byzantine general problem .

The Byzantine general question is about a consensus issue . The Byzantine general problem is a model of the real world .

  • Byzantine error is a overly pessimistic Model ( The most pessimistic 、 The strongest error model )

    The significance of studying this model is that : If a consistency protocol can guarantee that the system will appear N A Byzantine mistake , Consistency decisions can still be made , Then this protocol can handle the emergence of the system N Any other type of error .

  • Process failure error (fail-stop Failure, It's like downtime ) It is a overly optimistic Model ( The most optimistic 、 The weakest error model )

    The significance of studying this model is that : If a consistency protocol appears in the system N There is no guarantee to make a consistent decision in the event of process failure errors , Then this protocol will not be able to handle the emergence of the system N Any other type of error .

Fred Schneider The paper mentioned earlier 《Implementing fault-tolerant services using thestate machine approach》 It points out such a basic hypothesis :

One RSM( Distributed state machines ) The system should tolerate N A Byzantine mistake , Need at least 2N+1 Replication nodes .

If you just reduce the type of error to process failure , At least N+1 Only replication nodes can be fault tolerant .

But it's not just about meeting the above mentioned 2N+1 One request can guarantee that everything is safe ? Unfortunately , The answer is No .

FLP Impossible

FLP Impossibility is a very famous theorem in the field of distribution :

No completely asynchronous consensusprotocol can tolerate even a single unan-nounced process death.

stay Asynchronous communication scenario Next , No consistent agreement can guarantee , Even if only one process fails , Other non failing processes cannot agree either .

The process here failed (unannounced process death) It refers to the failure of a process , But other nodes don't know , Continue to think that the process has not finished processing or message delay has occurred .

for instance :

nail 、 B 、 Three people vote separately ( The vote was 0 or 1). They can communicate with each other over the phone , But some people fall asleep . for example : A vote 0, B voted 1, At this time, a and B draw , C's vote is the key . But C fell asleep , Neither a nor B will be able to reach the final result until he wakes up . Even if we vote again , It's also possible to fall into endless cycles .

FLP The theorem actually shows that in the scenario where node failures are allowed , Distributed protocol based on asynchronous communication , There is no guarantee that agreement can be reached within a limited time . use CAP In terms of theoretical explanation , stay P Under the condition of , Unable to meet C and A.

Please note that , The premise of this conclusion is asynchronous communication . In distributed systems ,“ asynchronous communication ” And “ Synchronous communication ” The biggest difference is that there is no clock 、 Can't time sync 、 Cannot use timeout 、 Failure cannot be detected 、 Messages can be delayed arbitrarily 、 News can be out of order .

therefore , The actual consistency protocol (Paxos、Raft etc. ) It's theoretically flawed , The biggest problem is that there is no termination in theory ! But they all made some adjustments , It reduces the probability .

Paxos agreement

A great god Leslie Lamport A thorough study of issues like Byzantine Generals , And published several papers .

To sum up, I will answer the following three questions :

1) Is there a solution to the distributed consistency problem like Byzantine Generals ?

2) If there is a solution, what conditions need to be satisfied ?

3) Based on certain preconditions , A solution is proposed .

Leslie Lamport In the paper “ General Byzantine question ” The answer to the first two questions has been given in , And the third problem is in his paper “The Part-Time Parliament” A kind of Consistency algorithm based on message passing .

The following is the daily operation of the great God :

1990 year ,Lamport towards ACM Transac-tions on Computer Systems Submitted his article about Paxos Algorithm paper . The chief editor wrote back and suggested that he describe his algorithm in mathematics rather than myth , Otherwise, they won't consider accepting the paper .Lamport Think those people are too pedantic , Refuse to make any changes , Instead, I posted my paper on my personal blog .

At first Paxos Because the algorithm is difficult to understand, it has not attracted many people's attention , until 2006 year Google The three major papers have appeared “ cloud ” End , among Chubby Lock The service uses Paxos As Chubby Cell The consistency algorithm , This makes Paxos The popularity of algorithms has soared ever since , Almost monopolized the field of consistent algorithms . stay Raft Before the birth of algorithms ,Paxos It's almost synonymous with conformance protocols .

Lamport I think Paxos It's simple , But in fact, for most people ,Paxos It's still too hard to understand .

quote NSDI A word in the community is : The world really understands Paxos The only people who do algorithms are 5 individual !

This may be the difference between man and God .

then , A more understandable consistency algorithm Raft The birth of .

Raft agreement : Born for comprehensibility

Finally, it comes to Raft 了 , It's not easy for me .

Raft The algorithm mainly uses two methods to improve the comprehensibility . There are two common ways to improve understanding

  1. Problem decomposition

    As much as possible, decompose the problem into several solvable 、 A little easier to understand —— This is a well-known methodology for simplifying problems . for example ,Raft The algorithm decomposes the problem into leader election (leader election)、 Log copy (log repli-cation)、 Security (safety) And changes in membership (membershipchanges) These sub problems .

    • Leader election : After a leader node fails, a new leader node must be given .
    • Log copy : The leader node receives the operation request from the client , Then copy the operation log to other servers in the cluster , And it is mandatory that the logs of other servers must be consistent with their own .
    • Security :Raft The key security feature is the state machine security principle mentioned below (State Machine Safety)—— If a server has applied a log entry at a given index location to the state machine , Then all other servers will not apply different entries at the index location . The following will prove that Raft How to guarantee this principle .
    • Membership changes : When the configuration changes , The cluster can continue to work .
  2. Reduce state space

    Raft The algorithm simplifies the state space by reducing the number of States to be considered . This will make the whole system more consistent and eliminate uncertainty as much as possible .

Raft There are several important innovations

  • Strong leaders .Raft Use a stronger form of leadership than other algorithms . for example , Log entries are only sent from the leader to other servers . This simplifies the management of log replication , Improved Raft The comprehensibility of .
  • Leader election .Raft Use random timers to elect leaders . This approach only adds a little change to the heartbeat mechanism that all algorithms need to implement , It makes conflict resolution easier and faster .
  • Membership changes .Raft New consistency is used when adjusting cluster membership (joint consensus, United consensus ) Method . Using this method , When the cluster configuration changes , The cluster still works .

Raft Consistency algorithm

Basic concepts

  1. Leader( Leader )

  2. Candidate( The candidate )

  3. Follower( The crowd )

  4. term (Term):Raft The algorithm divides the time into any length of tenure , Tenure is monotonically increasing , With consecutive numbers (1, 2, 3……) Express . stay Raft In the world of , Every term begins with an election of leaders . If a candidate wins an election , Then it will be the leader for the rest of the term . In some cases , The vote will be divided , As a result, no candidate can get more than half of the votes , So this term will end with no elected leader . that , The next term will automatically enter the system , Start a new election .Raft The algorithm guarantees that there is at most one leader in a given term of office . some Term Because of the election failure , There are no leaders , Such as t3 Shown .


The term of office is Raft It plays the role of a logical clock , It can also be used in Raft The node detects expired information —— For example, expired leaders . Every Raft Each node maintains a current tenure value locally , Trigger this number change ( increase ) There are two main scenarios : Start voting and exchange information with other nodes . If a node ( Including leaders ) The current tenure number of the node is smaller than that of other nodes , Then the local term number will be automatically updated to a larger one . If a candidate or leader realizes that its tenure number is out of date ( Smaller than others ), Then it will immediately switch back to mass state ; If a node receives a request with an outdated tenure number , Then the node will refuse to respond to this request .

Leader election

Raft By electing a supreme leader , And to maintain the consistency of replication logs between nodes by giving them the responsibility of managing replication logs .

Leaders receive log entries from clients , Then copy the log entries to other servers , And on the premise of ensuring safety , Tell other servers to apply log entries to their state machines . Leaders can decide where new log entries need to be placed in the log file , You don't have to negotiate with other servers , And the data flows one-way from the leader to the other servers .

The process of leadership election , Namely Raft Three kinds of role switching process

At the beginning , The system has a Leader And many Follower

  1. every last Raft node ( contain Follower) There's an election timer inside , If you receive Leader The heartbeat bag of broadcast , be Follower Reset the election timer .
  2. If Follower It's time for the election timer , No heartbeat packets were received during this period ,Follower Think Leader, You can be Leader 了 , And we started the election , The main steps are as follows
    • The current term of office of the local number will be maintained (current_term_id) Add 1
    • Switch your status to the candidate (Candidate), And vote for yourself
    • Send... To other nodes in its cluster RequestVote RPC(RPC The message will carry “current_term_id” value ), Ask them to vote for themselves
    • Set the election timeout , Generally, the values in an interval are randomly selected
  3. stay Candidate State,
    • If you get a majority of the votes , Then become Leader
    • If it turns out that a new leader has been created or has a longer term , Then the status changes to Follower
    • If the election timeout passes , The candidate's term of office has been increased (Term++) And launch a new round of canvassing activities
  4. stay Leader State, , If a higher tenure is found , Change yourself to Follower

Log copy

Once a leader wins the election , The client will start receiving the request . The leader will add this instruction to its log file as a new log entry , And then in parallel to the other Raft Nodes initiate AppendEntriesRPC, Ask other nodes to copy this log entry . When this log entry is “ Security ” After copying ,Leader Will apply this log (apply, That is to execute the instruction ) Into its state machine , And return the result to the client . If Follower An error occurred , It runs slowly and doesn't respond in time AppendEntries RPC, Or there is a network packet loss problem , Then leaders will try again indefinitely AppendEntries RPC( Even after it responds to the client ), Until all the followers finally store and Leader The same log entry .

A log consists of sequentially numbered log entries . Each log entry generally contains three attributes : Integer index (log index)、 Office no. (term) And instructions (command). It is generally shown as follows :


Once the entry created by the leader has been copied to more than half of the nodes , Then this entry is called committable .

Raft The main process of log replication is as follows :

  1. Client to Leader Send write request .
  2. Leader Parse the write request into an operation instruction and append it to the local log file .
  3. Leader For each Follower radio broadcast AppendEntries RPC.
  4. Follower By consistency checking , Choose where to start appending Leader Log entries for .
  5. Once the log entry is submitted successfully ,Leader Apply the instruction corresponding to the log entry (apply) To the local state machine , And return the operation result to the client .
  6. Leader Subsequently passed AppendEntries RPC Will have succeeded ( On most nodes ) Notification of submitted log entries Follower.
  7. Follower After receiving the submitted log entry , Apply it to the local state machine .

As can be seen from the above steps , in the light of Raft Log entries have two operations , Submit (commit) And applications (apply), The application must occur after submission , That is, a log entry can only be applied to the local state machine after it is submitted .

The flow chart is as follows :https://www.processon.com/view/link/5fa6c1045653bb25634dea4a

Security

This paper introduces how to add a restriction rule to the leader election section to ensure that —— Any leader has all the log entries submitted by his previous tenure .

  1. How to qualify as a leader ?- All committed log entries must be included

    RequestVote RPC The receiver of has a check : If Follower My own journal is more than RPC The caller ( The candidate ) The log is more up-to-date , You're going to turn down the candidate's request to vote .

    This is Raft The algorithm uses voting to prevent nodes that do not contain all submitted log entries from winning the election .

  2. How to judge whether the log has been submitted ?

    Before submitting term The log entry of , It must be ensured that at present term The new log entry has been copied to more than half of the nodes . such , Before term Only a log entry of is actually committed .

Usability and timing

broadcastTime << electionTimeout << MTBF

broadcastTime It refers to a node sending to other nodes in the cluster RPC, And the average time to receive their response .

electionTimeout It's election overtime .

MTBF It refers to the average time interval between failures of a single node .

In order to enable leaders to continuously send heartbeat packets to prevent the following Follower Launch an election ,broadcastTime Should compare electionTimeout One order of magnitude smaller .

Abnormal situation

#### followers / The candidate is abnormal

Raft The algorithm deals with these failures through endless retrying by leaders , Until the failed node restarts and handles these RPC until .

because Raft In the algorithm RPC They are idempotent , So there's no problem .

The leader is abnormal


Raft The data exchange process is shown in the figure above , At any moment , Leaders can collapse .

  1. The data is arriving Leader Before


Does not affect consistency

  1. Data arrives Leader node , But not copied to Follower node


Does not affect consistency

If at this stage Leader Something goes wrong , At this time, the data belongs to uncommitted state , that Client Will not receive ACK, Instead, they think that a timeout failure can safely initiate a retry .Follower There is no such data on the node , After reselection Client Retry resubmission succeeded . The original Leader The node will be restored as Follower To join the cluster , From the current term of office of the new Leader Sync data at , And Leader Data is forced to be consistent .

  1. Data arrives Leader node , Successfully copied to Follower On some nodes of the , But not to Leader Response reception


Data is not lost , It doesn't affect consistency

If at this stage Leader Something goes wrong , Now the data is in Follower Node is in uncommitted state (Uncommitted) And inconsistent , that Raft The protocol requires that votes be cast only for nodes with the latest data . So the node with the latest data will be selected as Leader, Then force data synchronization to Follower, Data will not be lost and ultimately consistent .

  1. Data arrives Leader node , Successfully copied to Follower On all nodes of , But not to Leader Response reception


Data is not lost , It doesn't affect consistency

If at this stage Leader Something goes wrong , Although the data is in Fol-lower Node is in uncommitted state (Uncommitted), But it can also be consistent , So re elect Leader After that, the data submission can be completed , At this time, the client does not know whether it has submitted successfully , So you can try submitting again . In this case ,Raft requirement RPC Request implementation idempotence , That is to realize the internal de duplication mechanism .

  1. Data arrives Leader node , Successfully copied to Follower On all or most nodes of , The data is in Leader Is in the submitted state on , But in Follower Is uncommitted on


Data is not lost , It doesn't affect consistency

  1. Data arrives Leader node , Successfully copied to Follower On all or most nodes of , The data is in the submitted state at all nodes , But not yet Client


Data is not lost , It doesn't affect consistency

  1. Brain crack caused by network partition , There is a double Leader


Does not affect consistency

The network partition will be the original Leader Nodes and Follower The nodes are separated ,Follower Don't get Leader The heart of the heart will launch an election to produce a new Leader. At this time, there is a double Leader, The original Leader Alone in a district , Submitting data to it is impossible to replicate to most nodes , So it's always unsuccessful to submit . To the new Leader Submit data can be submitted successfully , After the network recovers, the old Leader It is found that there are renewal terms in the cluster (Term) The new Leader, Automatically downgrade to Fol-lower And from the new Leader Synchronize data to achieve cluster data agreement .

summary

There is a big difference between distributed system and general business system , Involving more papers 、 Mathematical knowledge , More academic . With the continuous development of computers , Knowledge about distribution , Still need to master .

About Raft Algorithm , Suggest to have a look at the source code https://github.com/etcd-io/etcd/tree/master/raft.

Raft Through the leadership election mechanism , Simplify the overall complexity . Copy with logs + Copy state machine , Ensure the consistency of state execution . At the same time, some corresponding security rules are set , Enhanced the security of log replication , Consistency is maintained .

If you have limited time , You can just look at CAP、 Copy the state machine and Raft.

Information

  1. https://www.infoq.cn/article/wechat-serial-number-generator-architecture/ Wechat serial number generator architecture design and evolution

  2. From the comment visibility of wechat circle of friends , On the application of causal consistency in distributed system

  3. https://www.jianshu.com/p/ab511132a34f raft Series interpretation (3) And Code implementation

  4. https://blog.csdn.net/lanyang123456/article/details/109279234 raft Log security in the protocol

  5. http://www.duokan.com/book/180790 Cloud native distributed storage cornerstone :etcd In depth analysis of

Last

If you like my article , You can pay attention to my official account. ( Hot programmer )

My personal blog is :https://shidawuhen.github.io/

Review of previous articles :

technology

  1. The service framework and registry of microservices
  2. Beego Frame usage
  3. On micro service
  4. TCP performance optimization
  5. Current limiting implementation 1
  6. Redis Implement distributed locks
  7. Golang Source code BUG trace
  8. Transaction atomicity 、 Uniformity 、 The implementation principle of persistence
  9. CDN The request process is explained in detail
  10. Remember the process of blog service being crushed
  11. Common caching techniques
  12. How to effectively connect with third party payment
  13. Gin Simple version of the framework
  14. InnoDB Lock and transaction analysis
  15. Algorithm is summarized
  16. Distributed systems and conformance protocols

Reading notes

  1. The agile revolution
  2. How to exercise your memory
  3. Simple logic - Journal entry
  4. Hot air - Journal entry
  5. The analects of Confucius - Journal entry
  6. Sun Tzu's art of war - Journal entry

reflection

  1. Some views on Project Management
  2. Some thoughts on product managers
  3. Thinking about the professional development of programmers
  4. About the code review Thinking
  5. Markdown Editor recommendations -typora

版权声明
本文为[osc_cyo5y1ey]所创,转载请带上原文链接,感谢