[NOSQL] About Redis

Redis Overview

Redis was developed by Salvatore Sanfilippo in 2009 for its start-up company Lloogg, and is still a standalone project, but VMware likes the project (the author is its employee). It is implemented in C language, so it performs well. Use a BSD license that uses key-value storage, similar to Amazon Dynamo,cassandra,riak,voldemort,memcache. Support for rich data types, such as arrays, lists, collections, etc., is ideal for Web services that need to express timelines, such as Weibo.

The data types supported by Redis are:

• String
  
• Linked list
  
• Collection
  
• Ordered collection
  
• Hash table
  

Redis's master-slave replication Redis comes with a master-slave copy, as long as you set the slaveof option for the profile redis.conf, as follows:

High availability for Redis

So far, the official Redis is still developing redis-cluster, can refer to Http://redis.io/topics/cluster-spec, Chinese version http://www.cnblogs.com/chang290/ Archive/2012/09/05/2672506.html

But we can use the Keepalived+redis method to achieve high availability, as follows:

1. Configuration of Redis
Host Port role
REDIS0 6379 Master
Redis1 6379 Slave

2. Configuration of the Keepalived
Redis0 and Redis1 use a virtual IP

and use the following script to monitor if the Redis service is alive:

#!/bin/bash/usr/local/bin/redis-cli-h 192.168.1.53-p 6379 Info >/dev/nullif [$?-eq 0]; Then        echo "Redis OK"        exit 0else        echo "No Redis service found!"        /usr/local/bin/redis-server/path/to/redis.conf        # Try to start it again        /usr/local/bin/redis-cli-h 192.168.11.53-p 6380 Info >/dev/null        if [$?-eq 0]; then                exit 0        Else                # restart failed                Killall Keepalived                echo "Error"        Fifi

To implement a Redis failback, you can use the Notify_master of the keepalived configuration to notify_backup both methods to execute a specific script. In fact, as long as there are 2 scripts on slave (that is, REDIS1), the first one is to execute slaveof no one after Redis1 takes over the virtual IP to become master. The second is after the redis1 hand over the virtual IP, the REDIS0 executes slaveof no one to ensure REDIS0 recovery-oriented state, and Redis1 slaveof 6379 start to re-sync data from master. If you are already a slave, there is no need to sync.
Redis1 on the Keepalived configuration method as follows, redis0 as long as remove Notify_master, notify_backup two lines can be.

! Configuration File for keepalivedglobal_defs {router_id redis1}vrrp_script monitor_redis {script '/opt/redis_ keepalive.sh "Interval weight 2}vrrp_instance" state Buckup # (host is master, backup is Backup) interface eth0 # (HA monitoring network interface) VIR TUAL_ROUTER_ID 110 # (master, standby virtual_router_id must be the same) Mcast_src_ip 192.168.11.53 # (Multicast source IP, set to native extranet IP, same network card as VIP) This key is not set Priority 70 # (master, standby to take different priorities, host value is large, the backup machine value is small, the higher the value of the higher priority) Advert_int 1 # (VRRP multicast broadcast cycle seconds) authentication {  ...} notify_master/opt/redis_2master.sh notify_backup/opt/redis_2backup.sh Track_script {Monitor_Redis # (call Nginx process detection script) } virtual_ipaddress {192.168.11.4 # (VRRP ha virtual address)}}

Redis's persistent Redis has the following 2 types of persistence mechanisms:

• Snapshot (snapshot)
  
• AOF (Append only File)
  

The Redis snapshot feature is configured as follows:

The Redis snapshot principle is as follows:

• Redis uses the copy on write mechanism of the fork command. When a snapshot is generated, the current import thread is forked out of a subprocess, and then all the data is looped in the child import process, and the data is written as an RDB file.
  
• Redis's original Rdb file does not break because its write operation is import line in a new import, when a new, RDB file is generated, the Redis-generated sub-import process writes the data to a temporary file and then renames the temporary file to an Rdb file by means of an atomic rename system call. This way, when anything fails, Redis's RDB files are always available.
  
• At the same time, Redis's Rdb file is also a part of the Redis master-slave synchronization implementation.
  
• We can clearly see that the RDB has its shortcomings, that is, once the database has a problem, then the data stored in our Rdb file is not entirely new, from the last Rdb file generation to the Redis outage time of the data are all discarded. In some businesses, this is tolerable, and we recommend that these services be persisted using an RDB, because the cost of opening an RDB is not high.
  

The configuration of the AOF is as follows:

AOF takes precedence over an RDB (that is, a snapshot), and the RDB performs better than aof because there is no duplication.
AOF Rewrite: Regenerate a copy of the AOF file, one record in the new AOF file will only happen once, and unlike an old file, multiple operations on the same value may be logged. Its build process is similar to an RDB, and it also fork a process, traversing the data directly, and writing a new aof temporary file. In the process of writing a new file, all of the write logs are still written to the old aof file and are also recorded in the memory buffer. When the completion of the operation completes, logs from all buffers are written to the temporary file once. Then call the atomic Rename command to replace the old aof file with the new AoF file.