一.简单介绍
Redis是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。从2010年3月15日起，Redis的开发工作由VMware主持。从2013年5月开始，Redis的开发由Pivotal赞助
二.现网中redis的现状和可能遇到的问题和解决方法
1.现状：在现有企业中80%公司大部分使用的是redis单机服务，在实际的场景当中单一节点的redis容易面临风险
2.可能遇到的问题：
1）机器故障～单一节点的问题。部署到一台 Redis 服务器，当发生机器故障时，需要迁移到另外一台服务器并且要保证数据是同步的。而数据是最重要的，如果你不在乎，基本上也就不会使用 Redis 了。
2）容量瓶颈。当我们有需求需要扩容 Redis 内存时，从 16G 的内存升到 64G，单机肯定是满足不了。当然，你可以重新买个 128G 的新机器。
3.解决方法：
Redis 为了解决这个单一节点的问题，也会把数据复制多个副本部署到其他节点上进行复制，实现 Redis的高可用，实现对数据的冗余备份，从而保证数据和服务的高可用，为解决瓶颈问题，会将原来集中式数据库的数据分别存储到其他多个网络节点上
三.主从复制
主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点(master)，后者称为从节点(slave)
Redis的主从结构可以采用一主多从或者级联结构
1.主从复制的特点：
0）采用异步复制；
1）一个master可以有多个slave，但是一个slave只有一个master
2）数据流是单向的，只能有master到slave
3）slave也是可以有自己的slave节点（存在从从同步）
4）主从复制对于主redis服务器来说是非阻塞的，这意味着当从服务器在进行主从复制同步过程中，主redis仍然可以处理外界的访问请求
5）主从复制对于从redis服务器来说也是非阻塞的，但是读取的数据可能是老数据
6）为了降低主redis服务器写磁盘压力带来的开销，可以配置让主redis不在将数据持久化到磁盘，而是通过连接让一个配置的从redis服务器及时的将相关数据持久化到磁盘，（不过这样会存在一个问题，就是主redis服务器一旦重启，因为主redis服务器数据为空，这时候通过主从同步可能导致从redis服务器上的数据也被清空；）
2.主从复制的作用：
1）数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。
2）故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。～但是需要手动切换
3）负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写Redis数据时应用连接主节点，读Redis数据时应用连接从节点），分担服务器负载；尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量。
4）读写分离：可以用于实现读写分离，主库写、从库读，读写分离不仅可以提高服务器的负载能力，同时可根据需求的变化，改变从库的数量；
5）高可用基石：除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis高可用的基础
3.主从复制启动
参考地址：
4.主从复制流程：
主从复制过程大体可以分为3个阶段：连接建立阶段（即准备阶段）、数据同步阶段、命令传播阶段。
1）连接建立：
A、保存主节点（master）信息
B、主从建立socket连接
C、发送ping命令（返回pong）～检测主从之间网络套接字是否可用，检测主节点当前是否可接受处理命令
D、权限验证～需要登录密码
E、同步数据集 ～ 全量同步
F、命令持续复制 ～ 增量同步
解释：
1）Redis主从复制可以根据是否是全量分为全量同步和增量同步（无盘复制2.8版本之后支持）
2）全量同步时，salve会丢弃所有的旧数据
3）在什么时候进行全量复制，是否选择全量复制（快照复制）：
主从节点连接成功后，主从节点进行一次快照同步。事实上，是否进行快照同步需要判断主节点的run id，当从节点发现已经连接过某个run id的主节点，那么视此次连接为重新连接，就不会进行快照同步。相同IP和port的主节点每次重启服务都会生成一个新的run id，所以每次主节点重启服务都会进行一次快照同步，如果想重启主节点服务而不改变run id，使用redis-cli debug reload命令
5.全量同步（快照同步）
1)刚开始主从同步的时候使用全量同步
2）节点间网络通信不好，那么当从节点同步的速度不如主节点接收新写请求的速度时，buffer 中会丢失一部分指令，从节点中的数据将与主节点中的数据不一致，此时也会触发快照同步
快照同步是一个非常耗费资源的操作，它首先需要在主节点上进行一次 bgsave 将当前内存的数据全部快照到RDB文件中，然后再将快照文件的内容全部传送到从节点。从节点将RDB文件接受完毕后，立即执行一次全量加载，加载之前先要将当前内存的数据清空。加载完毕后通知主节点继续进行增量同步
可能出现的问题：
在整个快照同步进行的过程中，主节点的复制 buffer 还在不停的往前移动，如果快照同步的时间过长或者复制 buffer 太小，都会导致同步期间的增量指令在复制 buffer 中被覆盖，这样就会导致快照同步完成后无法进行增量复制，然后会再次发起快照同步，如此极有可能会陷入快照同步的死循环。所以需要配置一个合适的复制 buffer 大小参数，避免快照复制的死循环
6.无盘复制
主节点在进行快照同步时，会进行大量的文件 IO 操作，特别是对于非 SSD 磁盘存储时，快照会对系统的负载产生较大影响。特别是当系统正在进行 AOF 的 fsync 操作时如果发生快照复制，fsync 将会被推迟执行，这就会严重影响主节点的服务效率。
从 Redis 2.8.18 版开始支持无盘复制。所谓无盘复制是主节点会一边遍历内存，一遍将序列化的内容发送到从节点，而不是生成完整的 RDB 文件后才进行 IO 传输从节点还是跟之前一样，先将接收到的内容存储到磁盘文件中，再进行一次性加载
7.增量同步
redis 增量同步的是指令流，主节点会将那些对自己的状态产生修改性影响的指令记录在本地的内存 buffer 中，然后异步将 buffer 中的指令同步到从节点，从节点一边执行同步的指令流来达到和主节点一样的状态，一边向主节点反馈自己同步到哪里了 (偏移量，这是redis-2.8之后才有的特性)。从节点同步数据的时候不会影响主节点的正常工作，也不会影响自己对外提供读服务的功能，从节点会用旧的数据来提供服务，当同步完成后，需要删除旧数据集，加载新数据，这个时候才会暂停对外服务
