文章目录
单点问题
分布式系统中，涉及到一个非常关键的问题：单点问题
某个服务器程序，只有一个节点（只搞一个物理服务器，来部署这个服务器程序）。这就可能会遇到一些问题：
- 可用性问题。如果这个机器挂了，意味着服务就中断了
- 性能/支撑的并发量也是比较有限的
引入分布式系统，主要也就是为了解决上述的单点问题
什么是主从复制
在分布式系统中，往往希望有多个服务器来部署 redis 服务器，从而构成一个 redis 集群。此时就可以让这个集群给整个分布式系统重其他的服务，提供更稳定/更高效的数据存储功能
在分布式系统重，希望使用多个服务器来部署 redis，存在以下几种 redis 部署方式：
- 主从模式
- 主从+哨兵模式
- 集群模式
主从模式：
在若干个 redis 节点中，有的是"主节点"，有的是"从节点"。假设有三个物理服务器（称为三个节点），分别部署了一个 redis-server 进程
此时就可以把其中的一个节点，作为"主节点"，另外两个节点作为"从节点"。
- 从节点得听主节点的（从节点上的数据要跟随主节点变化；从节点的数据要和主节点保持一致）
- 本来，在主节点上保存一堆数据，引入从节点后，就是要把主节点上面的数据，复制出来放到从节点中。后续，主节点这边对于数据有任何修改，都会把这样的修改给同步到从节点
- 从节点就是主节点的副本
redis 主从模式中，从节点上的数据不允许被修改，只能读取数据
主从模式能解决的问题
并发量有限
- 由于从节点的数据都是时刻和主节点保持一致的，所以其他的客户端从从节点读取数据，和从主节点这里读取数据，是没有区别的
- 后续如果有客户端来读取数据了，就可以从上述节点中，随机挑一个节点，给这个客户端提供读取数据的服务
- 引入了更多的计算资源，自然能够支撑的并发量也就大幅提高了
可用性问题
之前只是单个 redis 服务器节点，此时这个机器挂了，整个 redis 就挂了
- 上述这个主从结构，这些
redis的机器不太可能"同时挂了"
但是整个机房，是否可能被一锅端了？（也是可能存在的）
-
这个时候如果考虑到更高的可用性，就可以把这些机器放到多个不同的机房中（异地多活）
-
如果是挂掉了某个从节点，没什么影响。此时继续从主节点或者其他从节点读取数据，得到的效果完全相同
-
如果挂掉了主节点，还是有一定影响的。从节点只能读取数据，如果需要写数据，就没得写了
可用性是提高了，但还是没有到非常理想的程度
我们可以弄多个主节点吗？
- 一山容不得二虎
- 如果存在两个主节点，相互之间如何同步数据，是个麻烦事
更准确的说，主从模式，主要是针对"读操作"进行并发量&可用性的提高。而写操作的话，无论是可用性还是并发，都是非常依赖主节点，主节点又不能搞多个。实际业务场景中，读操作往往就是比写操作更加频繁
主从结构，是分布式系统中比较经典的一种结构。不仅仅
redis支持，MySQL也支持
配置
建立复制
配置 redis 主从结构，首先需要启动多个 redis 服务器。正常来说，每个 redis 服务器程序，应该在一个单独的主机上（才是分布式）
没有多个服务器，我们可以在一个服务器上，运行多个 redis-server 进程
- 我们要保证
redis-server的端口是不同的 - 默认端口为：
6379，此时就不能让新启动的redis-server再继续使用6379了
如何去指定 redis-server 的端口呢？
- 可以在启动程序的时候，通过命令行来指定端口号。
-port选项 - 也可以直接在配置文件中，来设定端口
通过配置文件来指定端口
此处我们准备搞一个主节点，两个从节点
slave1是从节点 1，配置文件设置的6380slave2是从节点 2，配置文件设置的6381redis是主节点，端口为6379
从节点的配置文件都是复制的主节点的，只是把端口号改了。还需要把守护模式设为yes（daemonize yes）
- 此时就可以看到启动了三个服务器（一主两从）
- 但此时这几个节点还未构成主从结构，而是各自为政。要想成为主从结构，还需要进一步的进行配置
配置主从
要想配置成主从结构，就需要使用 slaveof
- 在配置文件中加入
slaveof {masterHost} {masterPort}随Redis启动生效 - 在
redis-server启动命令时加入--slaveof {masterHost} {masterPort}生效 - 直接使用
Redis命令：slaveof {masterHost} {masterPort}生效
一般是使用配置文件更多，修改配置文件是一直持久生效的，重启后也能用
直接加上相关信息：
Redis服务器的配置文件改完之后，要重启服务器
主从结构配置好之后，我们看一下网络状态
- 主节点随时修改，从节点能立即感知到
- 但是从节点不能改，只能读
查看集群结构
使用：
redis
info replication
offset- 主节点上会收到源源不断的"修改数据"请求，从节点就需要从主节点这里同步这些修改请求
- 从节点和主节点之间的数据同步，不是瞬间完成的
offset就相当于是从节点和主节点之间，同步数据的进度
lag- 表示延迟，单位为复制日志的条目数。
connected slaves- 从节点下面还可以接从节点
断开复制
直接使用 slaveof no one 这个命令，来断开现有的主从复制关系 
- 从节点断开主从关系，它就不再从属于其他节点了，里面已经有的数据，是不会抛弃的
- 但后续主节点再针对数据进行修改，从节点就无法再自动同步数据了
但是重启服务器之后，还是会回到之前一主两从的结构，因为配置文件里面是这样设置的
特点
安全性
对于数据比较重要的节点，主节点会通过设置 requirepass 参数进⾏密码验证，这时所有的客⼾端访问必须使⽤ auth 命令实⾏校验。
从节点与主节点的复制连接是通过⼀个特殊标识的客⼾端来完成，因此需要配置从节点的 masterauth 参数与主节点密码保持⼀致，这样从节点才可以正确地连接到主节点并发起复制流程。
只读
默认情况下，从节点使⽤ slave-read-only=yes 配置为只读模式。
由于复制只能从主节点到从节点，对于从节点的任何修改主节点都⽆法感知，修改从节点会造成主从数据不⼀致。所以建议线上不要修改从节点的只读模式。
传输延迟
主节点和从节点之间通过网络（TCP）来传输。TCP 内部支持了 nagle 算法（默认开启）
- 开启了，就会增加
TCP的传输延迟，节省了网络带宽 - 关闭了，就会减少
TCP的传输延迟，增加了网络带宽 - 目的和
TCP的捎带应答是一样的，针对小的TCP数据报，进行合并，从而减少包的个数（等待合并的时候就会耗时）
repl-disable-tcp-nodelay 参数就可以用于在主从通信过程中，关闭 TCP 的 nagle 算法，从而减少传输延迟，不过会增加网络带宽
- 从节点更快的和主节点进行同步
- 一般游戏开发，有其是及时性要求很高的（
fps、moba...）都要关闭nagle算法