gogoWebsite

preamble

In this article we will introduce the four modes of Redis and analyze the advantages and disadvantages of each.
Redis has a total of 4 modes:

1. Master-slave replication mode

2. (Sentinel) Sentinel mode

3. (Cluster) Cluster mode
4. Agent mode

1. master-slave mode

1.1 Introduction

The master-slave model is the simplest of the three, and in master-slave replication, the database is divided into 2 categories: master and slave databases

• The master database can perform read and write operations, and will automatically synchronize data to the slave database when read and write operations result in data changes.

• Slave databases are generally read-only, and receive data synchronized from the master database.

• A master can have multiple slaves, but a slave can only correspond to one master.

• A hung slave does not affect the reads of other slaves or the reads and writes of the master, and will synchronize the data from the master after restarting.

• After the master hangs, does not affect the slave read, but redis no longer provide write services, master restart redis will be re-provided to the outside world write service

• When the master hangs, a new master will not be selected in the slave node.

1.2 Working Mechanisms

When the slave starts up, it actively sends SYNC commands to the master. master receives the SYNC commands and saves the snapshots (RDB persistence) and caches the commands for the snapshots in the background, and then sends the saved snapshots and cached commands to the slave. slave receives the snapshots and commands and then loads the snapshots and cached commands for execution. After replication is initialized, every time the master receives a write command, it will be sent to the slave synchronously to ensure master-slave data consistency.

Drawbacks:

As you can see from the above, the master node is unique in the master-slave model, and if the master hangs, redis cannot provide write services to the outside world.

2. Sentinel Mode

2.1 Introduction

The disadvantage of the master-slave model is that it does not have high availability. When the master hangs, Redis will no longer be able to provide write operations to the outside world, because the sentinel is born.

The role of the sentinel is to monitor the operation of the redis cluster. The features are as follows:

* :: The sentinel model is based on a master-slave model; if there is only one Redis node, sentinel doesn't make any sense

* When the master hangs, Sentinel will choose one of the slaves to be the master and modify their configuration files, and the configuration files of the other slaves will also be modified, for example, the slaveof attribute will point to the new master.

* When the master is restarted, it will no longer be the master but will act as a slave to receive synchronization data from the new master.

* :: Because sentinel is also a process with the possibility of hanging, sentinel will also start more than one to form a sentinel cluster

* :: When multiple sentinels are configured, automatic monitoring is also performed between the sentinels

* When the password is configured in master-slave mode, sentinel also synchronizes the configuration information to the configuration file, so you don't need to worry about the

* :: A single sentinel or cluster of sentinels can manage multiple master and slave Redis, and multiple sentinels can monitor the same Redis

* :: Sentinel should not be deployed on the same machine as Redis, otherwise when the Redis server hangs, so does the sentinel.

2.2 Working Mechanisms

• Each sentinel sends a PING command to the master, slave, and other sentinel instances it knows about at a rate of once per second.

• If the time since the last valid reply to a PING command for an instance exceeds the value specified by the down-after-milliseconds option, the instance is marked as subjectively down by the sentinel.

• If a master is flagged as subjectively offline, all sentinels that are monitoring the master are required to confirm that the master is indeed in the subjective offline state at a rate of once per second

• When a sufficient number of sentinels (greater than or equal to the value specified in the configuration file) confirm that the master has indeed entered the subjective offline state within the specified timeframe, the master will be marked as objectively offline.

• In general, each sentinel sends INFO commands to all known masters and slaves every 10 seconds.

• When a master is marked as objectively offline by the Sentinel, the frequency of INFO commands sent by the Sentinel to all slaves of the offline master is changed from once every 10 seconds to once every 1 second.

• If a sufficient number of sentinels do not agree that the master has gone offline, the master's objective offline status is removed;

• If the master returns a valid reply to the sentinel's PING command, the master's subjective offline status is removed

2.3 Points of Attention

When using the sentinel mode, the client should not connect to Redis directly, but connect to the ip and port of the sentinel, and the sentinel will provide the specific Redis implementation that can provide the service, so that when the master node hangs, the sentinel will sense and provide the new master node to the user.

3. Cluster mode

3.1 Introduction

Sentinel mode can basically meet the needs of general production with high availability. But when the amount of data is too large to a server can not store the situation, the master-slave mode or sentinel mode can not meet the demand, this time you need to store the data for slicing, the data will be stored to multiple Redis strength, cluster mode appears to solve the problem of limited capacity of a single Redis machine, the Redis data according to certain rules The Redis data is allocated to multiple machines according to certain rules.

3.2 Working Mechanisms

cluster can be said to be a combination of sentinal and master-slave mode, through the cluster can realize the master-slave and master re-election function, so if you configure two copies of three slices, you need six Redis instances. Because Redis data is allocated to different machines in the cluster according to certain rules, when the amount of data is too large, new machines can be added for expansion.

To use clustering, just turn on the cluster-enable configuration in the redis configuration file. You need at least 3 master databases in each cluster to run properly, and it's very easy to add new nodes.

3.3 Advantages of Cluster Clustering

• Multiple redis nodes network interconnection, data sharing

• All nodes are one master and one slave (can also be one master and multiple slaves), where they never provide services and only serve as a standby

• Support for adding and deleting nodes online

• Clients can connect to any of the master nodes for reads and writes

3.4 Disadvantages of cluster clustering

• Multiple keys at the same time (e.g. MSET/MGET) are not supported because redis needs to distribute the keys evenly across the nodes, the

• Simultaneous key-value creation with high concurrency can degrade performance and lead to unpredictable behavior

4. agency model

In Redis, the proxy pattern is often used to achieve data sharding and load balancing. Currently the more popular proxy frameworks are as follows :

• twemproxy: fast, lightweight memcached and redis proxy, developed by Twitter Twitter Inc.

• codis: redis cluster agent solution, pea pod company development, need to modify redis source code

• predixy: high-performance full-featured redis agent with support for Redis Sentinel and Redis Cluster

• Redis-cerberus: Redis Cluster Agent

Contrast:

4.1 Twemproxy

4.1.1 Working mechanisms

Twemproxy is a proxy slicing mechanism , open source by Twitter. Twemproxy as a proxy , can accept access from multiple programs , according to the routing rules , forwarded to the background of each Redis server , and then return the original way . The program is a good solution to the problem of carrying capacity of a single Redis instance . Twemproxy can use multiple servers to horizontally expand the redis service, you can effectively avoid the single point of failure problem.

4.1.2 Disadvantages

• Twemproxy itself is also a single point (requires Keepalived for a highly available solution)

• Using Twemproxy requires more hardware resources and there is some loss in redis performance (twitter tests around 20%)

4.1.3 Unsupported commands

/twitter/twemproxy/blob/master/notes/

4.2 Codis

Codis is a distributed Redis solution , for the upper application , connect to the Codis Proxy and connect to the native RedisServer there is no obvious difference ( some commands are not supported ) , the upper application can be used as a stand-alone Redis the same use , the Codis bottom will deal with the forwarding of the request , non-stop data migration and other work , all the All the things behind, for the front of the client is transparent, you can simply think that the back of the connection is an infinite memory Redis service.

4.2.1 Working mechanisms

Codis contains the following components

• Codis Proxy (codis-proxy)

• Codis Manager (codis-config)

• Codis Redis (codis-server)

• ZooKeeper

codis-proxy is a client-connected Redis proxy service, codis-proxy itself implements the Redis protocol, behaves no differently than a native Redis (like Twemproxy), for a business, multiple codis-proxies can be deployed, codis-proxy itself is stateless. The codis-proxy itself is stateless.

codis-config is a Codis management tool that supports operations such as adding/removing Redis nodes, adding/removing Proxy nodes, initiating data migrations, etc. It also comes with an http server that starts a dashboard that allows you to observe the status of the Codis cluster directly from your browser. codis-config comes with an http server, which starts a dashboard that allows you to view the status of your Codis cluster directly from your browser.

codis-server is a Redis branch maintained by the Codis project, based on 2.8.13, which adds slot support and atomic data migration commands. The codis-proxy and codis-config can only interact with this version of Redis.

Codis relies on ZooKeeper to store the data routing table and meta-information about the codis-proxy nodes, and commands initiated by codis-config are synchronized to the surviving codis-proxies via ZooKeeper.

Codis supports differentiation of products according to Namespace, products with different product names will not conflict with each configuration.

4.2.2 Advantages

• automatic balancing

• Very easy to use

• Graphical panels and management tools

• Supports most Redis commands and is fully compatible with twemproxy.

• Support for Redis Native Clients

• Secure and transparent data migration, easily adding and removing nodes as needed

• Provide command line interface

• RESTful API

4.2.3 Unsupported commands

KEYS, MOVE, OBJECT, RENAME, RENAMENX, SORT, SCAN, BITOP,MSETNX, BLPOP, BRPOP, BRPOPLPUSH, PSUBSCRIBE，PUBLISH, PUNSUBSCRIBE, SUBSCRIBE, UNSUBSCRIBE, DISCARD, EXEC, MULTI, UNWATCH, WATCH, SCRIPT EXISTS, SCRIPT FLUSH, SCRIPT KILL, SCRIPT LOAD, AUTH, ECHO, SELECT, BGREWRITEAOF, BGSAVE, CLIENT KILL, CLIENT LIST, CONFIG GET, CONFIG SET, CONFIG RESETSTAT, DBSIZE, DEBUG OBJECT, DEBUG SEGFAULT, FLUSHALL, FLUSHDB, INFO, LASTSAVE, MONITOR, SAVE, SHUTDOWN, SLAVEOF, SLOWLOG, SYNC, TIME

/CodisLabs/codis

/CodisLabs/codis/blob/master/doc/tutorial_zh.md

4.3 predixy

Before redis 3.0 introduced redis clusters, the proxy layer implementation of redis clusters was the preferred solution, twemproxy and codis are the two most common proxies . However, there are too many redis features that Twemproxy does not support, such as list of blocking commands, things, publish-subscribe, etc., and there is no direct support for high availability of redis.

4.3.1 Working mechanisms

predixy supports both Redis Sentinel and Redis Cluster.

• The backend is a set of Redis monitored by Redis Sentinel, which is functionally equivalent to the original Redis.

• If the backend is a multi-group Redis monitored by Redis Sentinel, then some of the functionality is limited.

• The backend is a Redis Cluster, which is functionally equivalent to a Redis Cluster.

4.3.2 Characteristics

• High performance and lightweight

• Multi-threading support

• Multi-platform support: Linux, OSX, BSD, Windows

• Support for Redis Sentinel, can be configured with one or more groups of redis

• Support for Redis Cluster

• Support for redis blocking commands including blpop, brpop, brpoplpush

• The scan command is supported for both single redis and multiple redis instances.

• Multi-key command support: mset/msetnx/mget/del/unlink/touch/exists

• Support for multiple databases in redis, i.e. you can use the select command

• Transaction support is currently limited to a single redis group under Redis Sentinel.

• Support for scripts, including commands: script load, eval, evalsha

• Support for publish-subscribe mechanism, i.e. Pub/Sub series of commands

• Multi-data center support, read/write separation support

• Extended AUTH commands, powerful read, write, and administrative privilege control mechanisms, and robust space limiting mechanisms

• Logs can be sampled and output by level, asynchronous logging to avoid thread blocking by io.

• Log files can be automatically sliced by time and size

• Rich statistical information, including CPU, memory, request, response, etc.

• Latency monitoring information, you can see the overall latency, sub-backend redis instance latency

---