vault backup: 2024-10-11 17:44:32
This commit is contained in:
parent
1de8070de0
commit
cb14ce6660
6 changed files with 148 additions and 63 deletions
56
BUCA/Queues.md
Normal file
56
BUCA/Queues.md
Normal file
|
@ -0,0 +1,56 @@
|
|||
Challenges
|
||||
- Atomicity
|
||||
- you write to the queue first
|
||||
- you write to the db first
|
||||
- we need a transaction!
|
||||
- Idempotence
|
||||
- we need locking mechanism on the queue, to avoid multiple process to process the same element
|
||||
- solution: replay protection (lastUpdate in the db), but still I have the problem of multiple process reading the same element
|
||||
|
||||
## Data replication
|
||||
- Waiting for all replicas
|
||||
- definitely slower
|
||||
- safer for the data
|
||||
- Waiting only for the primary replica
|
||||
- faster but...
|
||||
- replica may fail
|
||||
- not getting always the same value
|
||||
- ok for maybe Instagram feed, but not for e-mails
|
||||
|
||||
## Paxos
|
||||
Paxos overview:
|
||||
- partecipnats are: Writers & Replicas
|
||||
- 2 phase protocol:
|
||||
- **prepare** reserves right to supply value, and robs other
|
||||
- **accepts** supplies the value **v**
|
||||
- replicas are stateful
|
||||
- communication is ordered by "proposal number" **n**
|
||||
- uses "viral propagation"
|
||||
|
||||
#### Algorithm
|
||||
- Prepare phase
|
||||
- Success if replica hasn't prepared a higher proposal
|
||||
- Fail otherwise
|
||||
- Success with value if we have accepted another value (viral property)
|
||||
|
||||
Majority succeded -> Go to Accept Phase
|
||||
|
||||
- Accept phase
|
||||
- Success only if replica hasn't Prepared a higher proposal (same is ok)
|
||||
|
||||
### Mesh
|
||||
- full mesh
|
||||
- subsetting: not every node connected to every other node: in case of a query of death, only connected nodes will fail
|
||||
- proxying: adding a layer of proxies (load balancers), that use a lookup service to route the request
|
||||
|
||||
### Strong stickiness
|
||||
Some applications like chat, online game servers, video calls ecc. need a very strong stickiness.
|
||||
In these cases, we may not want to use consistent hashing. Maybe we can use it to pick a server and then stick with it.
|
||||
|
||||
Also, it can happen that some users are not able to reach a specific server, but other does.
|
||||
Using leases might be a solution.
|
||||
|
||||
- Request from Alice
|
||||
- lookup server response is cached
|
||||
- we have a failure
|
||||
- we call Set to change the server, but the call stalls until the lease expires. Also, the lookup server might be able to still reach the server and renew the lease
|
Loading…
Add table
Add a link
Reference in a new issue