1. 单机故障
如果发生机器故障，例如磁盘损坏，主板损坏等，未能在短时间内修复好，客户端将无法连接redis。
当然如果仅仅是redis节点挂掉了，可以进行问题排查然后重启，姑且不考虑这段时间对外服务的可用性，那还是可以接受的。而发生机器故障，基本是无济于事。除非把redis迁移到另一台机器上，并且还要考虑数据同步的问题。
2. 容量瓶颈
假如一台机器是16G内存，redis使用了12G内存，而其他应用还需要使用内存，假设我们总共需要60G内存要如何去做呢，是否有必要购买64G内存的机器呢？
3. QPS瓶颈
redis官方数据显示可以达到10w的QPS，如果业务需要100w的QPS怎么去做呢？
关于容量瓶颈和QPS瓶颈是redis分布式需要解决的问题，而机器故障就是高可用的问题了。
2、单机故障解决方法在分布式系统中为了解决单点问题，通常会把数据复制多个副本部署到其他机器（主从模式），满足故障恢复和负载均衡的需求。
redis也是如此，它为我们提供了复制功能，实现了相同数据的多个redis副本（复制功能是高可用redis的基础，哨兵和集群都是在复制的基础上实现高可用的）。
但是这样会有如下问题，多个副本之间的数据如何保持一致呢？数据读写操作可以发送给所有实例呢？
实际上，Redis 提供了主从库模式，以保证数据副本的一致，主从库之间采用的是读写分离的方式。
即：
说明：
在了解 Redis 的主从复制之前，让我们先来理解一下现代分布式系统的理论基石——CAP 原理。
CAP 原理是分布式存储的理论基石：
分布式系统的节点往往都是分布在不同的机器上进行网络隔离开的，这意味着必然会有网络断开的风险，这个网络断开的场景的专业词汇叫做”网络分区“。
在网络分区发生时，两个分布式节点无法进行通信，我们对一个节点进行的修改操作将无法同步到另外一个节点，所以数据的”一致性“将无法满足，因为两个分布式节点的数据不再保持一致。除非我们牺牲”可用性“，也就是暂停分布式节点服务，在网络分区发生时，不再提供修改数据的功能，直到网络状况完全恢复正常再继续对外提供服务。
一句话概括 CAP 原理就是——网络分区发生时，一致性和可用性两难全。
2、Redis主从同步最终一致性Redis 的主从数据是 异步 复制的，所以分布式的 Redis 系统并不满足一致性要求。当客户端在 Redis 的主节点修改了数据后，立即返回，即使在主从网络断开的情况下，主节点依旧可以正常对外提供服务，所以 Redis 满足可用性。
而 Redis 其实是保证 ”最终一致性“，从节点会努力追赶主节点，最终从节点的状态会和主节点的状态保持一致。如果网络断开了，主从节点的数据将会出现大量不一致，一旦网络恢复，从节点会采用多种策略努力追赶上落后的数据，继续尽力保持和主节点一致。
三、主从复制类型 1、主备与主从1. 主备
请求都只能打到Master主节点上，备机只是等主机挂了后来自动升级为客户端继续提供服务。也就是说他不会为主节点分摊请求压力。
2. 主从
读请求会均摊到主节点和从节点上，而不是等主机挂了才提供服务。写请求在master上进行，然后同步到slaver。读请求会分摊，比如10w个请求，一主双从的话，可能M上3w个，两个S上处理6w个，他会为主节点分摊压力。所以可以解决单点故障问题。
2、主从复制三种类型1. 同步阻塞
这种方式讲究强一致性，必须等所有Slave都写入成功后我才会给客户端响应，否则一直阻塞。也是CAP中的C。
原理图：
2. 异步非阻塞
Redis采取的这种方式。没有采取下面同步阻塞mq的方式可能也是因为效率吧，因为Redis就是要高效。客户端发完请求到Redis Master后，立马给客户端返回，我不管你Slaver是否同步完成。保留CAP的A，舍弃C。
原理图：
3. 同步阻塞MQ
大数据hive采取的就是这种方式，他会保证最终一致性。相对于第二种方式好处在于能保证数据的最终一致性，坏处在于没第二种方式高效，但第二种存在丢数据的风险。
主从复制其实就是实现高可用（虽然是人工操作），避免单点故障问题。挂掉一个节点，我其他节点可以接着提供服务，但是明显缺点发现是Slave挂掉还好，Master挂掉可就难受了，Slave太多的话那就够运维折腾的了，这时候就有了哨兵。 同时，Redis虽然读取写入的速度都特别快，但是也会产生读压力特别大的情况，主从复制也能够分担读压力。
主从复制原理图：
其实就跟MySQL一个道理，mysql是靠binlog，而Redis靠的是rdb文件和aof文件。
2、主从复制实现原理总的来说主从复制功能的详细步骤可以分为7个步骤：
设置主节点的地址和端口-》建立套接字链接-》发送PING命令-》权限验证-》同步-》命令传播
接下来分别叙述每个步骤，整个流程图如下：
假设在本地机开启两个Redis节点，分别监听：
1. 设置主服务器的地址和端口
第一步首先是在从服务器设置需要同步的主服务器信息，包括机器IP，端口。
主从复制的开启，完全是从节点发起；不需要我们在主节点做任何事情。
从节点开启主从复制，有3种方式：
（1）配置文件
在从服务器的配置文件中加入：
slaveof masterip masterport（2）启动命令
redis-server启动命令后加入：
slaveof masterip masterport（3）客户端命令
Redis服务器启动后，直接通过客户端执行命令：
slaveof masterip masterport则该Redis实例称为从节点。
上述3种方法是等效的，下面以客户端命令的方式为例，看一下当执行了slaveof后，Redis主节点和从节点的变化。从服务器会将主服务器的ip地址和端口号保存到服务器状态的属性里面，可以使用Redis命令 info replication 分别查看从服务器和主服务器的主从信息。
2. 建立套接字连接
在slaveof命令执行之后，从服务器会根据设置的ip和端口，向主服务器建立socket连接。
在6380从服务器里面执行完 slave of 127.0.0.1 6379 后意味着，从服务器向主服务器发起 socket 连接。
在执行info Replication 命令分别查看从服务器的主从信息：
而6379服务器已经成为主服务器角色：
3. 发送PING命令
从节点成为了主节点的客户端之后，发送 ping 命令进行首次请求，目的是：检查socket连接是否可用，以及主节点当前是否能够处理请求。
从节点发送 ping 命令后，可能出现3种情况：
4. 身份验证
如果从节点中设置了masterauth选项，则从节点需要向主节点进行身份验证；没有设置该选项，则不需要验证。从节点进行身份验证是通过向主节点发送auth命令进行的，auth命令的参数即为配置文件中的masterauth的值。
如果主节点设置密码的状态，与从节点masterauth的状态一致（一致是指都存在，且密码相同，或者都不存在），则身份验证通过，复制过程继续；如果不一致，则从节点断开socket连接，并重连。
5. 同步
同步就是将从节点的数据库状态更新成主节点当前的数据库状态。具体执行的方式是：从节点向主节点发送psync命令（Redis2.8以前是sync命令），开始同步。
数据同步阶段是主从复制最核心的阶段，根据主从节点当前状态的不同，可以分为 全量复制 和 部分复制。
6. 命令传播
经过上面同步操作，此时主从的数据库状态其实已经一致了，但这种一致的状态并不是一成不变的。
在完成同步之后，也许主服务器马上就接受到了新的写命令，执行完该命令后，主从的数据库状态又不一致。
数据同步阶段完成后，主从节点进入命令传播阶段；在这个阶段主节点将自己执行的写命令发送给从节点，从节点接受命令并执行，从而保证主从节点数据的一致性。
另外命令传播我们需要关注两个点：延迟与不一致 和 心跳机制。
需要注意的是，命令传播是异步的过程，即主节点发送写命令后并不会等待从节点的回复；因此实际上主从节点之间很难保持实时的一致性，延迟在所难免。数据不一致的程度，与主从节点之间的网路状况、主节点写命令执行频率、以及主节点中repl-disable-tcp-nodelay 配置等有关。
repl-disable-tcp-nodelay 配置如下：
概括来说就是：前者关注性能，后者关注一致性。
一般来说，只有当应用对Redis数据不一致的容忍度较高，且主从节点之间网络状态不好时，才会设置为yes；多数情况使用默认值no
命令传播阶段，从服务器会利用心跳检测机制定时的向主服务发送消息。
3、Redis主从复制结构Redis的主从结构可以采用一主一从、一主多从或者树状主从结构，Redis主从复制可以根据是否是全量分为全量同步和增量同步。
一主一从：
一主多从：
树状主从结构：
在Redis2.8以前，从接待你向主节点发送sync命令请求同步数据，此时的同步方式是全量复制；在Redis2.8及以后，从节点可以发送psync命令请求同步数据，此时根据主从节点当前状态的不同，同步方式可能是全量复制或部分复制。
全量复制：用于初次复制或其他无法进行部分复制的情况，将主节点中的所有数据都发送给从节点，是一个非常重型的操作。
部分复制：用于网络中断等情况后的复制，只将中断期间主节点执行的写命令发送给从节点，与全量复制相比更加高效，需要注意的是，如果网络中断时间过长，导致主节点没有能够完整地保存中断期间执行地写命令，则无法进行部分复制，仍使用全量复制。
1. 全量同步
Redis全量复制一般发生在Slave初始化阶段，这时Slave需要将Master上的所有数据都复制一份。
具体步骤如下：
完成上面几个步骤后就完成了从服务器数据初始化的所有操作，从服务器此时可以接收来自用户的读请求。
2. 增量同步
由于全量复制在主节点数据量较大时效率太低，因此Redis2.8开始提供部分复制，用于处理网络中断时的数据同步。
部分复制的实现，依赖于三个重量的概念：复制偏移量、复制积压缓冲区、服务器运行id（runid）
1）复制偏移量
执行复制的双方，主从节点，分别会维护一个复制偏移量offset：
offset用于判断主从节点的数据库状态是否一致：如果二者offset相同，则一致；如果offset不同，则不一致，此时可以根据两个offset找出从节点缺少的那部分数据。例如，如果主节点offset是1000，而从节点的offset是500，那么部分复制旧需要将offset为501-1000的数据传递给从节点。而offset为501-1000的数据存储的位置，就是下面要介绍的复制积压缓冲区。
2）复制积压缓冲区（replication-backlog-buffer）
主节点内部维护了一个固定长度的、先进先出（FIFO）队列作为复制积压缓冲区，默认大小为1MB，在主节点进行命令传播时，不仅会将写命令同步到从节点，还会将写命令写入复制积压缓冲区。
由于复制积压缓冲区定长且是先进先出，所以他保存的是主节点最近执行的写命令；时间较早的写命令会被挤出缓冲区。因此，当主从节点offset的差距过大超过缓冲区长度时，将无法执行部分复制，只能执行全量复制。
为了提高网络中断时部分复制执行的概率，可以根据需要增大复制积压缓冲区的大小（通过配置repl-backlog-size）；例如如果网络中断的平均时间是60s，而主节点平均每秒产生的写命令（某些特定协议格式）所占据的字节数为100KB，则复制积压缓冲区的平均需求为6MB，保险起见，可以设置为12MB，来保证绝大多数断线情况都可以使用部分复制。
从节点将offset发送给主节点后，主节点根据offset和缓冲区大小决定能否执行部分复制：
3）服务器运行ID（runid）
每个Redis节点，都有其运行ID，运行ID由节点在启动时自动生成，主节点会将自己的运行ID发送给从节点，从节点会将主节点的运行ID存起来。从节点Redis断开重连的时候，就是根据运行ID来判断同步的进度：
如果从节点保存的runid与主节点现在的runid相同，说明主从节点之前同步过，主节点会继续尝试使用部分复制（到底能不能部分复制还要看offset和复制积压缓冲区的情况）；
如果从节点保存的runid与主节点现在的runid不同，说明从节点在断线前同步的Redis节点并不是当前的主节点，只能进行全量复制。
4、psync命令的执行在了解了复制偏移量、复制积压缓冲区、节点运行id之后，这里psync命令的参数和返回值，从而说明psync命令执行过程中，主从节点是如何确定使用全量复制还是部分复制的。
psync命令流程图如下：
psync命令的大体流程如下：
如果从节点之前没有复制过任何主节点，或者之前执行过slaveof no one 命令，从节点就会向主节点发送psync 命令，请求主节点进行数据的全量同步。
如果前面从节点已经同步过部分数据，此时从节点就会发送psync runid offset 命令给主节点，其中runid是上一次主节点的运行ID，offset是当前从节点的复制偏移量
主节点收到psync命令后，会出现以下三种可能：
主节点返回 fullresync runid offset 回复，表示主节点要求与从节点进行数据的完整全量复制，其中runid表示主节点的运行ID，offset表示当前主节点的复制偏移量。
如果主服务器返回+continue，表示从节点与从节点会进行部分数据的同步操作，将从节点缺失的数据复制过来即可。
如果主服务器返回-err，表示主服务器的Redis版本低于2.8，无法是别psync命令，此时从服务器会向主服务器发送sync，进行完整的数据全量复制。
Redis通过psnyc命令进行全量复制的过程如下：
通过全量复制的过程可以看出，全量复制是非常重型的操作：
心跳检测机制的作用有三个：
检查主从服务器的网络连接状态，主节点信息中可以看到所属的从节点的连接信息：
state 表示从节点状态、offset表示复制偏移量、lag表示延迟值（几秒之前有过心跳检测机制）
辅助实现min-slaves选项，Redis.conf 配置文件中有下方两个参数：
# 未达到下面两个条件时，写操作就不会被执行
# 最少包含的从服务器
# min-slaves-to-write 3
# 延迟值
# min-slaves-max-lag 10如果将两个参数注释取消，那么如果从服务器的数量少于3个，或者三个从服务器的延迟（lag）大于等于10秒时，主服务器都会拒绝执行写命令。
检测命令丢失时，在从服务器的连接信息中可以看到复制偏移量，如果此时主服务器的复制偏移量与从服务器的复制偏移量不一致时，主服务器会补发缺失的数据。
5、无磁盘复制通常来讲，一个完全重新同步需要在磁盘上创建一个RDB文件，然后加载这个文件以便为从服务器发送数据。如果使用比较低速的磁盘，这种操作会给主服务器带来较大的压力。Redis从2.8.18版本开始尝试支持无磁盘的复制。使用这种设置时，子进程直接将RDB通过网络发送给从服务器，不使用磁盘作为中间存储，避免了IO性能差问题。
可以使用repl-diskless-sync 配置参数来启动无磁盘复制。使用repl-diskless-sync-delay参数来配置传输开始的延迟时间，以便等待更多的从服务器连接上来。
开启无磁盘复制：
repl-diskless-sync yes如果在主从复制架构中出现宕机的情况，需要分情况看：
1. 从Redis宕机
这个相对而言比较简单，在Redis中从库重新启动后会自动加入到主从架构中，自动完成同步数据，这是因为在Redis2.8版本后就新增了增量复制功能，主从断线后恢复是通过增量复制实现的。所以这种情况无需担心。
2. 主Redis宕机
这个情况相对而言就会复杂一些，需要以下2步才能完成：
第一步，在从数据库中执行SLAVEOF NO ONE命令，断开主从关系并且提升为主库继续服务；
第二步，将主库修复重新启动后，执行SLAVEOF命令，将其设置为其他库的从库，这时数据就能更新回来；
这两个步骤要通过手动完成恢复，过程其实是比较麻烦的并且容易出错，有没有好办法解决呢？有的，Redis提供的哨兵（sentinel）功能就可以实现主Redis宕机的自动切换。
7、Redis主从复制总结1. Redis主从复制策略
主从刚刚连接的时候，进行全量同步；全同步结束后，进行增量同步。当然，如果有需要，slave 在任何时候都可以发起全量同步。redis的策略是，无论如何，首先会尝试进行增量同步，如不成功，要求从机进行全量同步。
2. 主从复制的特点
主从复制的特点：
主从模式并不完美，它也存在许多不足之处，下面做了简单地总结：
虽然主从模式存在上述不足，但他仍然是实现分布式集群的基础。Sentinel哨兵模式同样是依赖于主从模式实现。
五、Redis主从复制实战 1、主从复制配置文件redis.config配置文件相关配置：
配置主从：
# 相当于我们上面客户端执行的REPLICAOF命令，配置到配置文件每次重启就不用手动再执行命令了。
replicaof# master的密码
masterauth 主从传输数据这期间，从节点是否允许对外提供服务：
# 默认是ye，允许
slave-serve-stale-data yes看下面的log（这是我们建立主从关系的时候产生的log）。
意思是说在和Master建立连接，获取完Master数据之间，也就是从库进行flush操作之前，是否允许对外继续提供请求（就是Slave完成配置之前的那些flush之前的老数据是否还允许被访问）。
是否开启Slave从节点也支持写命令：
# 默认只读，yes代表只读
slave-read-only yes先落磁盘再传输还是直接网络传输：
# 默认是先落盘，再进行网络传输
repl-diskless-sync no因为默认是Master先生成rdb文件到磁盘，这时候产生一次磁盘IO，然后将磁盘上rdb文件以网络的方式传递给Slave，这时候又产生一次IO，如果rdb几个GB的话那还不如直接走网络传输，就不走磁盘io了。 改为yes的话直接Master通过网络的方式发送rdb给Slave。默认是no，从日志也可以看出先落盘了
原理图：
全量还是增量：
repl-backlog-size 1mb可以发现比主从复制原理图中多了个队列和偏移量。
这个队列代表repl-backlog-size参数设置的值大小，是决定全量复制还是增量复制的关键参数。
RDB每次同步到slave的时候，slave都会记录一个offset偏移量，然后每次同步数据的时候都会看队列里的数据偏移量是否符合slave上次同步的数据大小，若符合则增量，否则全量。
举例：
如果设置的1MB，你挂了3s钟，假设1s钟就写了1MB，那么3s钟的队列肯定放不下，这时候就触发全量，所以这个需要看业务调整大小。
再比如master是100MB数据，slave也是1MB数据，然后slave挂了。恢复的时候发现master已经有110MB了，但是队列大小只有1MB，把队列里的数据拿来显然不行，所以会触发全量，这只是举例，其实不会那么傻的判断总大小，而是通过偏移量来的。
2、仅开启RDB仅仅开启RDB持久化，关闭AOF。
首先启动三个redis，端口分别是6379、6380、6381。我们这里设定6379为Master，其余两个为Slaver。
1. 如何设置Slaver
可以看到Redis5.x后开始用REPLICAOF命令代替5.x版本之前的SLAVEOF命令。
2. 设置Slaver
# 设置6380是6379的从节点
127.0.0.1:6380>REPLICAOF localhost 6379
OK设置完成后去看6379和6380的log
6379的log：
6380的log：
3. 在Master执行写命令
127.0.0.1:6379>set k1 123
OK
127.0.0.1:6379>get k1
"123"4. 在Slave（6380）上查看是否同步过来了
127.0.0.1:6380>keys *
1) "k1"
127.0.0.1:6380>get k1
"123"5. Slave是禁止执行写命令的
127.0.0.1:6380>set k2 123
(error) READONLY You can't write against a read only replica.6. 设置6382也作为6379的Slave
设置从节点之前先在6382内set一个值，为了确定设置完后会进行flush操作。
127.0.0.1:6381>set k2 222
OK
127.0.0.1:6381>get k2
"222"然后设置Slave：
127.0.0.1:6381>REPLICAOF 127.0.0.1 6379
OK
127.0.0.1:6381>keys *
1) "k1"将Master的数据同步过来了。
如果设置Slave后进行了flush操作（上面的log也体现出来了），我们之前的k2没了。
若6381宕机了，这时候他再启动的时候是会同步Master的数据的，增量同步的。不需要手动进行同步。
但前提是需要作为Master的Slave，有如下三种方式：
8. Master挂了怎么办
从节点会一直报错：
导致的问题：Slave无法提供写请求，只能读了。影响了业务使用。
解决方案：让其中一个Slave升级为Master，然后其他Slave作为这个新升级为Master的从。
# 升级为Master的方法：在客户端执行，比如我们升级6380为Master
127.0.0.1:6380>REPLICAOF no one
OK
# 这时候再看6380就不会再刷错了，但是6381还在刷，
# 因为6381是已经挂掉的6379的Slave，我们需要让6381作为6380的Slave，
# 我们再操作这步骤之前，对6380set一个key，然后看6381的数据会重新复制6380的数据
# 显示业务中几乎不会存在此情况，因为从节点升级就是升级，所有主从的数据都一致，不会随意改
# 这里只是演示效果而已。
127.0.0.1:6380>set kkk 3333
OK
# 6381作为6380的Slave
127.0.0.1:6381>REPLICAOF 127.0.0.1 6380
OK
127.0.0.1:6381>keys *
1) "kkk"
2) "k1"
127.0.0.1:6381>get kkk
"3333"1. 仅开启AOF
和上面一样。只是会按照aof文件进行主从复制数据。
2. 混合模式（RDB+AOF）
流程和仅开启RDB一样，只是主从复制的时候会优先按照aof来同步数据，因为aof文件丢失数据最少，更可靠。redis会判断aof文件是否存在，若开启了aof且文件存在，则以aof复制，若没开启aof则走rdb方式。
4、Redis主从复制实战
1. 使用命令实现
1）方法一
使用命令在服务端搭建主从模式，其语法格式如下：
redis-server --port--slaveof 执行以下命令：
#开启开启一个port为6300的从机，它依赖的主机port=6379
>redis-server --port 6300 --slaveof 127.0.0.1 6379
接下来开启客户端，并执行查询命令，如下所示：
>redis-cli -p 6300
127.0.0.1:6300>get name
"jack"
127.0.0.1:6300>get website
"www.biancheng.net"
#不能执行写命令
127.0.0.1:6300>set myname BangDe
(error) READONLY You can't write against a read only slave.
127.0.0.1:6300>keys *
1) "myset:__rand_int__"
2) "ID"
3) "title"
4) "course2"从上述命令可以看出，port =6300 的主机，完全备份了主机的数据，它可以执行查询命令，但不能执行写入命令
从机服务端提示如下：
[18160] 20 Jan 17:40:34.101 # Server initialized #服务初始化
[18160] 20 Jan 17:40:34.108 * Ready to accept connections #准备连接
[18160] 20 Jan 17:40:34.108 * Connecting to MASTER 127.0.0.1:6379 #连接到主服务器
[18160] 20 Jan 17:40:34.109 * MASTER<->REPLICA sync started #启动副本同步
[18160] 20 Jan 17:40:34.110 * Non blocking connect for SYNC fired the event.#自动触发SYNC命令，请求同步数据
[18160] 20 Jan 17:40:34.110 * Master replied to PING, replication can continue...
[18160] 20 Jan 17:40:34.112 * Partial resynchronization not possible (no cached master)
[18160] 20 Jan 17:40:34.431 * Full resync from master: 6eb220706f73107990c2b886dbc2c12a8d0d9d05:0
[18160] 20 Jan 17:40:34.857 * MASTER<->REPLICA sync: receiving 6916 bytes from master #从主机接受了数据，并将其存在于磁盘
[18160] 20 Jan 17:40:34.874 * MASTER<->REPLICA sync: Flushing old data #清空原有数据
[18160] 20 Jan 17:40:34.874 * MASTER<->REPLICA sync: Loading DB in memory #将磁盘中数据载入内存
[18160] 20 Jan 17:40:34.879 * MASTER<->REPLICA sync: Finished with success #同步数据完成可以看出主从模式下，数据的同步是自动完成的，这个数据同步的过程，又称为全量复制。
2）方法二
启动一个服务端，并指定端口号。
#指定端口号为63001，不要关闭
redis-server --port 63001打开一个客户端，连接服务器，如下所示：
# 连接port=63001的服务器
>redis-cli -p 63001
// 现在处于主机模式下，所以运行读写数据
127.0.0.1:63001>keys *
1) "name"
127.0.0.1:63001>get name
"aaaa"
127.0.0.1:63001>set name "bbbb"
OK
127.0.0.1:63001>get name
"bbbb"
127.0.0.1:63001># 将当前服务器设置为从服务器，从属于6379
127.0.0.1:63001>SLAVEOF 127.0.0.1 6379
OK
127.0.0.1:63001>keys *
1) "master_6379" # 现在它的数据和主服务器的数据一样了
#写入命令执行失败
127.0.0.1:63001>SET mywebsite www.biancheng.net
(error) READONLY You can't write against a read only replica.
#再次切换为主机模式，执行下面命令
127.0.0.1:63001>SLAVEOF no one
OK
127.0.0.1:63001>SLAVEOF no one
OK
127.0.0.1:63001>keys *
1) "master_6379" # 数据还是和之前主服务器的一样
127.0.0.1:63001>SET mywebsite www.biancheng.net # 但是现在可以写入命令了
OK
127.0.0.1:63001>keys *
1) "mywebsite"
2) "master_6379"
2. 修改配置文件实现
每个 Redis 服务器都有一个与其对应的配置文件，通过修改该配置文件也可以实现主从模式。
新建 redis_6302.conf 文件,并添加以下配置信息：
slaveof 127.0.0.1 6379 #指定主机的ip与port
port 6302 #指定从机的端口启动 Redis 服务器，执行以下命令：
$ redis-server redis_6302.conf客户端连接服务器，并进行简单测试。
执行以下命令：
$ redis-cli -p 6302
127.0.0.1:6300>HSET user:username biangcheng
#写入失败
(error) READONLY You can't write against a read only slave.通过命令搭建主从模式，简单又快捷，所以不建议使用修改配置文件的方法。
你是否还在寻找稳定的海外服务器提供商？创新互联www.cdcxhl.cn海外机房具备T级流量清洗系统配攻击溯源，准确流量调度确保服务器高可用性，企业级服务器适合批量采购，新人活动首月15元起，快前往官网查看详情吧
