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