redis learning (a) - master-slave architecture to achieve high concurrency principle

Several principles: the principle of master-slave replication, sentinel principle, cluster model works
redis achieve high concurrency mainly depends on master-slave architecture , a master multi-slave. From the master to availability, we should add guards , may be implemented, any instance down, the switchover can be performed. After high concurrency availability want to accommodate big data, to redis clusters
Sentinel: Sentinel cluster
redis clusters: redis clusters

First, the main presentation copy from theory

1.1, master-slave replication principle
(1) master-slave structure : master and slave (master-slave) architecture, a master multi-slave, the master database is responsible for writing and copying data to other  slave  nodes; read from the database is responsible to achieve the database read write separation . This horizontal expansion of the support high concurrency read.

(Note: redis only inside a multi-master from, not from multiple multi-master)

(2) from the master copy core mechanism (redis replication)
using asynchronously copy data to the slave node , a master node may be configured from a plurality of nodes, from nodes can also be connected to other nodes and will not be interrupted from the master node when it is copied, it will not break the query operations on its own, it provides a service with old data set, copy after deleting old data set to load new data set, then will suspension of foreign service.

From the master copy application scenarios: cluster, separate read and write, log backup, high availability
(3) from the core principle of the master copy of
the sub-server from the primary server and the server , when starting from a node when it sends a  PSYNC  command to the master node;

If this is the first time the connection will trigger a full resynchronization full volume copy, this time master starts a background thread to generate a snapshot file RDB, while all write commands from the client receives the cached in memory;

RDB generate complete master node will send it to slave, slave would first written to the local disk and then loaded from the local disk to memory , and then write command to the slave master-memory cache, slave will synchronize data;

(Note: If there is a fault with the main network node will automatically reconnect the disconnected from the node, connected to the rear major node to copy only the missing data from the node)

Detailed process :

(1) when starting from a database, the master database sends the sync command ; 

(2) After receiving the master database sync command, the snapshot in the background begins (operation performed RDB), and saves the received command is saved during the snapshot;

(3) When the snapshot is complete, redis the snapshot file and send all commands to the cache from the database;

(4) received from the database, the snapshot will load and execute the file cache commands received.

1.2, the main questions copied from 

(1) HTTP:

Master node maintains a backlog in memory, master and slave keeps a copy of the offset and the main run id, offset stored in the backlog, if let off the network slave master copy from the last copy of the offset, if not find the offset amount is to conduct a full copy
(2) expired key process:

slave does not expire key, just wait for the expired master key, if an expired master key, or by LRU out of a key, it will simulate a del command to the slave.

1.3, three types of replication

(1) the total amount of copy:

master execution bgsave, rdb generate a snapshot file locally and then sent from the node, if rdb copy for more than 60s, then the node would think from the write command in the cache memory when execution fails, the master node generates rdb, from the node after saving rdb, then the new write command to copy from the node, the node receives from rdb empty your old data is then loaded into memory rdb, and provide services based on the old version of the data
(2) incremental copy:

The full amount of the copy process interrupted network, incremental replication is triggered when the slave reconnect master, master to obtain partial loss of data directly from their backlog to send to the slave node.
From the master node will send heartbeat messages to each other, the master node every 10 seconds by default send a heartbeat from the node sends a heartbeat every 1 second
(3) asynchronous replication:

After each master write command is received, the first internal write data, and to send an asynchronous slave node

1.4, configure the master-slave replication: is the configuration from the server

修改从Redis从配置文件：
修改slave从redis中的 redis.conf文件
slaveof 192.168.33.130 6379  
masterauth 123456--- 主redis服务器配置了密码,则需要配置
一主多从如何实现 

 

Two, Linux installed under Redis

下载Redis安装包
wget http://download.redis.io/releases/redis-3.2.9.tar.gz
解压Redis安装包
tar -zxvf redis-3.2.9.tar.gz
安装
cd redis-3.2.9
Make
Cd src
make install PREFIX=/usr/local/redis
移动配置文件到安装目录下
cd ../
mkdir /usr/local/redis/etc
mv redis.conf /usr/local/redis/etc

配置redis为后台启动
vi /usr/local/redis/etc/redis.conf //将daemonize no 改成daemonize yes
vi /usr/local/redis/etc/redis.conf // requirepass 123
开启redis
/usr/local/redis/bin/redis-server /usr/local/redis/etc/redis.conf 

连接Redis客户端

./redis-cli -h 127.0.0.1 -p 6379 -a "123456" 
PING 结果表示成功


关闭防火墙


//临时关闭
systemctl stop firewalld
//禁止开机启动
systemctl disable firewalld
Removed symlink /etc/systemd/system/multi-user.target.wants/firewalld.service.
Removed symlink /etc/systemd/system/dbus-org.fedoraproject.FirewallD1.service.


停止Redis服务
./redis-cli -h 127.0.0.1 -p 6379 -a "123456"  shutdown
修改redis.conf
注释掉
#bind 127.0.0.1 开启外网访问