From 8cc62eb4410ebd14bc98baf850ae464be25ca712 Mon Sep 17 00:00:00 2001
From: yuanguangxin <274841922@qq.com>
Date: Tue, 13 Oct 2020 02:28:35 +0800
Subject: [PATCH] update

---
 Rocket.md | 22 ++++++++++++++++++++--
 1 file changed, 20 insertions(+), 2 deletions(-)

diff --git a/Rocket.md b/Rocket.md
index e0c3bbc..288ae45 100644
--- a/Rocket.md
+++ b/Rocket.md
@@ -149,14 +149,32 @@ Redis默认是快照RDB的持久化方式。对于主从同步来说，主从刚
 3. 用底层模型不同：它们之间底层实现方式以及与客户端之间通信的应用协议不一样。redis直接自己构建了VM机制，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求。
 4. value的大小：redis可以达到1GB，而memcache只有1MB。
 
-### Redis的哨兵机制
+### Redis的几种集群模式
 
-哨兵是一个分布式系统,你可以在一个架构中运行多个哨兵进程,这些进程使用流言协议来接收关于Master是否下线的信息,并使用投票协议来决定是否执行自动故障迁移,以及选择哪个Slave作为新的Master。
+1. 主从复制
+2. 哨兵模式
+3. cluster模式
+
+### Redis的哨兵模式
+
+哨兵是一个分布式系统,在主从复制的基础上你可以在一个架构中运行多个哨兵进程,这些进程使用流言协议来接收关于Master是否下线的信息,并使用投票协议来决定是否执行自动故障迁移,以及选择哪个Slave作为新的Master。
 
 每个哨兵会向其它哨兵、master、slave定时发送消息,以确认对方是否活着,如果发现对方在指定时间(可配置)内未回应,则暂时认为对方已挂(所谓的”主观认为宕机”)。
 
 若“哨兵群“中的多数sentinel,都报告某一master没响应,系统才认为该master"彻底死亡"(即:客观上的真正down机),通过一定的vote算法,从剩下的slave节点中,选一台提升为master,然后自动修改相关配置。
 
+### Redis的rehash
+
+Redis的rehash 操作并不是一次性、集中式完成的，而是分多次、渐进式地完成的，redis会维护维持一个索引计数器变量rehashidx来表示rehash的进度。
+
+这种渐进式的 rehash 避免了集中式rehash带来的庞大计算量和内存操作，但是需要注意的是redis在进行rehash的时候，正常的访问请求可能需要做多要访问两次hashtable（ht[0]， ht[1]），例如键值被rehash到新ht1，则需要先访问ht0，如果ht0中找不到，则去ht1中找。
+
+### Redis的hash表被扩展的条件
+
+1. 哈希表中保存的key数量超过了哈希表的大小.
+2. Redis服务器目前没有在执行BGSAVE命令（rdb）或BGREWRITEAOF命令，并且哈希表的负载因子大于等于1.
+3. Redis服务器目前在执行BGSAVE命令（rdb）或BGREWRITEAOF命令，并且哈希表的负载因子大于等于5.(负载因子=哈希表已保存节点数量 / 哈希表大小，当哈希表的负载因子小于0.1时，对哈希表执行收缩操作。)
+
 ### Redis并发竞争key的解决方案
 
 1. 分布式锁+时间戳