_____________ LECTURE8 Irene Zhang _____________ Table of Contents _________________ 1 Intro: .. 1.1 Caching is half of distributed systems .. 1.2 Motivating example: Dropbox ..... 1.2.1 the ideal ..... 1.2.2 the reality, .. 1.3 Some definitions and terms ..... 1.3.1 Coherence & consistency models: does the reality match the ideal ..... 1.3.2 some terms 2 Consistency model examples .. 2.1 ideal .. 2.2 what if clients don't know which one arrived first .. 2.3 what if an external observer knows which one arrived first .. 2.4 Obviously some of these models are easier than others, but there are trade-offs 3 Maintaining Consistency with Caching .. 3.1 only one client accessing .. 3.2 multiple clients accessing, each with own cache .. 3.3 cache invalidations .. 3.4 leases .. 3.5 You might think we should provide strong consistency, but pretty expensive, so it's a trade-off 4 Maintaining Consistency with Sharding .. 4.1 Yes! If we want consistency across keys, we need to maintain ordering across shards Lecture 8: Memory Models 1 Intro: ======== 1.1 Caching is half of distributed systems ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - two options: go to the data (RPC) or bring the data to you (caching) - Both have problems - Server could be far away, so latency to get there - Server has to run all RPC, so eventually there will be a throughput bottleneck - With caching, the problem is how to keep the data synchronized 1.2 Motivating example: Dropbox ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1.2.1 the ideal --------------- - one system, which the user accesses - lots of reasons you wouldn't want dropbox to actually work like this (i.e., performance, offline access, etc) 1.2.2 the reality, ------------------ - caches that are synchronized with the back-end, accesses from different places, partitioning 1.3 Some definitions and terms ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1.3.1 Coherence & consistency models: does the reality match the ideal ---------------------------------------------------------------------- - single object = coherence - multiple objects = consistency - caveat: no actual consistency even in our reading! naming is hard too! 1.3.2 some terms ---------------- - weakly consistent -- doesn't behave like a single system - eventually consistent -- the system temporarily doesn't behave like a single system, but over time (if no further modifications) it converges to look like a single system - sequentially consistent/serializable -- behaves like a single system, but might not match user expectations (i.e., a write that finishes first, looks like it finished later) - linearizable -- behaves like a single system to users (i.e., writes that finish later have their effects applied later) - caveat: how these terms are used depends on how much the reality differs from the ideal 2 Consistency model examples ============================ - Example: c1, c2, two writes a and b to one Dropbox file - let's pretend we don't know what is going on inside 2.1 ideal ~~~~~~~~~ - send both to the server, first to arrive is first, both clients see the same thing 2.2 what if clients don't know which one arrived first ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - i.e., the operations overlap - the server should be free to do either BUT both should see either (a, b) or (b, a) 2.3 what if an external observer knows which one arrived first ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - i.e., one operation finishes first and there is some external observer that knows this or the clients use some out-of-band operation to coordinate - if linearizable, the server should order (a, b) because the external observer can tell a finished first - if serializable, the server can order either (a, b) and (b, a), but both must still be the same - if weaker, one might see (a, b) and other might see (b, a) - if eventual, one might see (b, a) for a while and then see (a, b) later 2.4 Obviously some of these models are easier than others, but there are trade-offs ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 3 Maintaining Consistency with Caching ====================================== - let's assume each client has a cache - tons of systems use caches: NFS, many layers for web apps 3.1 only one client accessing ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - are there problems? - Could be: write to a, either write-through or remember to read from cache. this is surprisingly hard to get right! for example, Spanner doesn't! 3.2 multiple clients accessing, each with own cache ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - maybe you have dropbox on laptop and tablet - c1 writes a, but maybe c2 doesn't get it, or reads the cached file - then if c2 writes b, does that overwrite a? How do we merge? 3.3 cache invalidations ~~~~~~~~~~~~~~~~~~~~~~~ - invalidate the caches or store first? - if we invalidate the caches first, a client might read an old value before the store is updated - if we update the store first - so we actually need to lock everything - but slow! Possibly practical on processors but so slow that even processors don't do this in practice 3.4 leases ~~~~~~~~~~ - basic idea: only one client can write to their cache at a time - can have shared read leases (many readers, but no one can write) or an exclusive write lease - still pretty expensive because need to communicate with everyone to revoke a lease in order to write, need to keep more state per object 3.5 You might think we should provide strong consistency, but pretty expensive, so it's a trade-off ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - what do you do if you can't contact some of the clients? block? - the basis for the CAP theorem, which is a simplification: if you want strong consistency (C), but might have clients not be available (Partitioned), then you can't have (Availability) or vice versa 4 Maintaining Consistency with Sharding ======================================= - let's assume there are two files stored on different servers - Dropbox is probably actually built this way, although maybe your files can all be on one server - other apps like Facebook have to be built this way because of scale and no good way to partition the data - Do we have to do something across shards? 4.1 Yes! If we want consistency across keys, we need to maintain ordering across shards ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~