先来一个引言，比较宏观的角度，先不考虑细节问题（先不谈理论，按照正常的发展思路，看看需要解决哪些问题，于是衍生出哪些技术）：
Redis是一款内存数据库，这个数据存储在内存中，如果说突然发生意外，Redis主机断电了宕机了，那么内存中的数据就丢失掉了。所以我们需要像个办法解决由于断电、宕机导致的Redis在内存当中的数据丢失性问题？
你说，我们可以从新从MySQL后端数据库来恢复，但是这样太慢了，几乎就是从头开始。我们是否可以在 Redis 本机所在机器上永久的保存数据？
所以我们需要持久化的技术来解决。要持久化，就意味着数据必须保存到非易失性存储介质磁盘上。（AOF写操作日志、RDB内存快照持久化机制）。
这样子，就不担心这个数据丢失了。
但是，如果Redis发生了宕机，我们虽然有持久化，可以进行数据恢复，但是恢复是需要一定时间的，恢复的过程就没法对外提供服务，这显然也是不可接受的。
所以，我们需要解决在主要节点数据恢复期间还可以正常对外提供服务的问题？ (主从复制)
我们就可以搞多个服务节点嘛，一个服务节点挂掉了，可以让其他服务节点继续提供嘛。如果这些服务节点有一个Boss 节点，其他的服务节点都是从Boss节点这里copy来的。Boss节点同步跟新这些子节点。如果是子节点挂掉，其实影响并不大，如果Boss节点挂掉，这个影响就特别大。
所以，我们需要解决在这个Boss节点挂掉的情况下，从下属节点中从新选拔一个Boss出来？(手动主从切换 ---》 自动主从切换)
选这个节点那肯定是跟 Boss 关系最近，最像的。（涉及一个选举问题）
这些都是单个Redis实例之上的问题，如果说一个Redis实例太大了。会不会出现许多问题？比如说持久化产生的文件AOF，RDB会不会特别大？太大了，这个恢复过程会不会特别缓慢，多个节点从Boss主节点那里copy代价会不会变大？
要解决这个问题，我们是不是可以想到把数据分摊到多个 Redis 实例上面去，做一个分流。当然可以。不过需要考虑很多问题。负载均衡的问题，还有这个数据分片的问题。我们把整个需要缓存的数据切开多份。
每一份如何对应给Redis实例？用什么算法去对应？
我首先可以想到的就是Hash，因为hash天然对应很多槽位。我们可以对数据的key值进行Hash运算、映射到槽位，槽位是固定的。我们可以把槽位分配给Redis主机。
再思考一下，当我们维护多实例的时候，必不可少的需要通信，所以实例与实例之间应该依赖什么来进行通信，来达到一个状态的同步，一致性。这必然也是需要解决的问题。但是小杰这块尚且无法理解。所以慢慢沉淀。
如下这些标题，就是小杰之后写这个博客后续要完成的，现在只是写出自己的一个规划目录。后续再驱动性、方向性的步步完成。