Introduction
redis as a good representative of NoSQL software, are becoming increasingly popular, although Redis it is easy to start and to use, but to make good use of it online will not be easy. redis high availability and scalability that comes with Redis Sentinel whether or Redis Cluster require additional client support, and now basically no suitable clients are able to do these things, in fact the client to do these things and inappropriate, it makes maintenance particularly difficult. So between the client and the server redis add a layer of agents has become an ideal solution, shielding the back-end proxy Redis implementation details redis provide services to clients, Redis can be the perfect solution to high availability and scalability issues, while Redis introducing agent also makes maintenance easier. Before this paper is to introduce the agent predixy, there have been several popular redis agents, they are unique. Next, we have to compare the following agents:
Introducing the Agent 
a detailed feature comparison 
Simply put, predixy supports both Redis Sentinel also support Redis Cluster
A group of the Sentinel Redis Redis rear of the monitor, the original fully functional equivalent Redis
plurality of sets of the Sentinel Redis Redis rear of the monitor, then the some functional limitations
rear end of the Cluster Redis, the Cluster Redis functions exactly the same
performance
as a proxy redis high performance is a mandatory requirement in order to test the performance of the above four agents then we take to be a simple evaluation, test platform and each agency specific version information is as follows:
redis deployment:
Threaded SET / GET test
herein refers to four threaded agents operate under a single thread (hereinafter the same), redis-benchmark default concurrent client connections 50, each connected to each send a response received after command issued the next command. This is the actual scene a lot online.
Test Command:
$ Redis-Benchmark -t -p xxx the SET, GET -r -n 3000 1000000 -d xxx
test results:
Results show that:
in throughput, performance orderly arrangement of four agents, predixy significantly ahead of the other three agents, but again twemproxy large lead over the other two, the remaining amount of data in less than two codis 512 when slightly ahead cerberus, and when data is larger than 512, codis leading to cerberus is growing. When the overall amount of data to reach 16KB, due redis-benchmark itself become a bottleneck, predixy and twemproxy the SET results almost the same.
On the delay, codis due to problems of language, has been greater than the other three agents, follow-up tests, too.
Single-threaded PIPELINE SET / GET test
under some scenarios, the client may request might need to initiate redis many times in dealing with a request, then if the request pipeline request more redis together, it will significantly improve performance. Take a look at the current round of testing when the client asked us to send multiple agency how to behave? Redis-benchmark still concurrent connections 50, 20 but a transmitted command.
Test Command:
$ Redis-Benchmark -t -p xxx the SET, GET -r -n 3000 20 5000000 -P -d xxx
Test Results: 
results show that:
in the throughput, redis-benchmark after a pipeline 20 commands, each agent throughput all soared. predixy is Yiqijuechen, far ahead of the other three, and the last to see predixy performance and other agents when the number of GET 4K data almost because predixy, when the data amount is greater than 2K redis-benchmark itself has become bottleneck. The other three agents, lagging behind in the last round of tests began to show a far better cerberus twemproxy and codis in the current round of testing, but cerberus there is still a large amount of data with performance rapidly deteriorates. twemproxy and codis in the current round of testing performance is roughly equal.
On the delay, the problems inherent in codis poor performance, the other three in a small amount of data when the difference is small, but when the amount of data exceeds 512, predixy showed a clear advantage.
Dual-threaded PIPELINE SET / GET test
measured over a single-threaded, multi-threaded test and now we start, because the twemproxy does not support multi-threaded, multi-threaded therefore twemproxy not participate in the test. Taking into account redis-benchmark itself is a single-threaded program, in multithreaded agent if we measure the performance of a single command, that redis-benchmark is likely that bottlenecks can not be more explicit show the performance of each agent, so we direct Pipeline testing, even went as the last round, 50 simultaneous connections, first transmission 20 commands.
Test Command:
$ Redis-Benchmark -t -p xxx the SET, GET -r -n 3000 20 10000000 -P -d xxx
test results:
Description result:
consistent overall trends and the second round of the single-threaded pipeline testing, predixy still took the lead in this round of tests, but at the beginning of cerberus and predixy ahead codis, cerberus and predixy did not differ much. But with the amount of data increases, cerberus again showed a sharp decrease performance problems, beyond 1K even worse than the codis.
Conclusion
on the comparison function, predixy more comprehensive compared to the other three agents, which can be fully applicable to the use of native redis scene. In performance, predixy are leading by a wide margin in each round of testing. A summary of the agency are as follows:
predixy: full function, either from a single master Redis, may also be used Redis Cluster; excellent performance.
twemproxy: availability dependent consistent hashing, only scenario in the cache, using memory NA; medium performance.
codis: Applicable redis clusters use; performance in general.
cerberus: suitable for use Redis Cluster; acceptable performance in the pipeline and a smaller amount of data usage, or poor performance.