vault backup: 2024-10-11 17:44:32

This commit is contained in:
Marco Realacci 2024-10-11 17:44:32 +02:00
parent 1de8070de0
commit cb14ce6660
6 changed files with 148 additions and 63 deletions

56
BUCA/Queues.md Normal file
View 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