目录
单点问题
如果某个服务器，只有一个节点(只搞一个物理服务器，来部署这个服务器程序)
1.可用性问题，如果这个机器挂了，意味着服务就中断了~
2.性能/支持的并发量也是比较有限的~
引入分布式系统，主要也就是为了解决上述的单点问题~
在分布式系统中，往往希望有多个服务器来部署redis服务，从而构成一个redis集群~，此时就可以让这个集群给整个分布式系统中其他的服务，提供更稳定/更高效的数据存储功能。
在分布式系统中，希望使用多个服务器来部署redis，存在以下几种redis的部署方式~
1.主从模式
2.主从+哨兵模式
3.集群模式
主从模式
在若干个redis节点中，有的是"主"节点，有的是"从"节点.
假设有三个物理服务器(称为是三个节点)
分别部署了一个redis-server进程~
此时就可以把其中一个节点，作为"主节点"
另外两个节点作为"从节点"
从节点，得听主节点的~
由于从节点的数据都是时刻和主节点保持一致的。因此其他的客户端从从节点这里读取数据，和从主节点这里读取数据，没有区别。
后续如果有客户端来读取数据，就可以从上述节点中，随机挑一个节点，给这个客户端提供读取数据的服务~
引入了更多的计算资源，自然能够支撑的并发量也就大幅提高了~
之前只是单个redis服务器节点，此时这哥机器挂了，整个redis就挂了。
如果挂掉了某个从节点，没啥影响，此时继续从主节点或者其他从节点读取数据，得到的效果完全相同！
如果是挂掉了主节点呢？还是有一定影响的！
从节点只能读数据.如果需要写数据，就没得写了。
如何启动多个redis-server
配置redis主从结构，首先需要启动多个redis服务器
正常来说，每个redis服务器程序，应该在一个单独的主机上(才是分布式)
按照后台进程的方式来运行。
当前这几个节点并没有构成主从结构，而是各自为政。要想成为主从结构，还需要进一步的配置。
建立主从关系
要想配置成主从结构，就需要使用slaveof
- 在配置文件中加入slaveof {masterHost} {masterPort} 随Redis启动生效
- 在redis-server启动命令时加入 --slaveof {masterHost} {masterPort} 生效
- 直接使用redis命令：slaveof {masterHost} {masterPort} 生效
此处以6379为主节点，6380和6381为从节点。
redis服务器的配置文件改完之后，就需要重新启动才生效！
主节点这边数据产生任何的修改，从节点就能立即感知到。
就是刚才看到的这些tcp连接起到的效果。
主节点上执行
从节点上执行
offset就相当于是从节点和主节点之间，同步数据的进度~
主节点上会收到源源不断的"修改数据"请求~
从节点就需要从主节点这里同步这些修改请求~
从节点和主节点之间的数据同步，不是瞬间完成的~
断开连接
powershell
slaveof no one直接使用这个命令断开现有的主从复制关系~
从节点断开主从关系，它就不再从属于其他节点了，里面已经有的数据，不会抛弃~
但是，后续主节点如果针对数据做出修改，从节点就无法再自动同步数据了
安全性
对于数据比较重要的节点，主节点会通过设置requirepass参数进行密码验证，这时所有的客户端访问必须使用auth命令实行校验。从节点与主节点的复制连接是通过一个特殊标识的客户端来完成，因此需要配置从节点的masterauth参数与主节点密码保持一致，这样从节点才可以连接到主节点并发起复制流程。
只读
默认情况下，从节点使用slave-read-only=yes配置为只读模式。由于复制只能从主节点到从节点，对于从节点的任何修改主节点都无法感知.修改从节点会造成主从数据不一致。所以建议线上不要修改从节点的只读模式。
传输延迟
主节点一般部署在不同机器上，复制时的网络延迟就成为需要考虑的问题，Redis为我们提高了repl-disable-tcp-nodelay参数用于控制是否关闭TCP_NODELAY，默认为no，即开启tcp-nodelay功能。
拓扑结构
若干个节点之间，按照啥样的方式来进行组织连接~
一主一从
改进办法，当主节点挂了之后，就需要让主节点从从节点这里获取到AOF的文件，再启动~
一主多从
主节点上的数据发生改变，就会把改变的数据同时同步给所有的从节点~
随着从节点个数的增加，同步一条数据，就需要传输多次~
树型结构
主从复制的基本流程
replicationid的作用
redis提供了psync命令，完成数据同步的过程~
psync不需要咱门手动执行
redis服务器会在建立好主从同步关系之后，自动执行psync
从节点负责执行psync.从节点从主节点这边拉取数据~
powershell
PSYNC replicationid offsetreplication复制~
是主节点生成的.
主节点启动的时候就会生成~
（即使是同一个主节点，每次重启，生成的replication id 都是不同的）
从节点和主节点建立了复制关系，就会从主节点这边获取到replication id
info replicaiton 获取到当前replicationid的值~
offset的作用
偏移量
主节点和从节点上都会维护偏移量(整数)
主节点的偏移量，主节点上回收到很多的修改操作的命令~
每个命令都要占据几个字节~
主节点会把这些修改命令，每个命令的字节数进行累加~
从节点的偏移量，就描述了，现在从节点这里的数据同步到哪里了~
replication id 和 offset 共同描述了一个"数据集合"
如果发现两个机器，replication id 一样，offset 也一样，就可以认为这两个redis机器上存储的数据就是完全一样的！！
全量复制和部分复制
psync这里可以从主节点获取全量数据，也可以获取一部分数据。
主要就是看offset这里的进度~
offset写作-1，就是获取全量数据.
offset写具体的正整数，则是从当前偏移量位置来进行获取~
啥时候进行全量复制：
1.首次和主节点进行数据同步
2.主节点不方便进行部分复制的时候
啥时候进行部分复制：
从节点之前已经从主节点上复制过数据了~因为网络抖动或者从节点重启了，
从节点需要重新从主节点这边同步数据，此时看看能不能只同步一部分
全量复制的无硬盘模式
主节点，进行全量复制的时候，也支持"无硬盘模式"
主节点，生成的rdb的二进制数据，不是直接保存到文件中了~而是直接进行网络传输了
从节点之前，也是先把收到的rdb数据，写入到硬盘中，然后再加载~现在也可以省略这个过程，直接b把收到的数据进行加载了
即使引入了无硬盘模式，仍然整个操作时比较重量，比较耗时的.网络传输时没法省的~
相比于网络传输来说，读写硬盘时小头。
关于runid和replid
一个服务器上，replication id 和 run id是都存在的！！两个不同的id，看起来非常像~
主节点
info replication
info server
从节点6380
从节点6381
run id 是每个节点都不相同的.
replid则是具有主从关系的节点，是相同的~
部分复制
从节点要从主节点这里进行全量复制，全量复制，开销是很大的。
有些时候，从节点本身已经持有了主节点的绝大部分数据，这个时候，就不太需要进行全量复制了。
比如，出现网络抖动~主节点这边最近修改的数据可能就无法及时同步过来了
更严重的，从节点已经感知不到主节点了~(进一步的从节点可能会升级成主节点)
网络抖动，一般都是"暂时的"，过一会就恢复了~
此时就可以让从节点和主节点重新建立联系~
当从节点和主节点重新建立连接之后，就需要进行数据的同步~
实时复制
全量复制：从节点刚连上主节点之后，进行的数据初始化工作.
部分复制：全量复制的特殊情况，优化手段，目的和全量复制一样
实时复制：从节点，已经和主节点，同步好了数据了~
但是之后，主节点这边会源源不断的收到新的修改数据的请求.
主节点上的数据就会随之改变。
也需要能够同步给从节点
从节点和主节点之间会建立TCP的长连接~
然后主节点把自己收到的修改数据的请求，通过上述连接，发给从节点
从节点再根据这些修改的请求，修改内存中的数据~
在进行实时复制的时候，需要保证连接处于可用状态~
心跳包机制~
