Question

RESP 协议

Redis 的协议规范是 Redis Serialization Protocol (Redis 序列化协议)。

该协议是用于与 Redis 服务器通信的，用的较多的是 Redis-cli 通过 pipe 与 Redis 服务器联系。

协议如下：

• 客户端以规定格式的形式发送命令给服务器；
• 服务器在执行最后一条命令后，返回结果。

客户端发送命令的格式（类型)：5 种类型（由第一个字节决定）

间隔符号，在 Linux 下是 \r\n ，在 Windows 下是 \n

+ 代表简单字符串
- 代表错误字符串
:  代表整数字符串
$ 代表块字符串
* 代表数组

Redis 持久化

Redis 提供了 RDB 与 AOF 等多种不同级别的持久化方式。

表格 5 Redis 持久化 RDB 和 AOF 比较

	RDB (Redis DataBase)	AOF (Append Only File)
原理	可以在指定的时间间隔内生成数据集的时间点快照（point-in-time snapshot）。二种方式：1. 手动执行持久化数据命令来让 redis 进行一次数据快照。命令： save/bgsave save：save 操作在 Redis 主线程中工作，因此会阻塞其他请求操作，应该避免使用。bgsave：调用 Fork，产生子进程，父进程继续处理请求。2. 根据你所配置的配置文件 的 策略，达到策略的某些条件时来自动持久化数据。	记录服务器执行的所有写操作命令。 AOF 文件（ appendonly.aof ）中的命令全部以 Redis 协议的格式来保存，新命令会被追加到文件的末尾。 Redis 还可以在后台对 AOF 文件进行重写，使得 AOF 文件的体积不会超出保存数据集状态所需的实际大小。
存储文件	dump.rdb	appendonly.aof
重启读取	redis 重启后，自动读取 dump.rdb 文件。	服务器启动时，通过重新执行 appendonly.aof 文件中写命令来还原数据集。
缺省配置策略	save 900 # 每 900 秒变化 1+键值做快照 save 300 3 # 每 300 秒变化 3+键值 save 60 10000 # 每 50 秒变化 1 万+键值	# 三个选择：everysync~每秒, no~, always~appendonly yes appendsync everysync
缺省	通常情况下一千万的字符串类型键，1GB 的快照文件，同步到内存中的 时间是 20-30 秒）。
优点	RDB 恢复数据时更快，可以最大化 redis 性能，子进程对父进程无任何性能影响。	AOF 有序的记录了 redis 的命令操作。意外情况下数据丢失甚少。
缺点	数据丢失比 AOF 严重

备注：Redis 可以同时使用 AOF 持久化和 RDB 持久化。在这种情况下，当 Redis 重启时，它会优先使用 AOF 文件来还原数据集，因为 AOF 文件保存的数据集通常比 RDB 文件所保存的数据集更完整。用户也可以关闭持久化功能，让数据只在服务器运行时存在。

Redis 的哈希槽

Redis 集群并没有使用一致性 hash，而是引入了哈希槽的概念。Redis 集群有 16384 个哈希槽，每个 key 通过 CRC16 校验后对 16384 取模来决定放置哪个槽，集群的每个节点负责一部分 hash 槽。

在 redis 节点发送心跳包时需要把所有的槽放到这个心跳包里，以便让节点知道当前集群信息，16384=16k，在发送心跳包时使用 bitmap 压缩后是 2k（2 * 8 (8 bit) * 1024(1k) = 2K），也就是说使用 2k 的空间创建了 16k 的槽数。

虽然使用 CRC16 算法最多可以分配 65535（2^16-1）个槽位，65535=65k，压缩后就是 8k（8 * 8 (8 bit) * 1024(1k) = 8K），也就是说需要需要 8k 的心跳包，作者认为这样做不太值得；并且一般情况下一个 redis 集群不会有超过 1000 个 master 节点，所以 16k 的 槽位是个比较合适的选择。