Redis Cluster
Introduction
1. Stand-alone, single instance of persistent manner
In our previous lessons, I built a stand-alone, single-process cache redis. We use rdb, aof persistence, to ensure data security.
rdb（relation-ship database）持久化：
默认redis会以一个rdb快照的形式，将一段时间内的数据持久化到硬盘，保存成一个dumpr.rdb二进制文件。
工作原理：当redis需要持久化时，redis会fork一个子进程，子进程将数据写到磁盘上临时一个RDB文件中。当子进程完成写临时文件后，将原来的RDB替换掉，这样的好处就是可以copy-on-write。
配置redis.conf:
save 900 1
save 300 10
save 60 10000
在900秒内，如果有一个key被修改，则会发起快照保存。300秒之内，如果超过10个key被修改，则会发起快照保存。在60秒内，如果1w个key被修改，则会发起快照保存。
aof（append-only file）持久化：
默认会以一个appendonly.aof追加进硬盘。
redis.conf默认配置:
appendfsync yes
appendfdync always
#每次有数据修改都会写入AOF
appendfsync everysec
#每秒同步一次，策略为AOF的缺省策略2. single node, a single instance of the problems faced:
- Single point of failure
- Limited capacity
- pressure
The face of so many problems, we solve ways that will become a single-node multi-node architecture:
1. separate read and write.
2. Based on the three-dimensional extended AKF.
- The X axis the total amount mirrored replicate site (from the single reservoir to multiple base)
- Y axis business function separation (divide again according to the service logic library)
- Z axis priority logic subdivided (fragmentation single business, such as the MR DataNodes, divides a single service node operation)
3. Several issues facing the cluster:
1. Data Consistency
Component data can not guarantee the same, if the guarantee agreement, it will be lost availability. If we are to ensure strong data consistency, then we will destroy availability (data in sync, can not remain available).
2. Data Integrity
We guarantee consistent weak, may get the wrong data.
3. Data eventual consistency
Our price architecture shown in Figure 3, in the middle of putting a similar middleware kafka like, then we can guarantee eventual consistency. (Kafka through a certain technology becomes reliable)
4. distributed a few common architecture:
Standby architecture: the host is dead, the backup machine can top
Copy the master: Several back from the host node. (Redis using a master-slave replication)
Master-slave replication architecture, also facing a problem, how to solve a single point of failure?
We were on the main HA architecture, with a monitoring program, the monitoring program, in order to avoid a single point of failure, it must also be a cluster architecture.
Our monitoring equipment must be odd units, were more than half of the election, if more than half of all electoral failure, then will jump to another node.
Configuration
1. Extract
Redis preparation of a tar package, decompress.
2. Start node and follow
Start three instances, be used to follow the master node replicaof ip port command from the node.
(Note that before redis 5, we can follow the Lord by slaveof node, but from then redis5, replicaof be changed to follow)
3. Use the append mode
When opened, use appendonly yes this configuration, perform additional way to write the cluster.
Dump.rdb full backup are useful when the master node can follow
Appendonly using incremental backup, it is unable to follow the master node
4. Master hook
The master node manually hook
Slave node may become a master node, a command directly replicaof no one
sentinel
1. Start 3 Sentry, monitoring
Command is:
1.redis-server ./26379.conf --sentinel
2.也可以直接启动redis-sentinelport 26379
sentinel monitor mymaster 127.0.0.1 6379 226379.conf file only 2 lines
The second line semantics: Sentinel surveillance ip port monitor name a few votes
Sentinel needs 30 seconds to take effect