Mcrouter

Mcrouter is a Memcached protocol router for scaling Memcached deployments. It’s a core component of cache infrastructure at Facebook and Instagram where mcrouter handles almost 5 billion requests per second at peak. See FB engineering blog post about mcrouter.

Mcrouter is developed and maintained by Facebook.

Because the routing and feature logic is abstracted from the client in mcrouter deployments, the client may simply communicate with destination hosts through mcrouter over a TCP connection using standard Memcached protocol. Typically, little or no client modification is needed to use mcrouter, which was designed to be a drop-in proxy between the client and Memcached hosts.

Mcrouter supports typical Memcache protocol commands like getting, set, delete, etc. and specific commands to access stats, version and so on.

Features

• Memcached ASCII protocol
• Connection Pooling
• Multiple hashing schemes
• Prefix routing
• Replicated pools
• Production traffic shadowing
• Online reconfiguration
• Flexible routing
• Destination health monitoring/automatic failover
• Cold cache warm-up
• Broadcast operations
• Reliable delete stream
• Multi-cluster support
• Rich stats counters, Stats commands and debug commands
• Quality of service
• Large values
• Multi-level caches
• IPv6 support
• SSL support
• News

Release v0.14.0. (November 25, 2015) Starting today, we will sync all mcrouter commits continuously to the master branch of our GitHub repo. In addition, we will be cutting a biweekly release branch that is intended to be stable and resilient to third-party incompatibilities. This week’s release appears as the release-14-0 branch in our GitHub repo.

Initial open source release (mcrouter 1.0) (September 15, 2014)

List of Route Handles

AllAsyncRoute

Immediately sends the same request to all child route handles. Does not wait for the response. Returns the default reply for the request right away as returned by NullRoute.

AllFastestRoute

Immediately sends the same request to all child route handles. Returns the first non-error reply to come back. Other requests complete in the background and their replies are silently ignored.

AllInitialRoute

Immediately sends the same request to all child route handles. Waits for the reply from first route handle in the children list and returns it. Other requests are completed asynchronously in the background.

AllMajorityRoute

Immediately sends the same request to all child route handles. Waits for replies until a non-error result appears (half + 1) times (or all replies if that never happens), and then returns the latest reply that it sees (the effect is that typically the reply with the most common result is returned).

AllSyncRoute

Immediately sends the same request to all child route handles. Collects all replies and responds with the “worst” reply (i.e., the error reply, if any).

DevNullRoute

Same as NullRoute, but with mcrouter stats reporting.

ErrorRoute

Immediately returns the error reply for each request. You can specify the error value to return: “ErrorRoute|MyErrorValueHere”

FailoverRoute

Sends the request to the first child in the list and waits for the reply. If the reply is a non-error, returns it immediately. Otherwise, depending on the settings, sends the request to the second child, and so on. If all children respond with errors, returns the last error reply. Note: miss (key not found) doesn’t count for an error. See MissFailoverRoute to failover misses.

FailoverWithExptimeRoute

FailoverRoute with additional settings. Sends request to normal route handle. If it responds with an error, checks settings, and failovers to failover if necessary.

HashRoute

Routes to the destination based on the key hash.

HostIdRoute

Routes to one destination chosen based on client host ID.

LoadBalancerRoute

Load balances to a destination from a list of children. The two supported load balancing algorithms are “weighted-hashing” and “two-random-choices”.

In weighted-hashing, requests are hashed between the children taking into account a cached server load for each child.

In two-random-choices, two children are chosen at random and the child with the lowest load is selected.

In both algorithms, the load for each child is cached from a previous response and has a configurable expiry time. On expiry, it will be reset to the configured default server load.

MigrateRoute

• This route handle changes behavior based on Migration mode.
• Before migration starts, sends all requests to from route handle.
• Between start_time and (start_time + interval), sends all requests except deletes to from route handle, send all delete requests to both from and to route handle. For delete requests, returns reply from worst of two replies (i.e., any error reply).
• Between (start_time + interval) and (start_time + 2*interval), sends all requests except deletes to route handle and sends all delete requests to both from and to route handle. For delete requests, returns reply from worst among two replies.
• After (start_time + 2*interval), sends all requests to route handle.

MissFailoverRoute

For get-like requests, sends the same request sequentially to each route handle in the list, in order, until the first hit reply. If all replies result in errors/misses, returns the reply from the last destination in the list.

ModifyExptimeRoute

Modifies exptime (TTL) for all requests.

 

NullRoute

Returns the default reply for each request right away. Default replies are:

• delete – not found
• get – not found
• set – not stored

PrefixSelectorRoute

Sends to different targets based on specified key prefixes.

PoolRoute

Route handle that routes to a pool. With different settings, it provides the same functionality as HashRoute, but also allows rate limiting, shadowing, et cetera.

OperationSelectorRoute (previously: PrefixPolicyRoute)

Sends to different targets based on specified operations.

RandomRoute

Routes to one random destination from the list of children.

WarmUpRoute

Allows for substantial changes to the number of boxes in a pool without increasing the miss rate and, consequently, to the load on the underlying storage or service.

All sets and deletes go to the target (“cold”) route handle. Gets are attempted on the “cold” route handle and, in case of a miss, data is fetched from the “warm” route handle (where the request is likely to result in a cache hit). If “warm” returns a hit, the response is forwarded to the client and an asynchronous request, with the configured expiration time, updates the value in the “cold” route handle.

The post Mcrouter appeared first on kubedex.com.