1.redis单master架构的容量的瓶颈问题
单台redis的缓存容量毕竟有限，如果超出的话，只能使用内存淘汰清除最近最久未使用的数据了
2.redis如何通过master横向扩容支撑1T+数据量
3、redis的集群架构
redis cluster
支撑N个redis master node，每个master node都可以挂载多个slave node
读写分离的架构，对于每个master来说，写就写到master，然后读就从mater对应的slave去读
高可用，因为每个master都有salve节点，那么如果mater挂掉，redis cluster这套机制，就会自动将某个slave切换成master
redis cluster（多master + 读写分离 + 高可用）
我们只要基于redis cluster去搭建redis集群即可，不需要手工去搭建replication复制+主从架构+读写分离+哨兵集群+高可用
4、redis cluster 和 replication + sentinal哪个好
如果你的数据量很少，主要是承载高并发高性能的场景，比如你的缓存一般就几个G，单机足够了
replication，一个mater，多个slave，要几个slave跟你的要求的读吞吐量有关系，然后自己搭建一个sentinal集群，去保证redis主从架构的高可用性，就可以了
redis cluster，主要是针对海量数据+高并发+高可用的场景，海量数据，如果你的数据量很大，那么建议就用redis cluster
5.redis-cluster中最老土的hash算法和弊端（大量缓存重建）
解析：会有什么问题呢？假设有3台redis master节点，如果其中一台master宕机了，那么就会引发下面的问题：
①宕机的那台redis上的缓存数据全部丢失，如果客户端要访问这些数据就要全部打到mysql上去，数据库承受不了
②由于宕机之后redis master节点数减少，那么我们做对key的hash值取模的时候就由原来的“hash值%3”变成“hash值%2”，这样的话，其他正常存活的redis master都会受到影响，我们原本存的时候是按“hash值%3”存，但是取的时候是按“hash值%2”取，发生错乱
6、一致性hash算法（自动缓存迁移）+虚拟节点（自动负载均衡）
具体在计算一致性hash时采用如下步骤：
首先求出redis服务器（节点）的哈希值，并将其配置到0～232的圆（continuum）上。
然后采用同样的方法求出存储数据的键的哈希值，并映射到相同的圆上。
然后从数据映射到的位置开始顺时针查找，将数据保存到找到的第一个服务器上。如果超过232仍然找不到服务器，就会保存到第一台redis服务器上。
从上图的状态中添加一台redis服务器。余数分布式算法由于保存键的服务器会发生巨大变化而影响缓存的命中率，但Consistent Hashing中，只有在园（continuum）上增加服务器的地点顺时针方向的第一台服务器上的键会受到影响，如下图所示：
重点：只会影响插入节点的顺时针方向的下一个节点上的键
7、redis cluster的hash slot算法
redis cluster有固定的16384个hash slot，对每个key计算CRC16值，然后对16384取模，可以获取key对应的hash slot
redis cluster中每个master都会持有部分slot，比如有3个master，那么可能每个master持有5000多个hash slot
hash slot让node的增加和移除很简单，增加一个master，就将其他master的hash slot移动部分过去，减少一个master，就将它的hash slot移动到其他master上去
移动hash slot的成本是非常低的
客户端的api，可以对指定的数据，让他们走同一个hash slot，通过hash tag来实现
解析下图：假设redis02宕机了，那么也不会影响redis01和redis02，为什么呢？那是因为根据key的id找hash slot，而不是找redis机器，而redis01,03上的hash slot又没有变化，当然不会影响啊，这个时候由于redis02宕机，所以系统底层会把redis02上分配的hash slot转移到剩下的redis存活的机器上，整个redis cluster仍然可以对外提供服务
8、节点间的内部通信机制
9、面向集群的jedis内部实现原理
这是手动指定hash tag让key落到指定的hash slot中
10.高可用性与主备切换原理（重要）
