Distributed Systems
46 notes
Some notes are currently available only in Chinese. English translations are shown when available.
- 1.11 Distributed-System Communicationhistorical
1. What Is Distributed-System Communication - After a monolithic system is split into multiple subsystems, the subsystems need to communicate to provide a complete service. 2. Communication Methods Between Distributed Systems 2.1. Synchronous Communication - A calls B and waits for the result to return. 2.1.1. REST vs RPC.
- 1.12 Distributed-System Service Statehistorical
1. What Is State - State refers to a program's contextual information or data. - Stateful: a user's previous request and next request are associated, and the request must reach a particular node to be processed normally. - Stateless: a user's previous request and next request are associated, and the request can reach any node and still be processed normally. 2. Stateful Services vs Stateless Services.
- 1.13 Distributed-System Upgrade and Rollbackhistorical
1. What Are Service Upgrade and Rollback - A service in a distributed system has multiple instances. When a new feature is released or an old system is refactored, all of these instances need to be upgraded and replaced. If a problem occurs, rollback needs to happen promptly. 2. Deployment Strategies 2.1. Downtime Deployment - Stop the existing version of the service and then deploy the new version.
- 1.14 Distributed-System Failureshistorical
1. What Is a Distributed-System Failure - A node goes down or the network is unreachable. 2. How to Detect Distributed-System Failures 2.1. Heartbeat Detection 2.2. Gossip Protocol Detection. 3. How to Handle Distributed-System Failures 3.1. Fail-Over - A calls B. If B fails and B has other replicas, A switches to another replica of B.
- 1.15 Distributed-System Node Communicationhistorical
1. What Is Node Communication - Nodes in a distributed system need to communicate and exchange metadata. 1.1. What Is Metadata - The relationship between master and slave, data distribution, and so on. 1.2. Metadata Maintenance Methods - There are generally two ways to maintain metadata in a cluster: centralized and P2P.
- 2. Distributed Transactionshistorical
1. What Are Distributed Transactions - Transactions in a distributed environment. - Traditional transactions operate on a single database node, while distributed transactions span multiple database nodes, or even other data sources such as Redis and MongoDB. 2. Why Distributed Transactions Are Needed - Traditional database transactions can only guarantee transactions within a single database and cannot do so across multiple databases.
- 2.1 Distributed Transaction Solution: 2PChistorical
1. What Is 2PC - A distributed transaction solution that guarantees strong consistency. 2. 2PC Process - Divide the transaction into two phases. - Phase 1: the transaction manager sends prepare requests to all databases. - Phase 2 depends on the result of Phase 1.
- 2.2 Distributed Transaction Solution: TCChistorical
1. What Is TCC - A distributed transaction solution that guarantees eventual consistency. 2. TCC Process - TCC: Try, Confirm, Cancel. - Divide the transaction into two phases. - In Phase 1, execute Try to perform business checks and reserve resources. - Phase 2 depends on the result of Phase 1.
- 2.3 Distributed Transaction Solution: Reliable-Message Eventual Consistencyhistorical
1. What Is Reliable-Message Eventual Consistency - A distributed transaction solution that guarantees eventual consistency. 2. Reliable-Message Eventual-Consistency Process. 3. Use Cases - Suitable for businesses that require eventual consistency, have low time sensitivity, and where the distributed transaction can only succeed rather than fail, such as awarding points after registration or coupons after login.
- 2.4 Distributed Transaction Solution: Best-Effort Notificationhistorical
1. What Is Best-Effort Notification - A distributed transaction solution that guarantees eventual consistency. 2. Best-Effort Notification Process. 3. Use Cases - Suitable for businesses that require eventual consistency, have low time sensitivity, allow a small number of distributed transactions to fail, and where the passive side's processing result does not affect the active side's processing result, such as bank notifications and payment-result notifications.