1.REDIS集群
普通hash算法:假设有3台master主机,所有键值对的hash值取值范围为30000(具体是多少不清楚),那么用第k台机器的所有键值就是10000*(k-1) ~ 10000*k。一旦有一个机器挂掉,那么去获取hash值为200时,就会去第(200%(3-1))=0个机器上去,显然是去不到的,因为它本来是存在第(200%3)=2个机器上。
一致性hash算法:假设有3台master主机,所有键值对的hash值取值范围为30000(具体是多少不清楚)。分布如下图。
A节点的hash值为:{0-3333,10001-13333,20001-23333}
B节点的hash值为:{3334-6666,13334-16666,23334-26666}
C节点的hash值为:{6667-10000,16667-20000,26667-30000}
该图采用了虚拟节点。不仅解决了热点问题,而且还容易扩展。比如再需要插入一个主节点D,结果如下图:
当然主机挂掉的可能性比较小,但是为了避免这种情况,REDIS支持集群配置。
REDIS的数据如何保证不丢:
1.开启RDB(快照)bgsave 300 10,300秒内有10个键值发送变化就触发,
Save是同步,bgsave是异步,生产环境用bgsave,要不然影响性能
2.开启AOF(指令)appendonly yes(开启),appendfsync everysec(每秒同步一次)
服务重启时AOF优先加载。RDB相当于数据库备份,当AOF不能用时就可以使用, 好过没有。
3.设置与从节点的连接数量,少于这个数量就禁止写入。min-replicas-to-write 3, min-replicas-max-lag 10,第一个参数表示最少的salve节点为3个,第二个参数表 示数据复制和同步的延迟不能超过10秒,配置了这两个参数:如果发生脑裂:原 master会在客户端写入操作的时候拒绝请求。这样可以避免大量数据丢失。
4.主节点宕机时,有可能有未同步的数据到从节点中,选举新的主节点后,旧的主节 点恢复过来,变为新主节点的从节点,未同步的数据就会丢失掉。