安装redis：Rdis专题目录

搭建步骤

1. 复制 redis.conf文件 => redis-6380.conf 。
2. 将上述复制的文件修改如下配置：
   a. 端口号：port 6380
   b. pidfile /var/run/redis_6380.pid #吧pid进程号写入pidfile配置的文件
   c. logfile “6380.log”
   d. dir /usr/local/redis/data/6380 #指定数据存放目录
3. 配置主从复制
   a. replicaof 127.0.0.1 6379 #从本机6379的redis实例复制数据.redis5.0之前使用slaveof
   b. replica-read-only yes #配置从节点只读
4. 启动从节点
   a. /opt/redis/redis-7.0.5/src/redis-server /opt/redis/redis-7.0.5/redis-6380.conf

我们查看一下进程
ps -ef | grep redis

我们在分别连接6379以及6380客户端
/opt/redis/redis-7.0.5/src/redis-cli -p 6379

/opt/redis/redis-7.0.5/src/redis-cli -p 6380

主从复制基本原理

全量复制

1.当从节点6380节点启动之后，会向主节点发送 psync命令同步数据，发送命令之前会会master节点建立socket连接。
2.
- 主节点收到 psync命令直线bgsave生成最新rdb快照数据
- 主节点开始做rbd之后新数据的缓存，一些写命令。
3. 主节点 send rdb数据
4. 从节点清空老数据并加载主节点rdb
5. 主节点发送缓存数据 send buffer到从节点
6. 从节点执行 buffer 里的写命令到内存
7. 主节点通过socket长连接持续把写命令发送给从节点，保证主从数据一致性。

部分复制（断点续传）

如果上述主从从，如果此时我们slave节点宕机了很长一段时间，此时的master节点肯定写入了大量的数据，此时我们重新启动slave节点就不会进行全量复制，而是进行部分复制。

注意： 从上述描述中我们可以发现，从节点在建立连接的时候，主节点会进行一次 bgsave命令，如果此时有大量的从节点，我们会对主节点的服务器造成很大的压力，我们为了缓解这一情况（** 主从复制风暴** ）当存在多个从节点的时候，我们可以做如下设计来进行主从同步：

Redis管道（pipeline）

客户端可以一次性发送多个请求而不用等待服务器的响应，待所有命令都发送完后在发送一次性读取服务的响应，这样可以极大降低多条命令执行的网络开销，管道执行多条命令的网络开销实际上只相当于一次执行的网络开销。需要注意到的是用pipeline方式打包命令发送，redis必须在处理完所有命令前先缓存起所有命令的处理结果。打包的命令越多，缓存消耗的内存也越多，所以并不是打包的命令越多越好。pipeline中发送的每个command都会被server立即执行，如果执行失败，将会子此后的响应中得到信息；也就是pipeline并不是表达“所有command都一起成功”的意思，管道中前面命令失败，后面命令不会有影响，继续执行，也就是说pipeline不具备原子性

如果存在这样的情况，当我们存在有大量的set命令需要去操作redis的时候我们应该怎么样去处理，Redis本身就是基于内存来实现的，一次set命令的消耗我们几乎可以忽略不计，但是如果存在大量的set命令的时候，我们大部分的时间就浪费了在建立连接的这个消耗上，此时我们可以通过管道来实现。

简单的可以的将管道理解为，一堆命令的集合，redis可以同时接收多个命令去操作：

 JedisPoolConfig jedisPoolConfig = new JedisPoolConfig();jedisPoolConfig.setMaxTotal(20);jedisPoolConfig.setMaxIdle(10);jedisPoolConfig.setMinIdle(5);JedisPool jedisPool = new JedisPool(jedisPoolConfig, "127.0.0.1", 6379, 3000,null);Jedis jedis = jedisPool.getResource();
for (int i = 0; i < 10; i++) {pl.incr("num");pl.set("zhangsan" + i, "zhangsan");}
List