lec08
dz / distributed_systems_MIT / lec08Summary
Lecture 8, more linearizability, zookeeper
Node Tree
Nodes
| linearizability | |
| content | linearizability |
| children | correctness, history_linearizable, proof_of_order, strongly_consistent_system (important for), writes_linearizable |
| strongly_consistent_system | |
| content | strongly consistent system |
| children | no_stale_data (a strongly consistent system can't serve stale data) |
| parents | linearizability |
| history_linearizable | |
| content | is the history linearizable |
| children | no_cycles |
| parents | linearizability |
| proof_of_order | |
| content | client must observe proof of only one order |
| parents | linearizability |
| no_cycles | |
| content | no cycles |
| parents | history_linearizable |
| correctness | |
| content | correctness |
| children | correct_tolerant, no_stale_data, not_good_correctness, writes_linearizable |
| parents | linearizability |
| no_stale_data | |
| content | can't serve stale data |
| parents | correctness, strongly_consistent_system |
| correct_tolerant | |
| content | correct applications must be tolerant of these systems |
| parents | correctness |
| zookeeper | |
| content | zookeeper |
| children | consistency_guarantees, raft_like, why_zookeeper |
| why_zookeeper | |
| content | why? |
| children | API_general_purpose_coordination, more_better_performance |
| parents | zookeeper |
| more_better_performance | |
| content | Nx -> Nx performance (does adding more nodes yield better performance?) |
| children | read_from_replicas, write_more_slower |
| parents | why_zookeeper |
| API_general_purpose_coordination | |
| content | API general purpose coordination service |
| parents | why_zookeeper |
| raft_like | |
| content | RAFT-like |
| children | up_to_date |
| parents | zookeeper |
| write_more_slower | |
| content | write: more servers -> slwoer |
| parents | more_better_performance |
| remarks | write needs to coordinate with replicas, single server |
| read_from_replicas | |
| content | read from replicas |
| children | up_to_date |
| parents | more_better_performance |
| remarks | reading from replicas speeds things up |
| up_to_date | |
| content | up to date? (maybe, maybe not) |
| children | not_good_correctness |
| parents | raft_like, read_from_replicas |
| not_good_correctness | |
| content | not good for correctness |
| children | how_to_make_safe |
| parents | correctness, up_to_date |
| how_to_make_safe | |
| content | How to make safe? |
| children | non_linearized_reads_rules |
| parents | not_good_correctness |
| non_linearized_reads_rules | |
| content | non-linearized reads are in the rules of conistency |
| children | still_useful |
| parents | how_to_make_safe |
| remarks | in other words, zookeeper doesn't provide guarantee for reads. A tradeoff of correctness for read performance |
| still_useful | |
| content | Is this still useful? |
| parents | non_linearized_reads_rules |
| consistency_guarantees | |
| content | Consistency Guarantees |
| children | fifo_client_order, reads, reasonable_programming |
| parents | zookeeper |
| writes_linearizable | |
| content | Writes are linearizable |
| parents | correctness, linearizability |
| fifo_client_order | |
| content | FIFO client order: any given client operations are in that order |
| children | writes_client_specified_order (AKA) |
| parents | consistency_guarantees |
| writes_client_specified_order | |
| content | Writes: client-specified order |
| parents | fifo_client_order |
| reads | |
| content | reads |
| children | relative_to_log |
| parents | consistency_guarantees |
| relative_to_log | |
| content | relative to log client is talking to |
| children | sucessive_reads |
| parents | reads |
| sucessive_reads | |
| content | occur in log. successive reads have to be in order |
| children | cant_go_backwards |
| parents | relative_to_log |
| cant_go_backwards | |
| content | Can't go backwards |
| children | client_switches_replicas |
| parents | sucessive_reads |
| client_switches_replicas | |
| content | rule still holds if client switches replicas |
| children | zxid_tag |
| parents | cant_go_backwards |
| zxid_tag | |
| content | ZXID tag from leader entry |
| children | client_remembers |
| parents | client_switches_replicas |
| client_remembers | |
| content | Client remembers |
| children | replica_responds_zxid |
| parents | zxid_tag |
| replica_responds_zxid | |
| content | replica responds with zxid |
| parents | client_remembers |
| remarks | "highest ZXID I've ever seen" |
| reasonable_programming | |
| content | Possible to reasonable programming with? |
| children | sync |
| parents | consistency_guarantees |
| sync | |
| content | sync operation |
| children | proliferates_like_write |
| parents | reasonable_programming |
| proliferates_like_write | |
| content | Proliferates through system like write |
| children | sync_before_read |
| parents | sync |
| sync_before_read | |
| content | sync before a read gets data |
| parents | proliferates_like_write |
| remarks | sync is therefore an expensive operation |