Twemproxy Architecture Analysis

Twemproxy Overview

Twemproxy is one of the important components to build distributed cache cluster. He can send Redis packets from clients to different Redis servers via key shards, rather than to a single Redis server. As a result, information that would have been centralized on a redis could be diverted to several Redis, which enabled Twemproxy to support Redis clusters. It is not difficult to think that because of the Twemproxy sharding feature, it is easy to scale the Redis cluster horizontally (simply by adding more Redis servers to a business), and for a little modification of the code, we can get a redis cluster that can read and write, This greatly improves the performance of the Redis cluster. This makes the major companies such as Pea Pod, Ali, Baidu and so on the code has been modified, can make it meet the requirements of distributed cache cluster. Of course, Twemproxy is not responsible for data consistency.

Source: https://github.com/twitter/twemproxy/

Twemproxy Architecture

In order to better understand Twemproxy's code structure, we need to understand the architecture of Twemproxy and understand the components that interact with it. Here is the general Twemproxy architecture diagram

Client is the client, where clients can be many applications, such as Web pages, or servers that require Redis support. LVS is a Linux virtual server, it is mainly used for load balancing, of course, this layer of load balancing can be done by other means, such as haproxy, of course, can not need this layer, can let the client directly connected to Twemproxy. Memchache and Redis are two cache servers currently supported by Twemproxy, and Redis servers are typically used for high availability and specific functionality.

From this frame composition, we can begin to explain the characteristics of twemproxy, read the source folder under the "Readme.md" features, as to how he achieved, we need to interpret the code, this is not the task to complete this chapter.

1.Fast, that is fast, according to test, Direct connect twenproxy and direct even redis compared to almost no performance loss, this is very counter-productive, the most important thing is that he has not read and write separation can achieve this effect, indeed Fast

2.Lightweight, which is lightweight, as far as I'm concerned, the code is lightweight, because transparent connection pooling, memory 0 copies, and the use of the Epoll model make it fast and lightweight enough.

3.Enables pipelining of requests and responses,keeps connection count on the backend caching servers low, that is, maintain the number of connections on the front end, reducing the connection at the back end Number, mainly due to the use of transparent connection pool, the front end mainly refers to the client and LVs, the back end refers to Redis and Memchache, this benefit is particularly obvious, not only can reduce the Redis connection load, but also maintain the functionality of the front-end.

4.Enables pipelining of requests and responses, the upcoming request and the reply pipeline, here I understand that he will request the package and reply package one by one, so that its request and reply more clearly.

5.Supports multiple server pools Simultaneously,shard data automatically across multiple servers these two features, This is done through the sharding feature that I talked about earlier in the Twemproxy.

6.Implements the complete memcached ASCII and Redis protocol, which supports both protocols, of course, now only supports most of the protocols rather than all of them, which is explained later.

7.Supports multiple hashing modes including consistent hashing and distribution. That's him. Supports many hashing algorithms to hash key.

8.Easy configuration of server pools through a Yaml file. His profile is configured through the Yaml files

9.Can is configured to disable nodes on failures. Automatically indicates the node that failed.

10.Observability via stats exposed on the stats monitoring port. This is his monitoring function, generally less use.

With the above functional analysis, we can sort out a list of features on the implementation that we should be concerned about:

1. Memory management, which is one of the key factors that lead to features 1 and 4, he uses a number of methods, such as memory not immediately after the release of the memory in the queue for it to use, memory 0 copies and other means to make memory use efficiency greatly increased. Nc_mbuf files in the corresponding source code

2. Transparent connection pool, which is the key to the characteristics of 1,3, of course, the connection pool connection is also not immediately released after use to put it into the connection queue for it to use. nc_connection files in the corresponding source code

3. Sharding, which is the key to feature 5,6, is also the core function of Twenproxy. Of course, the 7,8 in the back also led to the fragmentation. Proto folder, Hashkit folder in the corresponding source code

4. configuration file, which affects the feature 8, and the code in the configuration of the code style is very simple, corresponding to the source of the nc_conf file

5. Monitoring, not particularly understood but it completed the 9,10 features, corresponding to the source of Nc_proxy, nc_stats files

Twemproxylinux under Installation

1. First install the autoconf2.69, please refer to my blog http://www.cnblogs.com/onlyac/p/5408420.html

2. Enter the source directory

CD Twemproxy

3. Preparing for compilation using autoconf

Autoreconf-fvi

./configure cflags= "-g-gstabs-o3-fno-strict-aliasing"--enable-debug=full

4. Compiling and installing

Make && make install

This compilation and the installation of the program Nutcracker has been generated in the SRC directory.

Summarize

In this article, we first outline the twemproxy, and then through the architecture analysis, we have to extract the will become our reading source of some important points of concern and twemproxy work environment, and finally elaborated how to install Twemproxy.

Twemproxy Architecture Analysis