Redis：
slot
在redis集群内部，采用slot槽位的逻辑管理方式， 集群内部共有16384(2的14次方)个Slot，集群内每个Redis Instance负责其中一部分的Slot的读写。一个Key到底属于哪个Slot，由分片算法：
crc16(key) % 16384
决定。也正是通过此分片算法，将不同的key以相对均匀的方式分配到不同的slot上。
watch：当执行多键值事务操作时，Redis不仅要求这些键值需要落在同一个Redis实例上，还要求落在同一个slot上。
官方介绍MULTI 、 EXEC 、 DISCARD 和 WATCH 是 Redis 事务相关的命令，事务可以一次执行多个命令，但是必须满足2个条件：
事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。 事务是一个原子操作：事务中的命令要么全部被执行，要么全部都不执行。执行和是否成功是2个概念，并不是一个失败报错等，其他就失败。redis对事务是部分支持。如果最开始语法等就有提交错误，就相当于java的编译器都过不了，那么肯定全部不执行。如果在执行过程中报错，已经全部执行了，但是谁报错找谁，其他正常执行放行。各取所需！这里的事务并不是要么全部成功，要么全部失败，全部执行和全部成功（或者都失败）是2个概念。
hashtag
Hash Tag原理是：当一个key包含 {} 的时候，不对整个key做hash，而仅对 {}包括的字符串做hash。
Hash Tag可以让不同的key拥有相同的hash值，从而分配在同一个槽里；这样针对不同key的批量操作(mget/mset等)，以及事务、Lua脚本等都可以支持。不过Hash Tag可能会带来数据分配不均的问题，这时需要：(1)调整不同节点中槽的数量，使数据分布尽量均匀；(2)避免对热点数据使用Hash Tag，导致请求分布不均。
bigkey
- 涉及到bigkey的操作，网卡会成为瓶颈
- 若需要删除bigkey，直接del，被操作的实例可能会直接卡死
- 业务上对bigkey取余，将数据分散，避免生成bigkey
高可用
主从复制
- 一台redis服务的数据，复制到多台redis服务器。前者称为主节点，后者为从节点
- 数据的复制是单向的，只能从主节点复制到从节点
-
作用：
- 数据冗余：实现了数据的热备份，是持久化之外的数据冗余方式
- 故障恢复：主节点失效，丛节点提供服务
- 负载均衡：实现读写分离，主节点写，丛节点读
- 高可用的基础：主从复制是哨兵和集群模式能够实施的基础
-
数据同步：
- 主从节点连接建立后，便开始数据同步。
- 根据主从节点当前状态，分为全量和部分复制
- 具体执行方式：从节点朝主节点发送psync命令，开始同步
-
命令传播：
主从数据同步完成后，主节点将自己执行的写命令发送给丛节点（该过程是异步的），保证数据的一致性。
哨兵
- 能够自动完成故障发现和转移，从而实现高可用
- 由一组哨兵节点和一组（或多组）主从复制节点组成
- 心跳机制
- 故障转移
- 每个 Sentinel 都会定时进行心跳检查，当发现主节点出现心跳检测超时的情况时，此时认为该主节点已经不可用，这种判定称为主观下线。
- 哨兵节点开始投票，当超过半数认为该主节点故障，会将其下线：基于raft算法，选取一个哨兵节点来执行该过程
- 选取一个从节点作为主节点，将其他从节点和该节点绑定
- 原来的主节点更新为从节点，对其监控，等恢复后，命令其去复制新的主节点
cluster集群
- 由多个主从复制的结构组成
- 每个主从复制的结构看做一个节点
