高可用：

  主从

    哨兵：sentinel： 集群监控 消息通知 故障转移 配置中心

redis cluster ：livu livechat中使用了

 人家有槽slot 16384个呢 请求发送任意节点 该节点会将请求发送到正确节点上-相亲相爱

    1.哈希的方式，将数据分片 每个节点均分存储一定哈希槽区间的数据

    2.每份数据分片会存储在多个互为主从的多节点上

    3.先写主节点再同步从节点

    4.读取数据，当客户端操作的key没有分配在该节点，返回转向指令，指向正确节点

    5.扩容时需要把旧节点的数据迁移一部分到新节点

    6.每个redis放开两个端口，6379 16379，16379节点间通信，cluster bus，故障检测/转移

    7.cluster bus用gossip二进制协议，节点间高效数据交换，占用更少的网络带宽和处理时间

无中心架构，支持动态扩容，对业务透明

自备sentinel监控和自动failover故障转移能力

高性能，直连redis服务 免去proxy损耗

有点缺：人无完人 redis无完美  怎么说：反正有缺点但是值得

    运维复杂 数据迁移需要人工 只能使用0号数据库 不支持批量操作 分布式逻辑和存储模块耦合

redis sharding：你可以不看  让我自己卷

多redis实例集群，采用哈希算法将redis的key进行散列，映射到特定的redis节点

   简单，服务端redis实例彼此独立，相互无关联，每个redis实例像单服务器一样 线性扩展

   不支持动态删增节点，服务器redis实例群拓扑结构变化，每个客户更新调整 连接不共享 

三大热门问题：还行 咱家项目设计稳稳当当 上学的时候遇到过一次

缓存穿透：缓存 数据库都没有的数据，库短时间内承受大量请求

    接口层校验，缓存取不到库中也没有，可key-null 短的过期时间，布隆过滤器bitmap中

缓存击穿：缓存中没有库中有，并发查同一条数据

    热点永不过期，互斥锁

缓存雪崩：一瞬间大面积失效

    设置随机过期时间/新增缓存标记是否失效/缓存预热/互斥锁

一致性：

写不太频繁：

1，操作缓存 设置过期标识 客户端读缓存过期则休眠再查redis

2，先删缓存，看他不顺眼直接删了！再写数据库，休眠 再删缓存

主从同步

1 从节点slaveof masterip port 保存主节点信息

2 从节点定时任务发现主节点，建立和主节点socket连接

3 从发送信号 主返回 互相私通 呸 私信，连接建立 主all数据发送给从

runid：每个redis节点启动生成唯一标识uuid

offset：主从各自维护自己的复制偏移量，主也写offset=offset+命令字节长度，从收到主发送命令后，增加自己的offset，把自己的offset发送给主节点，主节点同时保存自己的offset和从的，对比判断主从一致性数据

 

repl_backlog_size：主节点上固定长度的先进先出队列1M