Redis Basic Configuration Detailed _redis configuration

Transaction processing of Redis

As we all know, business refers to "a complete action, or all the implementation, or nothing to do."

Before talking about Redis transaction processing, we must first introduce four Redis instructions, namely multi, EXEC, discard, WATCH. These four directives form the basis of REDIS transaction processing.

1.MULTI is used to assemble a transaction;
2.EXEC is used to perform a transaction;
3.DISCARD is used to cancel a transaction;
4.WATCH is used to monitor some keys, and once they are changed before the transaction is executed, the execution of the transaction is canceled.

On paper, let's take a look at a multi and exec example:
Copy code code as follows:
Redis> MULTI//Mark Transaction start
Ok
redis> INCR user_id//multiple commands in sequence
QUEUED
Redis> INCR user_id
QUEUED
Redis> INCR user_id
QUEUED
Redis> PING
QUEUED
Redis> EXEC//Executive
1) (integer) 1
2) (integer) 2
3) (integer) 3
4) PONG

In the above example, we see the typeface of queued, which means that when we assemble the transaction with multi, each command is cached in the memory queue, and if queued indicates that the command was successfully inserted into the cache queue, when the exec is executed in the future, These queued commands are assembled into a single transaction to execute.

For the execution of a transaction, if the Redis turns on aof persistence, then once the transaction is successfully executed, the commands in the transaction are written to disk at once, and if there are problems with power outages, hardware failures, and so on while writing to disk, Then there is the possibility that only some of the commands are aof persisted, and then the aof file will be incomplete, and then we can use the Redis-check-aof tool to fix the problem, which will remove the incomplete information from the AoF file and ensure that the AoF file is fully available.

For a transaction, you will often encounter two types of errors:

1. Errors prior to calling exec
2. Invoke the error after exec

"Errors prior to calling exec" may have been caused by incorrect syntax or, possibly, due to insufficient memory. Whenever a command fails to write to the buffer queue, Redis records that Redis will refuse to perform the transaction when the client invokes exec. (This is the policy after version 2.6.5.) In the previous version of 2.6.5, Redis would ignore those commands that failed to join the team and only execute those commands that were successful on the team. Let's look at an example of this:
Copy code code as follows:
127.0.0.1:6379> Multi
Ok
127.0.0.1:6379> haha//an obvious wrong instruction
(Error) ERR unknown command ' haha '
127.0.0.1:6379> Ping
QUEUED
127.0.0.1:6379> exec
Redis mercilessly rejected the execution of the transaction because "an error occurred before"
(Error) Execabort Transaction discarded because of previous errors.

With "Invoke exec error", Redis takes a completely different strategy, that is, Redis ignores the errors and continues to execute the other commands in the transaction down. This is because the application-level error is not a problem that Redis itself needs to consider and handle, so if a single command fails in a transaction, it does not affect the execution of the other commands that follow. Let us also take a look at an example:

Copy code code as follows:
127.0.0.1:6379> Multi
Ok
127.0.0.1:6379> Set age 23
QUEUED
Age is not a collection, so the following is an apparently incorrect instruction
127.0.0.1:6379> Sadd age 15
QUEUED
127.0.0.1:6379> Set Age 29
QUEUED
127.0.0.1:6379> exec//execute transaction, Redis ignore the 2nd instruction execution error
1) OK
2) (Error) Wrongtype Operation against a key holding the wrong of value
3) OK
127.0.0.1:6379> Get Age
"29"//You can see that the 3rd instruction was executed successfully.

Well, let's say the last instruction, "WATCH," is a very useful instruction that can help us achieve an effect similar to "optimistic lock", that is, CAS (check and set).

Watch itself is the role of "monitoring key has been changed", but also to support the monitoring of multiple keys at the same time, as long as not really trigger the transaction, watch will be responsible for monitoring, once found that a key has been modified, in the executive Exec will return nil, indicating that the transaction can not trigger.
Copy code code as follows:
127.0.0.1:6379> Set age 23
Ok
127.0.0.1:6379> Watch age//Start monitoring age
Ok
127.0.0.1:6379> set age 24//before Exec, the age value was modified
Ok
127.0.0.1:6379> Multi
Ok
127.0.0.1:6379> Set age 25
QUEUED
127.0.0.1:6379> Get Age
QUEUED
127.0.0.1:6379> exec//trigger EXEC
(nil)//transaction cannot be executed

Redis Configuration – Introduction

We can specify the configuration file that should be loaded when Redis-server is started, as follows:
Copy code code as follows:
$./redis-server/path/to/redis.conf

Next, we'll explain the implications of the various configuration items for the Redis configuration file, and note that this article is based on the redis-2.8.4 version.

Redis official redis.conf file, 700+ line, where more than 100 acts of effective configuration lines, the other 600 more behavior annotation description.

At the beginning of the configuration file, you first identify some units of measure:
Copy code code as follows:
# 1k => 1000 bytes
# 1kb => 1024 bytes
# 1m => 1000000 bytes
# 1mb => 1024*1024 bytes
# 1g => 1000000000 bytes
# 1GB => 1024*1024*1024 bytes

As you can see, the Redis configuration is insensitive to the case of units, 1GB, 1Gb, and 1gB are the same. This also shows that Redis only supports bytes, and does not support bit units.

Redis supports the introduction of external profiles in the master configuration file, much like the include directives in C + +, such as:
Copy code code as follows:
Include/path/to/other.conf

If you've seen the Redis profile, you'll find that it's still very organized. The Redis configuration file is divided into a few large areas, respectively:

1. General
2. Snapshot (snapshotting)
3. Replication (Replication)
4. Safety (Security)
5. Restrictions (Limits)
6. Append mode (append only mode)
7.LUA script (Lua scripting)
8. Slow logs (slow log)
9. Notification of events (event notification)

Let's go through each of these.

"Teach you to understand Redis configuration-General"

By default, Redis is not run in daemon form. By daemonize configuration items, you can control the form of Redis, and if you change to Yes, then Redis will run in daemon form:
Copy code code as follows:
Daemonize No

When run as daemon, Redis generates a PID file, which is generated by default in/var/run/redis.pid. Of course, you can specify where the PID file is generated by Pidfile, for example:
Copy code code as follows:
Pidfile/path/to/redis.pid

By default, Redis responds to connection requests for all available network cards on this computer. Of course, Redis allows you to specify the IP to bind through the BIND configuration entry, such as:
Copy code code as follows:
Bind 192.168.1.2 10.8.4.2

The default service port for Redis is 6379, which you can modify with the port configuration entry. If the port is set to 0, Redis will not listen on the port.
Copy code code as follows:
Port 6379

Some students asked "if Redis do not listen to the port, how to communicate with the outside", in fact, Redis also support the UNIX socket to receive requests. You can specify the path to the UNIX socket file through the Unixsocket configuration entry and specify permissions for the file through Unixsocketperm.
Copy code code as follows:
Unixsocket/tmp/redis.sock
Unixsocketperm 755

When a redis-client has not been requested to send to the server side, the server side has the option to turn the connection on its own initiative, and you can set the idle timeout limit by timeout, 0 to never close.
Copy code code as follows:
Timeout 0

TCP connection Retention policy can be set by tcp-keepalive configuration items in seconds, if set to 60 seconds, The server side initiates an ACK request every 60 seconds to the client that is connected to the idle to check whether the client is dead or not, and closes its connection for the unresponsive client. So it takes a maximum of 120 seconds to close a connection. If set to 0, no live detection is performed.
Copy code code as follows:
tcp-keepalive 0

Redis supports setting the log level by LogLevel configuration entries, divided into four levels, that is, debug, verbose, notice, warning. The
Copy code code is as follows:
loglevel notice

Redis also supports setting the build location of the log files through logfile configuration entries. If set to an empty string, Redis outputs the log to standard output. If you set the log to output to standard output in a daemon case, the log will be written to the/dev/null.
Copy code code as follows:
logfile ""

If you want the log to print to Syslog, it is also easy to control by syslog-enabled. In addition, Syslog-ident allows you to specify log flags in syslog, such as
Copy code code as follows:
Syslog-ident Redis

and also supports the designation of a syslog device. The value can be either user or LOCAL0-LOCAL7. The use of the Syslog service itself can be referenced specifically.
Copy code code as follows:
syslog-facility local0

for Redis, you can set the total number of its databases, if you want a redis to contain 16 databases, set the following:
Copy code code as follows:
Databases

The number of these 16 databases will be 0 to 15. The default database is the database with number 0. The user can use select <DBid> to select the appropriate database.

Redis Configuration – Snapshots

Snapshots, which are primarily concerned with Redis RDB-related configuration, let's take a look.

We can use the following instructions to save data to disk, that is, to control the RDB snapshot function:
Copy code code as follows:
Save <seconds> <changes>

For example:
Copy code code as follows:
Save 900 1//indicates that a persistence is triggered once every 15 minutes and at least 1 key changes are initiated

Save 300 10//indicates that a persistence is triggered once every 5 minutes and at least 10 key changes are initiated

Save 60 10000//indicates that there are at least 10,000 key changes per 60 seconds, triggering a persistent

If you want to disable the RDB persistence policy, you can do so as long as you do not set any save directives, or pass in an empty string parameter to save, like this:
Copy code code as follows:
Save ""

If a user turns on the Rdb snapshot feature, if a failure occurs when Redis data is persisted to disk, Redis will stop accepting all write requests by default. The advantage of this is that it makes it clear to the user that the data in memory and on the disk are inconsistent. If Redis disregard this inconsistency, and continue to receive written requests, it may cause some disastrous consequences.

If the next rdb is persisted successfully, Redis will automatically resume accepting write requests.

Of course, if you don't care about this data inconsistency or if there are other ways to detect and control this inconsistency, you can completely turn off this feature to ensure that Redis continues to accept new write requests when the snapshot write fails. The configuration items are as follows:
Copy code code as follows:
Stop-writes-on-bgsave-error Yes

For snapshots stored on disk, you can set whether to compress storage. If so, Redis will use the LZF algorithm for compression. If you do not want to consume CPU to compress, you can set it to turn off this feature, but the snapshot stored on disk is relatively large.
Copy code code as follows:
Rdbcompression Yes

After the snapshots are stored, we can also have Redis use the CRC64 algorithm for data validation, but doing so increases the performance cost by approximately 10%, and you can turn off this feature if you want to get the maximum performance boost.
Copy code code as follows:
Rdbchecksum Yes

We can also set the name of the snapshot file, which is configured by default:
Copy code code as follows:
Dbfilename Dump.rdb

Finally, you can also set the path for this snapshot file to be stored. For example, the default setting is the current folder:
Copy code code as follows:
Dir./

Redis Configuration – Replication

Redis provides a master-slave synchronization function.

The Slaveof configuration item controls the location of a redis as another redis from the server, by assigning IP and ports to the main Redis. In general, we recommend that users set a cycle of snapshot persistence for different frequencies from Redis, or configure a different service port from Redis, and so on.
Copy code code as follows:
Slaveof <masterip> <masterport>

If the primary redis has a validation password set (using Requirepass), the Masterauth is used to set the checksum password in the configuration from Redis, otherwise the primary Redis rejects the access request from the Redis.
Copy code code as follows:
Masterauth <master-password>

When a connection to the primary Redis is lost from the Redis, or when the master-slave synchronization is in progress, redis how to handle an external access request. Here, there are two options from Redis:

The first option: If Slave-serve-stale-data is set to Yes (the default), the client's read and write requests continue to be answered from Redis.

The second option: If Slave-serve-stale-data is set to No, the request from Redis will return "SYNC with Master in progress" from the client and, of course, with exceptions, when the client sends the info request and the slaveof request, It will be processed from the Redis.

You can control whether a write request can be accepted from Redis. Writing data directly from Redis is generally only applicable to data that is very short in life cycle, because the temporary data is cleaned up when the master-slave synchronization occurs. Since the redis2.6 version, the default is read-only from Redis.
Copy code code as follows:
Slave-read-only Yes

Read-only from Redis is not suitable for direct exposure to untrusted clients. In order to minimize risk, you can use the Rename-command directive to rename some potentially destructive commands to avoid direct calls from outside. Like what:
Copy code code as follows:
Rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52

From Redis will periodically ping the main Redis the package. You can control the cycle by Repl_ping_slave_period instructions. The default is 10 seconds.
Copy code code as follows:
Repl-ping-slave-period 10

During master-slave synchronization, there may be timeouts in these cases:

1. From a redis point of view, when there is a large-scale IO transmission.
2. From a redis point of view, when data transfer or ping, the main redis timeout
3. From the point of view of the primary Redis, when replying to a ping from Redis, timeout from Redis

The user can set the time limit for the above timeout, but make sure that the time limit is larger than the Repl-ping-slave-period value, otherwise each time the primary Redis will assume that the timeout is from Redis.
Copy code code as follows:
Repl-timeout 60

We can control whether Tcp_nodelay is disabled during master-slave synchronization. If Tcp_nodelay is turned on, then the primary Redis uses fewer TCP packets and less bandwidth to