twemproxy(又称为nutcracker)是一个轻量级的Redis和Memcached代理，主要用来减少对后端缓存服务器的连接数。由Twitter开源出来的缓存服务器集群管理工具，主要用来弥补Redis和Memcached对集群(cluster)管理指出的不足。


antirez(Redis作者)写过一篇对twemproxy的介绍http://antirez.com/news/44，他认为twemproxy是目前Redis 分片管理的最好方案，虽然antirez的Redis cluster正在实现并且对其给予厚望，但是我从现有的cluster实现上还是认为cluster除了增加Redis复杂度，对于集群的管理没有twemproxy来的轻量和有效。


谈到集群管理不得不又说到数据的分片管理，为了满足数据的日益增长和扩展性，数据存储系统一般都需要进行一定的分片，如传统的MySQL进行横向分表和纵向分表，然后应用程序访问正确的位置就需要找的正确的表。这时候，这个数据定向工作一般有三个位置可以放，数据存储系统本身支持，服务器端和客户端中间建代理支持或者客户端支持。Redis Cluster就是典型的试图在数据存储系统上支持分片，而twemproxy就是试图在服务器端和客户端中间建代理支持，Memcached的客户端对分片的支持就是客户端层面的。

在三种方案中，客户端方案我认为欠妥，因为这样每个客户端需要维护一定的服务器信息，但是如果动态的增加或减少节点就需要重写配置各个客户端。而在服务器端增加集群管理有利于使用者，减少使用者需要了解的东西，整合集群管理使得性能比其他方案都要更高，但是缺点是其会严重增加代码复杂度，导致服务器端代码爆炸。而采用中间层代理的方式我认为是最优雅和有效的，在不改动服务器端程序的情况下，twemproxy使得集群管理更简单，去除不支持的操作和合并，同时更可以支持多个后端服务，大大减少连接数等等，但是缺点也是显而易见的，它不能更有效的利用集群的优势，如多键运算和范围查找操作等等，这都是需要服务器端程序本身支持。

最后，如果就Redis而言，我认为最好的方式是在Redis的基础上做一个代理计算层，也就是所有的操作通过这个代理计算层进行对Redis集群的操作，也就是一个Master-Slave结构的Redis集群，因为Redis作为一个后端服务，本身连接数不宜过多，通过多Slave备份Master达到的效果比无核心节点我认为更好。

回到Twemproxy，它主要通过事件驱动模型来达到高并发，每收到一个请求，通过解析请求，发送请求到后端服务，再等待回应，发送回请求方。主要涉及到三个重要的结构:server,connection, message。

server

struct server {
    uint32_t           idx;           /* server index */
    struct server_pool *owner;        /* owner pool */
                                                                                               
    struct string      pname;         /* name:port:weight (ref in conf_server) */
    struct string      name;          /* name (ref in conf_server) */
    uint16_t           port;          /* port */
    uint32_t           weight;        /* weight */
    int                family;        /* socket family */
    socklen_t          addrlen;       /* socket length */
    struct sockaddr    *addr;         /* socket address (ref in conf_server) */
                                                                                               
    uint32_t           ns_conn_q;     /* # server connection */
    struct conn_tqh    s_conn_q;      /* server connection q */
                                                                                               
    int64_t            next_retry;    /* next retry time in usec */
    uint32_t           failure_count; /* # consecutive failures */
};


每个server其实就是一个后端的缓存服务程序，Twemproxy可以预先连接每个server或者不，根据接收到的请求具体分析出key，然后根据key来选择适当的server，这里的选择过程采用一致性哈希算法，具体算法可以根据配置文件选择。

connection

connection在Twemproxy中非常重要，它分为三种类型的connection:proxy，client和server，也就是监听的socket，客户端连接的socket和连接后端的socket，其中proxy类型的工作比较简单，就是接受到请求，然后产生一个client connection或者server connection。

struct conn {
    TAILQ_ENTRY(conn)  conn_tqe;      /* link in server_pool / server / free q */
    void               *owner;        /* connection owner - server_pool / server */
                                                                       
    int                sd;            /* socket descriptor */
    int                family;        /* socket address family */
    socklen_t          addrlen;       /* socket length */
    struct sockaddr    *addr;         /* socket address (ref in server or server_pool) */
                                                                       
    struct msg_tqh     imsg_q;        /* incoming request Q */
    struct msg_tqh     omsg_q;        /* outstanding request Q */
    struct msg         *rmsg;         /* current message being rcvd */
    struct msg         *smsg;         /* current message being sent */
                                                                       
    conn_recv_t        recv;          /* recv (read) handler */
    conn_recv_next_t   recv_next;     /* recv next message handler */
    conn_recv_done_t   recv_done;     /* read done handler */
    conn_send_t        send;          /* send (write) handler */
    conn_send_next_t   send_next;     /* write next message handler */
    conn_send_done_t   send_done;     /* write done handler */
    conn_close_t       close;         /* close handler */
    conn_active_t      active;        /* active? handler */
                                                                       
    conn_ref_t         ref;           /* connection reference handler */
    conn_unref_t       unref;         /* connection unreference handler */
                                                                       
    conn_msgq_t        enqueue_inq;   /* connection inq msg enqueue handler */
    conn_msgq_t        dequeue_inq;   /* connection inq msg dequeue handler */
    conn_msgq_t        enqueue_outq;  /* connection outq msg enqueue handler */
    conn_msgq_t        dequeue_outq;  /* connection outq msg dequeue handler */
                                                                       
    size_t             recv_bytes;    /* received (read) bytes */
    size_t             send_bytes;    /* sent (written) bytes */
                                                                       
    uint32_t           events;        /* connection io events */
    err_t              err;           /* connection errno */
    unsigned           recv_active:1; /* recv active? */
    unsigned           recv_ready:1;  /* recv ready? */
    unsigned           send_active:1; /* send active? */
    unsigned           send_ready:1;  /* send ready? */
                                                                       
    unsigned           client:1;      /* client? or server? */
    unsigned           proxy:1;       /* proxy? */
    unsigned           connecting:1;  /* connecting? */
    unsigned           connected:1;   /* connected? */
    unsigned           eof:1;         /* eof? aka passive close? */
    unsigned           done:1;        /* done? aka close? */
    unsigned           redis:1;       /* redis? */
};


可以用面向对象的方法来考虑这个结构，struct conn就是个基类，而proxy，client和server是派生类，通过recv_done, recv_next, recv和send_done, send_next, send来达到多态的效果。

当客户端建立与Twemproxy的连接或者Twemproxy建立与后端服务的连接后，会生成一个conn结构，或为client或为server类。

message

struct msg {
    TAILQ_ENTRY(msg)     c_tqe;           /* link in client q */
    TAILQ_ENTRY(msg)     s_tqe;           /* link in server q */
    TAILQ_ENTRY(msg)     m_tqe;           /* link in send q / free q */
                                                          
    uint64_t             id;              /* message id */
    struct msg           *peer;           /* message peer */
    struct conn          *owner;          /* message owner - client | server */
                                                          
    struct rbnode        tmo_rbe;         /* entry in rbtree */
                                                          
    struct mhdr          mhdr;            /* message mbuf header */
    uint32_t             mlen;            /* message length */
                                                          
    int                  state;           /* current parser state */
    uint8_t              *pos;            /* parser position marker */
    uint8_t              *token;          /* token marker */
                                                          
    msg_parse_t          parser;          /* message parser */
    msg_parse_result_t   result;          /* message parsing result */
                                                          
    mbuf_copy_t          pre_splitcopy;   /* message pre-split copy */
    msg_post_splitcopy_t post_splitcopy;  /* message post-split copy */
    msg_coalesce_t       pre_coalesce;    /* message pre-coalesce */
    msg_coalesce_t       post_coalesce;   /* message post-coalesce */
                                                          
    msg_type_t           type;            /* message type */
                                                          
    uint8_t              *key_start;      /* key start */
    uint8_t              *key_end;        /* key end */
                                                          
    uint32_t             vlen;            /* value length (memcache) */
    uint8_t              *end;            /* end marker (memcache) */
                                                          
    uint8_t              *narg_start;     /* narg start (redis) */
    uint8_t              *narg_end;       /* narg end (redis) */
    uint32_t             narg;            /* # arguments (redis) */
    uint32_t             rnarg;           /* running # arg used by parsing fsa (redis) */
    uint32_t             rlen;            /* running length in parsing fsa (redis) */
    uint32_t             integer;         /* integer reply value (redis) */
                                                          
    struct msg           *frag_owner;     /* owner of fragment message */
    uint32_t             nfrag;           /* # fragment */
    uint64_t             frag_id;         /* id of fragmented message */
                                                          
    err_t                err;             /* errno on error? */
    unsigned             error:1;         /* error? */
    unsigned             ferror:1;        /* one or more fragments are in error? */
    unsigned             request:1;       /* request? or response? */
    unsigned             quit:1;          /* quit request? */
    unsigned             noreply:1;       /* noreply? */
    unsigned             done:1;          /* done? */
    unsigned             fdone:1;         /* all fragments are done? */
    unsigned             first_fragment:1;/* first fragment? */
    unsigned             last_fragment:1; /* last fragment? */
    unsigned             swallow:1;       /* swallow response? */
    unsigned             redis:1;         /* redis? */
};


struct msg是连接建立后的消息内容发送载体，这个复杂的msg结构很大程度是因为需要实现pipeline的效果，多个msg属于同一个conn，conn通过接收到内容解析来发现几个不同的msg。

事件驱动
static void
core_core(struct context *ctx, struct conn *conn, uint32_t events)
{
    rstatus_t status;
                                                 
    log_debug(LOG_VVERB, "event %04"PRIX32" on %c %d", events,
              conn->client ? 'c' : (conn->proxy ? 'p' : 's'), conn->sd);
                                                 
    conn->events = events;
                                                 
    /* read takes precedence over write */
    if (events & EVENT_READABLE) {
        status = core_recv(ctx, conn);
        if (status != NC_OK || conn->done || conn->err) {
            core_close(ctx, conn);
            return;
        }
    }
                                                 
    if (events & EVENT_WRITABLE) {
        status = core_send(ctx, conn);
        if (status != NC_OK || conn->done || conn->err) {
            core_close(ctx, conn);
            return;
        }
    }
}


事件驱动库会绑定每一个socket fd到一个conn，当检测到可读时，会调用conn->recv来推动，如果是proxy的fd可读，这时conn->recv的工作就是建立一个新的连接来接收消息。如果client的fd可读，其对应的conn的conn->recv的工作就是接收内容并分析。如果server的fd可读时，其对应的server conn的conn->recv的工作是接收到后端服务的回应，然后再回发给请求方。

小结

Twemproxy的架构比较清晰，对Twemproxy源码印象较深的是对logging的合理布局和错误处理的清晰，这是第一次看大公司开源出来的代码，非常重视logging和错误处理。

我的fork

由于Twitter开源的Twemproxy直接使用epoll驱动，导致其他不支持epoll的系统无法使用，因此我fork了一个版本，加入了kqueue支持，让FreeBSD和Mac os x能够成功编译运行，并且因为Twemproxy不合理的将epoll嵌入到业务逻辑中，因此，只能大改事件驱动的相关代码，将复用IO的结构抽象出来，并且增加了部分结构。

我的Twemproxy Fork版本