Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proxy: V system leasing #6065

Closed
heyitsanthony opened this issue Jul 28, 2016 · 1 comment
Closed

proxy: V system leasing #6065

heyitsanthony opened this issue Jul 28, 2016 · 1 comment

Comments

@heyitsanthony
Copy link
Contributor

Suppose a client starts spamming the etcd cluster with Puts to a key with many watchers. This will cause a lot of network traffic and considerable server load. Likewise, suppose a client keeps requesting the same serialized ranges / txns for keys that it just wrote out, also causing unnecessary network traffic. What to do?

V system leasing reduces the communication overhead of these situations. This can be implemented on top of etcd3 through a proxy. A sketch and some remarks:

All clients go through a local proxy. When a client writes to a fresh key the proxy will grant itself a lease with an attached lease key. The presence of the lease key locks the other proxies from immediately sending updates to the key to their clients (updates are still posted to all clients connected to the proxy that owns the lease). When the key is updated, the proxy will keep-alive the lease. If the lease expires, the proxy loses its claim on that key. When a proxy services a write to a key with a foreign lease, it will transactionally delete the foreign lease key and create a lease key for itself. Starvation is avoided by periodically refreshing any cached keys / updating gated watchers.

Watch optimizations:

  1. Watchers on rev=0 that have not yet received an event can get the revision after the write spam. (this can only be done per-stream because the create header revision can't be faked easily)
  2. Watchers that have a set revision still have to receive the spam events, but gating the writes until after the lease expires will makes it possible to benefit from event batching. Alternatively, there could be a "coalescing" flag for watchers where it can drop events on a key in favor of the most recent one.

Serialized Range caching:
When a proxy fetches a key, it also fetches its lease key (or creates a new lease key, if none exists). The key is then used for the rev=0 serialized range cache. If the lease key expires, the key is discarded as stale.

/cc @HardySimpson

@heyitsanthony
Copy link
Contributor Author

Fixed by #8341

@gyuho gyuho modified the milestones: v3.3.0, unplanned Aug 8, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

3 participants