FeeLing

一般并发下上万人并发操作的读写如下：存在的问题：遇到写请求时，可用先删除缓存数据，再更新数据库，这样不管数据库更新失败还是缓存删除失败，缓存与数据库始终一致。这种方案一般可满足上万人并发操作了，因为删除缓存到更新数据库的时间可以用毫秒计算，正常的并发影响不大。但如果是达到上亿级访问，在这时间段内，会出现读请求在写请求更新数据库之前执行，导致数据库与缓存不一致亿级并发场景淘宝双11活动，抢购商品，商品数量为100，当前状态是数据库和缓存都是100，这时上亿账户抢购该商品，商品数

结构去中心化：每个master只存储一部分数据任何两个master都是相通的，客户端访问当任意节点就可与集群中的任何master连接集群的寻址模式，扩容/缩容方式哈希槽缺点不支持批量操作(pipeline管道操作)...

分布式寻址算法hash 算法（大量缓存重建） 一致性 hash 算法（自动缓存迁移）+ 虚拟节点（自动负载均衡） redis cluster 的 hash slot 算法简单hash算法只要集群数量N发生变化，之前所有的hash映射全部失效，缓存全部失效一致性哈希算法+虚拟节点一致性哈希算法假设有3个node 增加一个Node4，只会使Node2和Node4之间缓存失效，其他数据正常 删除一个Node1，只会使Node2和Node1之间缓存失效，其他数据正常数据倾斜

主从模式不支持高可用Redis的主从复制模式下， 一旦主节点由于故障不能提供服务， 需要人工将从节点晋升为主节点， 同时还要通知应用方更新主节点地址， 对于很多应用场景这种故障处理的方式是无法接受的。 可喜的是Redis从2.8开始正式提供了Redis Sentinel（哨兵） 架构来解决这个问题。总结：Redis主从复制的缺点：没有办法对master进行动态选举，需要使用Sentinel机制完成动态选举结构哨兵哨兵的作用哨兵是 redis 集群机构中非常重要的一个组件，具

结构一主一从用于主节点故障转移从节点，当主节点的“写”命令并发高且需要持久化，可以只在从节点开启AOF一主多从针对“读”较多的场景，“读”由多个从节点来分担，但节点越多，主节点同步到多节点的次数也越多，影响带宽，也加重主节点的稳定树状主从减轻主节点推送的压力数据同步机制2.7版本之后采用全量复制、增量复制全量复制：初次复制时（第一次建立SLAVE） slave启动并连接到master，向master发送一个sync命令 master以RDB的方式全...