Redis (2) Basic Introduction to Redis (Linux)

1.memcached vs. Redis

Memcahced has only one string data structure, and Redis has 5 kinds of data data storage, Memcahced has the method of Redis basic all have, and Redis code is more concise, more readable, more maintenance, performance is basically similar, Redis supports persistence, and memcache itself does not support persistence.

2.redis data Types and APIs

String,list,set,hash,zset

Redis API

http://redisdoc.com/

Note: incr, Decr,incrby,decrby is an atomic operation

3. General Command:

Tab: Fill command

Redis-server redis.conf;//to start the server by the specified configuration file

Redis-cli-p 6379;//-h no write default is localhost,-p port, start client

redis-check-aof aof filename;//aof file repair, here you need to compare the differences with the original file using the diff command

Redis-check-rdb rdb filename;//rdb file repair, here you need to compare the differences with the original file using the diff command

Config set configuration file parameters;//Modify configuration parameters

Config get configuration file parameters;//Get Configuration parameters

Redis-benchmark-h ip-p port-c number-n number//redis performance test

Redis-benchmark parameter Description: http://www.runoob.com/redis/redis-benchmarks.html

4. Common commands after logging in to the client

Clear: Clear screen;

Flushdb: Empty the current library and persist the data;

Flushall: Clears all libraries and persists the data;

Shutdown: Persisting data and closing the session

Exit: Persist the data and exit;

Save: Persist data, synchronize blocking, ensure data security;

Bgsave: Snapshots are asynchronous and can be lastsave to get the time of the last saved snapshot, ensuring efficiency

Select library//Switch library

Dbsize//View the size of the key for the current library

5. Set password//generally not necessary, because he is not doing safe

Get password: config get requirepass//default no password

Set Password: Config set requirepass 12345678

Login: auth Password

Description in the Redis configuration file

6. The CAP principle in distributed

C:consistency (Strong consistency)

A:availability (availability)

P:partition tolerance (partition fault tolerance)

Selection principle

Because the current network hardware is bound to have problems such as delayed packet loss, partition tolerance is something we have to implement. Selection of most site architectures for APS, CA traditional Oracle Database

7.redis Persistent aof and RDB

1) The persistence of the RDB

The configuration in Redis is set up as follows:

The Bgsave command is executed as long as any one of the following three conditions is met

Server within 900 seconds, the database has been modified at least 1 times;
Server within 300 seconds, the database has been modified at least 10 times;

The server changed the database at least 10,000 times within 60 seconds.

2) AoF Persistence

AppendOnly no;//default is off, turn on set to Yes

Appendfilename appendonly.aof;//default aof file name

Appendfsync everysec;//Default Write policy

The parameters are as follows

No: Indicates that the data cache of the operating system is synchronized to disk (fast)

Always: Represents a manual call to Fsync () to write data to disk (slow, secure) after each update operation

Everysec: Indicates one time per second (tradeoff, default value)

Note: No too slow, always too fast system prone to collapse

3) Comparison of RDB and AOF

The RDB recovers large datasets faster than AOF, and the RDB is much smaller than the aof file, with a failed shutdown aof less data than the RDB loses

4) AoF principle of rewriting:

When the aof file reaches a certain value (64m,auto-aof-rewrite-percentage 100 is the default in the configuration file,

Auto-aof-rewrite-min-size 64MB), fork out a new process to rewrite the file (write the temporary file first, then delete the original file, then rename), traverse the new process's in-memory data, rewrite the aof file, and optimize the file size ( The first number of sets or incr, and so on, and finally only a bit, a key and a value, a set statement), and did not read the old aof file, the entire in-memory database content with a command to rewrite a new aof file, which is a bit similar to the snapshot.

Note: RDB and aof error after the repair has been written, generally two are open, if flush, then you can open the corresponding aof file, delete Flush statement reload can be repaired, but after rewriting aof cannot recover, aof file takes precedence over RBD file load.

8.Redis of transactions

1) API

Open things Multi

Cancel transaction: Discard

The monitoring is canceled regardless of failure or success after submitting the thing EXEC//commit

Monitoring: Watch

Un-monitoring: unwatch//Cancel all monitoring

2) Rollback

After you open the transaction before the exec error, then all rollback, if the error after the exec, then the error-prone statement continues execution, does not rollback

127.0.0.1:6379> multiok127.0.0.1:6379> set K1  v1queued127.0.0.1:6379> getset K2 (Error) ERR wrong number of Arguments for ' getset ' command127.0.0.1:6379> exec (Error) Execabort Transaction discarded because of previous errors.1 27.0.0.1:6379> get K1 (nil)

127.0.0.1:6379> multiok127.0.0.1:6379> set K1 v1queued127.0.0.1:6379> incr k1queued127.0.0.1:6379> exec1) OK2) (Error) ERR value is not a integer or out of range127.0.0.1:6379> get K1 "v1"

3) Watch and Unwatch

Watch instruction, like optimistic lock, when a transaction commits, if the value of key has been changed by another client, the whole transaction queue will not be executed, and the watch command monitors multiple keys before the transaction is executed, if the value of any key has changed before multi after watch. The transaction executed by the EXEC command is discarded, and the nullmulti-bulk answer is returned to inform the caller that the transaction execution failed.

Client 1//success story 127.0.0.1:6379> set K1 1000ok127.0.0.1:6379> set K2  0ok127.0.0.1:6379> WATCH k1ok127.0.0.1 :6379> multiok127.0.0.1:6379> Decrby K1 500queued127.0.0.1:6379> incrby K2 500queued127.0.0.1:6379> exec1) (integer) 5002) (integer) 500

Client 1//before multi, the data is changed after watch, so the content in multi is invalid 127.0.0.1:6379> set  k1 1000ok127.0.0.1:6379> set  K2 0ok127.0.0.1:6379> WATCH  k1ok127.0.0.1:6379> set  k1 500ok127.0.0.1:6379> MULTI ok127.0.0.1:6379 > Decrby K1 500queued127.0.0.1:6379> incrby  K2 500queued127.0.0.1:6379> exec (nil) 127.0.0.1:6379> get K1 "500"

Client 1//normal walk 127.0.0.1:6379> set  K1 1000ok127.0.0.1:6379> set  K2 0ok127.0.0.1:6379> WATCH  k1ok127.0.0.1:6379> MULTI ok127.0.0.1:6379> decrby K1 500queued127.0.0.1:6379> INCRBY  K2 500queued127.0.0.1:6379> exec (nil) 127.0.0.1:6379> get K1 "2000"

The client 2//setting value, which causes the above failure set K1  2000

Note:

Separate quarantine operation: All commands in a transaction are serialized and executed sequentially. The transaction is not interrupted by a command request sent by another client during execution. There is no concept of isolation level: a command in a queue is not actually executed until it is committed, because any instruction before the transaction commits is not actually executed and does not guarantee atomicity: Redis in the same transaction, if one of the commands fails, the subsequent command will still be executed without rollback.

Pessimistic lock: Think that others are not safe for themselves, the entire corresponding space is locked up, such as table locks, write locks, etc.

Optimistic lock: Think that others are safe for themselves, similar to the row lock, add a version number after the modification line, for example, when the version is 1, two people are at the same time which data, almost time to commit, when someone commits, becomes 2, and then after the submission of the version with the current version of the conflict, the need to resolve post-conflict

9.redis Release Subscriptions

Slightly, basically not used, because essentially all use ACTIVEMQ

10. Master-slave replication//advantages: Read/write separation, disaster recovery

1) file configuration (one Master two servants)

Configuration to be modified (port and file address)

Port

Pidfile

LogFile

Dbfilename

Appendfilename (need to change after opening aof)

2) 1 is the main 2,3 from

Main//info replication

From//slaveof 127.0.0.1 6379, another from a similar

Note: Can only write, never write, the Lord has fallen, two servants or two servants, the Lord is still the Lord after returning

3) Legend of Fire

The other hangs on one from the top, but is mounted from, or from

Note: The Lord has fallen, the servant or the servant, the Lord is still the Lord when he returns.

4) His new//slaveof no one

Note: His new the heel of the Lord is okay.

4) Sentinel Mode

Configuration file

New sentinel.conf file, the name must not be wrong, the contents of the file

Sentinel Monitor MyMaster 127.0.0.1 6379 1//MyMaster hostname who can take, IP, prot, poll number

Sentinel Down-after-milliseconds MyMaster 5000//configuration how long to detect once, default 30 seconds, here configure 5 seconds
Sentinel Failover-timeout MyMaster 900000
Sentinel Parallel-syncs MyMaster 2

Start Redis-sentinel sentinel.conf file path

Note: After the main drop line, from the machine to vote, in the slave automatically select the host, the main back to the machine

Redis (2) Basic Introduction to Redis (Linux)