![]() One approach is to synchronously try fetch the new item, but then optimistically continue to use the old one if that’s possible (optimistic because it’s making the optimistic assumption that the item hasn’t change). Two more optimistic patterns are quite commonly used to address this situation (especially in DNS and networking systems). Thus the pessimistic TTL approach has a strong availability disadvantage: if a network partition or authority downtime lasts longer than the TTL, the cache hit rate will drop to zero. This is unavoidable: caches simply can’t provide strongly bounded staleness (or any other strong recency guarantee) if they can’t reach the authority 4. One downside of the pessimistic approach TTL takes is that it means the cache empties when it can’t talk to the authority. In systems with a low per-item write rate, that pessimistic assumption can be wrong much more often than it’s right. It’s also a pessimistic one: the cache is doing extra work assuming that the item has changed. This is a simple, strong, and highly popular mechanism. The TTL provides a strong 3 upper bound on how stale an item can be. This simply means that the cache only keeps items around for a certain fixed period of time. Possibly the most common way of ensuring this property-that inconsistencies are short-lived-is with a time to live (TTL). In other words, inconsistencies are relatively short-lived. By eventually consistent we mean that if the write stream stops, the caches eventually all converge on containing the same data. ![]() Unlike with CPUs 2, distributed caches typically aren’t coherent, but we still want them to be eventually consistent. To make this concrete, let’s consider some examples.ĭistributed caches almost always make assumptions about whether the data they are holding is changed or not. The pessimistic assumption takes the bull by the horns and makes sure it will. The optimistic assumption assumes it’ll get away with its plans. I generally think of optimistic assumptions as ones that avoid or delay coordination, and pessimistic assumptions as ones that require or seek coordination. The choice between pessimistic and optimistic assumptions can make a huge difference to the scalability and performance of systems. ![]() I find it very useful, when thinking through the design of a distributed system, to be explicit about each assumption each component is making, whether that assumption is optimistic or pessimistic, and what exactly happens if the assumption is wrong. One way to classify these assumptions is into optimistic and pessimistic assumptions. If two components can’t check in with each other after every single step, they need to make assumptions about the ongoing behavior of the other component. When we build systems that avoid coordinating, we end up building components that make assumptions about what other components are doing. ![]() Optimism vs Pessimism in Distributed SystemsĪvoiding coordination is the one fundamental thing that allows us to build distributed systems that out-scale the performance of a single machine 1. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |