Redis学习第五天

利用Docker管理Redis，作者已经学习过！通过Docker管理Redis集群是很方便的！

Linux与Docker

关于Docker带来的弹性云服务，后续会基于Docker部署Redis集群，整个集群随时开启关闭。其实配置集群启动脚本是不是也可以啊？作者之前集群都是通过配置一系列启动脚本滴，那就查一查：

Docker 在弹性云服务中的优势

1. 可移植性：Docker 容器可以在任何安装了 Docker 的机器上运行，不管是在本地、私有云还是公有云。

2. 微服务：Docker 非常适合微服务架构，因为它允许你将每个服务打包为一个单独的容器，这些容器可以单独伸缩和部署。

3. 隔离：每个 Docker 容器都在其自己的环境中运行，这意味着它们彼此隔离，即使它们运行在同一个物理机上。

4. 快速部署：由于 Docker 容器只包含运行应用程序所需的最小依赖，因此它们启动得非常快。

5. 版本控制：Docker Hub 或私有仓库可以存储多个版本的容器映像，使得回滚和版本切换变得简单。

对于 Redis 集群的部署：

Docker 的方式：你可以使用 Docker Compose 或 Kubernetes 来部署、管理和扩展 Redis 集群。这样做的好处是，你可以很容易地调整集群的大小，添加或删除节点，并确保每个节点都有一致的配置。

传统的脚本方式：当然，你也可以使用脚本来启动、停止和管理 Redis 集群。这样的好处是，它可能更简单，特别是对于那些不熟悉 Docker 的人。但是，你可能会失去 Docker 提供的某些优势，比如隔离和快速部署。

最后，选择使用 Docker 还是传统脚本取决于你的需求和经验。如果你对 Docker 感到舒适，并希望充分利用它提供的优势，那么 Docker 是一个很好的选择。但如果你觉得 Docker 增加了复杂性，并希望坚持使用你熟悉的工具和过程，那么传统脚本可能更合适。

所以，作者还是要学一下Docker！

image镜像就相当于容器类，可以提供应用程序和依赖。只有通过Image才能生成container容器。

镜像文件image是二进制文件，一个image文件往往是通过继承其他image文件而形成的。可以使用docker pull命令从Docker Hub上获取镜像！Docker Hub是镜像仓库！

镜像是静态类，容器是动态实体：

后面都是在image基础上创建容器，运行容器docker run。

基本上运行容器啊，不使用数据卷是不行的。读者看，上图可以直接进入bash终端，在redis中呢就可以直接进入redis终端了，但是，对于这样redis的操作，并不是持久化的！如何改善见后文！

常用指令复习一下：

docker container stop

docker ps -a

exit退出bash终端

Repository仓库用来存储管理image文件，可以帮助实现镜像共享。

Redis集群

通常使用主从复制的模式提高性能和可用性，本节使用Docker容器模拟服务器，这个作者还是第一次接触，看起来蛮有意思！

与Mysql集群比较

1. 主从复制

MySQL 主从复制：

• 数据同步：MySQL 的主从复制是半同步或异步的。默认情况下，它是异步的，意味着主服务器不会等待从服务器确认已接收并应用了日志事件。
• 操作模式：MySQL 复制基于事件。主服务器上的更改（如INSERT、UPDATE等操作）被写入二进制日志，然后这些事件会被传送到从服务器并在那里重放。

Redis 主从复制：

• 数据同步：Redis 的复制是异步的。但与MySQL不同的是，Redis 主从复制的延迟通常非常小，几乎是实时的。
• 操作模式：Redis 复制是基于数据的。当从服务器连接到主服务器时，主服务器会发送其整个数据集给从服务器。之后，主服务器上的所有新的写命令都会被发送到从服务器并在那里执行。
• 读写模式：在Redis中，从服务器可以用于读取操作，提高读取能力。但从服务器默认是只读的，写操作只在主服务器上执行。其实Mysql也是如此。

2. 分布式集群

MySQL Cluster：

• 事务性：MySQL 支持ACID事务，确保数据的一致性、原子性、隔离性和持久性。
• 分片策略：MySQL Cluster 使用预定义的规则或用户定义的函数进行数据分片。

Redis Cluster：

• 事务性：虽然Redis支持某种形式的事务（使用MULTI、EXEC、WATCH等命令），但它们与传统的ACID事务有所不同。在Redis Cluster中，事务不能跨多个节点，因为Redis不支持跨节点的事务。
• 数据分区：Redis Cluster 通过哈希槽进行数据分区。整个键空间被分为 16,384 个哈希槽，每个节点负责其中一部分哈希槽。当增加或删除节点时，哈希槽会被重新分配。

核心区别：

• 复制的同步性：虽然两者都可以是异步的，但在实践中，Redis的主从复制延迟通常更低。

• 复制的操作模式：MySQL基于事件复制，而Redis基于数据复制。

• 事务性：MySQL提供了完全的ACID事务支持，而Redis虽然有事务命令，但其语义与传统数据库有所不同，尤其在Cluster模式中。

集群相关概念 

什么叫跨节点的事务？

在分布式数据库系统中，如果一个事务涉及到两个或多个不同的物理节点，这样的事务被称为跨节点事务。例如，假设我们有一个事务，其中的两个命令需要操作不同节点上的数据，这就是跨节点事务。(分布式存储中数据往往被分片到多个物理机上，并且有多个备份哦~)

为什么Redis会基于数据复制？

基于数据的复制使得整个复制过程简单并且更易于实现。这种策略确保从节点有一个与主节点几乎相同的数据副本，从而在主节点故障时可以快速切换。

为什么Redis不提供完整的事务功能？

Redis的设计目标是为了速度和简单性。虽然它提供了一些事务功能（例如，MULTI、EXEC和WATCH命令），但这些事务不同于传统的ACID事务。Redis的这些“事务”更像是命令批处理，因为它们只确保命令连续执行，而不是确保命令的原子性。

为什么Redis不支持跨节点事务？

在Redis Cluster中，不支持跨节点的事务是因为这样做会引入复杂性，并可能降低性能。跨节点事务需要复杂的两阶段提交或其他分布式事务协议，这些协议会增加延迟并降低吞吐量。由于Redis的设计重点是低延迟和高吞吐量，因此选择了不支持跨节点的事务。

Redis的设计选择是基于其用例和目标的：为了提供一个高性能、易于使用的内存数据存储，而不是一个完整的关系型数据库系统。

Redis主从复制

Redis的主从复制过程与MySQL的binlog机制有所不同。在MySQL中，主要的变化（如插入、更新、删除等）被记录在binlog中，然后从服务器读取并应用这些日志来保持与主服务器同步。

在Redis中，主从复制的流程有些不同：

1. 全量复制：当一个从服务器首次连接到主服务器时，或当需要重新同步数据时，会进行全量复制。主服务器会创建一个包含其数据集的RDB快照并将其发送给从服务器。从服务器接收到这个快照后，会丢弃其所有旧数据并加载这个快照。

2. 部分复制：一旦全量复制完成，主服务器会继续将所有新的写命令（指令集）发送到从服务器，确保数据在主从之间的实时一致性。

Redis的这种机制主要基于其主要用途——作为一个高速的键值存储系统。与传统的关系型数据库相比，其设计更加轻量且更注重性能。因此，直接传输写命令而不是类似binlog的日志文件可以减少一些转换和处理的开销。

Redis的主从复制机制和持久化方式的相互作用

再细讲一下，咱一起确立好概念：

1. 初次复制：当一个从服务器首次连接到主服务器时，进行所谓的“全量复制”。在这个阶段，主服务器生成一个RDB快照并发送给从服务器。从服务器接收这个快照并加载到内存中。这确保从服务器的初始状态与主服务器相匹配。

2. 增量复制：完成初次复制后，所有后续的写入命令（例如，SET, DEL等）在主服务器执行后直接发送到从服务器进行同步。这不是通过AOF文件中的命令，而是实时发送这些命令给从服务器。

3. 持久化：

   • RDB：这是一个快照机制，定期或在特定的条件下将当前的数据集写入磁盘。
   • AOF：这记录了所有的写入操作，是一个追加的日志文件。如果AOF持久化被启用，那么写入命令会被追加到AOF文件中。但是！不记录增量复制的内容！

在主从同步的上下文中，AOF文件并不直接用于数据同步。但AOF提供了数据的持久化保障，意味着在Redis重启后，可以通过重放AOF文件中的命令来恢复数据。

现在，如果主服务器出现故障并重新启动：

• 如果配置了AOF并且AOF的数据比RDB更加新，那么Redis在启动时会选择AOF来恢复数据，因为它提供了更好的数据完整性。
• 如果没有AOF或者RDB更加新，那么RDB被用来恢复数据。

但在主从复制的场景中，如果从服务器与主服务器的连接丢失，当它们重新连接时：

• 如果断开的时间很短，并且主服务器的缓冲区中还保留有所有丢失的命令，那么这些命令会被发送到从服务器，完成增量同步。
• 如果断开时间较长或主服务器的缓冲区不足以保存所有丢失的命令，那么将进行全量复制，即再次发送RDB快照。

所以，总结一下，RDB主要用于初始化从服务器和备份，而AOF主要用于数据恢复。在主从复制中，增量更新是通过实时发送写命令来完成的，而不是通过AOF文件。

深入解读从服务器与主服务器连接丢失

当从服务器与主服务器重新建立连接后，它们将试图进行增量复制（因为它快嘛），即只同步断开连接期间丢失的数据。但是，主服务器有一个专门的缓冲区，称为复制缓冲区，用于存储最近执行的写命令，以便可以传输给从服务器进行增量复制。

1. 增量复制：如果断开的时间相对较短，且主服务器的复制缓冲区能够存储断开期间所有的写命令，那么只需执行增量复制。

2. 全量复制：但如果断开的时间过长或复制缓冲区的大小不足以保存断开期间的所有写命令，则主服务器将无法进行增量复制。此时，会触发全量复制。全量复制意味着主服务器生成一个新的RDB快照并发送给从服务器。从服务器将使用这个快照重新初始化自己的数据。

3. 全量复制后的增量复制：在全量复制完成后，从服务器的数据状态应该与主服务器同步。但是，考虑到在RDB快照生成和传输的过程中，主服务器上可能还会有新的写命令执行。因此，在全量复制后，从服务器仍然需要接收那些在全量复制期间产生的增量更新。这些更新通常可以从复制缓冲区中获取。

简而言之，如果复制缓冲区可以提供所有丢失的写命令，那么就只进行增量复制；如果不能，则进行全量复制。在全量复制之后，增量复制将确保从服务器完全与主服务器同步，即使在全量复制过程中主服务器上有新的写命令执行。