2021-03-25

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.主节点宕机时，有可能有未同步的数据到从节点中，选举新的主节点后，旧的主节 点恢复过来，变为新主节点的从节点，未同步的数据就会丢失掉。