MySQL事务：
- 原子性：把多个操作打包成一个整体
- 一致性：事务执行之前和之后，数据库的完整性约束一致
- 持久性：事务中做出的修改都会存硬盘
- 隔离性：事务并发执行
而Redis的事务和MySQL一比就很可怜
不具备原子性：MySQL要么全部执行成功要么全部不执行，而redis要么全执行要么全不执行
它是不保证成功的。mysql事务中有操作执行失败要进行回滚，redis没有回滚
不具备一致性：redis没有约束
不具备持久性：redis本身就是内存数据库，数据是存储再内存上，虽然有持久化机制和事务没啥关系
不涉及隔离性：redis是单线程模型的服务器程序，所有的请求都是串行执行的
Redis的事务主要的意义就是为了"打包"，避免其他客户端的命令，插队插到中间
watch必须搭配事务使用，判断key的版本号是否被其他的客户端修改，才能正常设置
主从模式：
本来，在主节点保存一堆数据，引入从节点之后就是要把从节点上面的数据复制出来，放到从节点，后续主节点这边对于数据有任何修改都会把这样的修改给同步到从节点上
从节点上的数据不允许修改，只能读取数据
由于从节点的数据都是时刻和主节点保持一致的，因此其他客户端从从节点这里读取数据和从节点读取数据没有去别的，后续有客户端来读取数据就可以从上述节点随机挑一个节点来提供读取数据服务
1.先保存主节点的ip和端口
2.TCP的三次握手是为了验证通信双方是否能正确读写数据（系统层面）
3.验证主节点是否能正常工作
4.redis主节点开启密码
5.全量同步和增量同步
`PSYNC replicationid offset
主节点重启、从节点晋升为主节点，或是同一节点每次重启时，其replication ID 都会发生变化这一机制，从节点在和主节点建⽴连接之后,就会获取到主节点的replicationid
offset偏移量：标识在该基础版本上，数据同步的 "进度位置"，相当于看书的 "页码"
Redis 复制机制中，replid（复制 ID）和 offset（偏移量）的组合是唯一标识一个 "数据集版本" 的核心，只要两个节点的 replid 和 offset 完全相同，就说明它们的数据集是完全一致的
offset默认是-1，获取全量数据。写具体正整数则是从当前偏移量位置来进行获取
主节点回复+FULLRESYNC replid offset，则是全量复制流程
回复+CONTINEU则是从节点进行部分复制
全量复制:
-
发起同步请求 ：从节点首次复制时，因无主节点运行 ID 和复制偏移量，向主节点发送
psync ? -1命令； -
主节点响应全量复制 ：主节点解析命令后，判定为全量复制，回复
+FULLRESYNC响应（包含自身运行 ID 和当前复制偏移量）； -
从节点保存主节点信息：从节点接收并保存主节点返回的运行 ID 和偏移量；
-
主节点生成 RDB 文件 ：主节点执行
bgsave命令，异步生成 RDB 持久化文件； -
主节点发送 RDB 文件：主节点将生成的 RDB 文件发送给从节点，从节点将 RDB 数据保存到本地硬盘；
-
主节点缓存增量命令：主节点将生成 RDB 期间执行的写命令写入复制缓冲区，待从节点保存完 RDB 后，将缓冲区数据以 RDB 二进制格式补发至从节点，保证数据连续性；
-
从节点清理旧数据：从节点清空自身原有数据，避免新旧数据冲突；
-
从节点加载 RDB 文件：从节点加载本地保存的 RDB 文件，获取与主节点一致的数据；
-
从节点更新 AOF（可选） ：若从节点开启 AOF 持久化，加载完 RDB 后会执行
bgrewriteaof操作，生成最新的 AOF 文件Redis现在也支持无磁盘复制，主节点在执行RDB生成流程时直接把生成RDB数据通过网络发送给从结点，这样就节省了一些列读写硬盘的操作开销
部分复制 ：有时候从节点本身已经持有主节点的绝大部分数据，这个时候就不需要全量复制
-
断连判定 ：主从节点网络中断且超过
repl-timeout时间，主节点判定从节点故障，终止复制连接； -
命令缓存 ：断连期间主节点正常响应写命令，无法发送给从节点的命令暂存至复制积压缓冲区；
-
网络恢复重连：主从网络恢复后，从节点重新连接主节点；
-
发起增量复制请求 ：从节点将本地保存的
replicationId和复制偏移量作为参数，发送psync命令给主节点，请求部分（增量）复制； -
主节点验证与响应 ：主节点验证参数后，根据偏移量在复制积压缓冲区查找对应数据，回复
+CONTINUE确认增量复制； -
增量数据同步 ：主节点将缓冲区中从节点缺失的数据发送给从节点，完成主从数据一致性恢复。
复制积压缓冲区是主节点 上的一个固定大小的环形内存缓冲区 （默认 1MB，可通过
repl-backlog-size配置），专门用于缓存主从断连期间主节点接收的写命令，是实现主从增量复制的核心依赖。
实时复制 ：主从节点在建立复制连接后，主节点会把自己收到的修改操作，通过tcp长连接的方式，源源不断的传输给从节点，从节点就会根据这些请求来同时修改自身的数据，从而保持和主节点数据的一致性
长连接通过心跳包的方式来维护连接状态