[缓存] - Redis
1. 高性能
尽量使用短key
不要存过大的数据
避免使用keys *：使用SCAN,来代替
在存到Redis之前压缩数据
设置 key 有效期
选择回收策略(maxmemory-policy)
减少不必要的连接
限制redis的内存大小（防止swap，OOM）
slowLog
使用pipline批量操作数据
2. 高可用
2.1 单机版的高可用
数据持久化：AOF(WAL) & RDB
2.2 Replication-Sentinel模式
也就是哨兵模式。哨兵能对节点进行监控，提醒，自动故障迁移。
缺点：主从模式，切换需要时间，可能会丢数据，而且没有解决 master 写的压力；存储性能没办法横向扩展。
适用场景：缓存大小<10G时建议使用一主多从的哨兵模式。 从节点的数量，根据qps来扩展，比如10WQPS，可以有3-4个从节点（只能提高读操作的qps，写的qps不能扩展）。
架构图：
2.3 Redis-Cluster模式
redis在3.0上加入了 Cluster 集群模式，实现了 Redis 的分布式存储，也就是说每台 Redis 节点上存储不同的数据。
Gossip协议维护节点的元数据信息，进行节点间的信息同步。P2P去中心化的模式。最终一致性。
每个分区有一个master和若干slaver组成。
缺点：对于大型集群来说， 例如200 个使用 3.2.8 版本节点搭建的 Redis 集群，在没有任何客户端请求的情况下，每个节点仍然会产生 40Mb/s 的流量（gossip协议）， 不建议使用官方的 Redis Cluster。
适用场景：如果系统的缓存大小<2000G， 主节点数<200个，建议使用Redis Cluster模式
2.4 Proxy模式
适用于主节点数量 > 200的情况下。有Codis Proxy和Twemproxy Proxy来年各种中间件模式。
数据分片算法：
（1）Codis 代理分片
（2）Twemproxy 代理分片
2.4.1 数据分片
（1）Range分片
常用在关系型数据库的设计。
比如：1到100个数字，要保存在3个节点上，按照顺序分区，把数据平均分配成三个片段
-
1号到33号数据为 片段1
-
34号到66号数据为 片段2
-
67号到100号数据为 片段3
（2）节点取余分片
比如有100个数据，对每个数据进行hash运算之后，与节点数进行取余运算，根据余数不同保存在不同的节点上。
缺点：
当增加或减少节点时，原来节点中的80%的数据会进行迁移操作，对所有数据重新进行分片。
建议：
建议使用多倍扩容的方式，例如以前用3个节点保存数据，扩容为比以前多一倍的节点即6个节点来保存数据，这样只需要适移50%的数据。
数据迁移之后，第一次无法从缓存中读取数据，必须先从数据库中读取数据，然后回写到缓存中，然后才能从缓存中读取迁移之后的数据。
（3）一致性哈希分区
步骤：构造一致性哈希环、节点映射、路由规则。
1）构造一致性哈希环
通过哈希算法，将哈希值映射到哈希空间（[0, 2^32]）。
2）节点映射
将集群中的各节点映射到环上的某个一位置。比如集群中有三个节点，那么可以大致均匀的将其分布在环上。
3）路由规则
路由规则包括存储（setX）和取值（getX）规则。
当需要存储一个对时，首先计算键key的hash值：hash(key)，这个hash值必然对应于一致性hash环上的某个位置，然后沿着这个值按顺时针找到第一个节点，并将该键值对存储在该节点上。
缺点：数据倾斜，不能对所有节点进行负载均衡
（4）虚拟槽分区
为了在增删节点的时候，各节点能够保持动态的均衡，将每个真实节点虚拟出若干个虚拟节点，再将这些虚拟节点随机映射到环上。此时每个真实节点不再映射到环上，真实节点只是用来存储键值对，它负责接应各自的一组环上虚拟节点。当对键值对进行存取路由时，首先路由到虚拟节点上，再由虚拟节点找到真实的节点。增加虚拟节点其实是减小了路由规则过程中的粒度，使每个真实节点可以分摊局部压力。
（5）Redis分区
槽位，共16384个槽位。
所有的键根据哈希函数映射到0 ～ 16383，计算公式：slot = CRC16(key)&16383。
3. 主从复制
哨兵模式和集群模式，都需要进行主从复制。
核心流程：
建立连接，数据同步，命令传播
4. 分布式缓存的常见问题
4.1 缓存击穿
定义：缓存击穿是指热点key在某个时间点过期的时候，而恰好在这个时间点对这个Key有大量的并发请求过来，从而大量的请求打到db。
解决方案：
- 设置热点数据永远不过期。
- 采用多级缓存架构，热点数据，肯定数据量不大，可以使用 本地缓存
- 如果过期则或者在快过期之前更新，如有变化，主动刷新缓存数据，同时也能保障数据一致性。
4.2 缓存穿透
定义：缓存穿透是指查询一个一定不存在的数据，由于缓存是不命中时需要从数据库查询，查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到数据库去查询，进而给数据库带来压力。
解决方案：
1、**接口校验。**在正常业务流程中可能会存在少量访问不存在 key 的情况，但是一般不会出现大量的情况，所以这种场景最大的可能性是遭受了非法攻击。可以在最外层先做一层校验：用户鉴权、数据合法性校验等，例如商品查询中，商品的ID是正整数，则可以直接对非正整数直接过滤等等。
2、缓存空值。当访问缓存和DB都没有查询到值时，可以将空值写进缓存，但是设置较短的过期时间，该时间需要根据产品业务特性来设置。
3、hashmap 记录存在性，存在去查redis，不存在直接返回。
4、布隆过滤器。使用布隆过滤器存储所有可能访问的 key，不存在的 key 直接被过滤，存在的 key 则再进一步查询缓存和数据库。
4.3 缓存雪崩
定义：缓存雪崩是指缓存中数据大批量到过期时间，而查询数据量巨大，引起数据库压力过大甚至down机。
解决方案：过期时间打散，热点数据不过期
4.4 缓存一致性
binlog，程序（mq）