explaingit

twitter/twemproxy

12,342CAudience · ops devopsComplexity · 4/5Setup · hard

TLDR

A lightweight C proxy server created at Twitter that reduces connection overhead to Redis and Memcached clusters by pooling connections and sharding keys across multiple backend servers.

Mindmap

mindmap
  root((twemproxy))
    What it does
      Connection pooling
      Redis proxy
      Memcached proxy
    Features
      Key sharding
      Zero-copy memory
      Stats monitoring
    Config
      YAML pools
      Timeout settings
    Audience
      DevOps engineers
      Backend teams
Click or tap to explore — scroll the page freely

Code map

Detail Auto

An interactive map of this repo's files and how they connect — its source is parsed live in your browser. Click Visualize to build it.

filefunction / class

Things people build with this

USE CASE 1

Reduce the number of open connections to a Redis or Memcached cluster when many application servers all connect at once.

USE CASE 2

Automatically distribute cache keys across multiple Redis servers without changing your application code.

USE CASE 3

Add a connection pool in front of Memcached to handle traffic spikes without overwhelming the cache layer.

USE CASE 4

Monitor active connections and request rates by querying Twemproxy's built-in statistics port.

Tech stack

CYAML

Getting it running

Difficulty · hard Time to first run · 1h+

Requires compiling from source on Linux and configuring a YAML pool file with backend server addresses.

In plain English

Twemproxy, also called nutcracker, is a lightweight proxy server written in C that sits between your application and your caching servers. It was created at Twitter to solve a specific problem: when many application servers all try to open connections to a caching layer like Redis or Memcached, the caching servers get overwhelmed with connection overhead. Twemproxy acts as a middleman, accepting many incoming connections but maintaining only a small number of outgoing connections to the actual caching servers. The proxy speaks both the Memcached text protocol and the Redis protocol, so your application connects to twemproxy as if it were a regular Redis or Memcached server. Twemproxy then routes requests to the appropriate backend server based on a hashing algorithm, which also means data is automatically spread across multiple servers. When you need to add more caching capacity, you add more servers to the pool. Configuration is done through a YAML file where you define server pools, each with its own list of backend servers. You can set timeouts, choose how keys get distributed across servers, configure whether failed servers get temporarily removed from rotation, and tune connection limits. The tool also exposes a statistics port you can query to monitor what it is doing. One notable internal design choice is zero-copy memory handling. The same memory buffer that receives a request from a client is used directly to send that request to the backend server, avoiding unnecessary copying. This keeps memory usage low and processing fast even under heavy load. The project originated at Twitter and is open-source. It supports Linux, BSD variants, macOS, and Solaris. The README is detailed and covers build steps, all configuration options, and internal implementation notes.

Copy-paste prompts

Prompt 1
Set up a Twemproxy configuration YAML file that pools connections from my app servers to a 3-node Redis cluster using consistent hashing.
Prompt 2
How do I configure Twemproxy to automatically remove a failed Redis server from rotation and re-add it when it recovers?
Prompt 3
What is the correct Twemproxy YAML config to set connection limits and request timeouts for a Memcached pool?
Prompt 4
How do I query the Twemproxy statistics port to get a JSON snapshot of active connections and request counts?
Open on GitHub → Explain another repo

← twitter on gitmyhub — every repo by this author, as a profile.

Verify against the repo before relying on details.