前言
Redis大家都不陌生，就算是没用过，也都听说过了。
作为最广泛使用的KV内存数据库之一，在当今的大流量时代，单机模式略显单薄，免不了要有一些拓展的方案。为最广泛使用的KV内存数据库之一，在当今的大流量时代，单机模式略显单薄，免不了要有一些拓展的方案。
笔者下文会对各种方案进行介绍，并且给出场景，实现 等等概述，还会提到一些新手常见的误区。
正文
先从基础的拓展方式开始，这样更便于理解较高级的模式。
分区
概述
分区(Partitioning)是一种最为简单的拓展方式。
在我们面临单机的存储空间瓶颈时，第一点就能想到像传统的关系型数据库一样，进行数据分区。
或者假设手中有N台机器可以作为Redis服务器
所有机器内存总和有256G, 而客户端正好也需要一个大内存的存储空间。
我们除了可以把内存条都拆下来焊到一个机器上，也可以选择分区使用，这样又拓展了计算能力。
单指分区来讲，即将全部数据分散在多个Redis实例中，每个实例不需要关联，可以是完全独立的。
使用方式
客户端处理
和传统的数据库分库分表一样，可以从key入手，先进行计算，找到对应数据存储的实例在进行操作。
范围角度，比如orderId:1orderId:1000放入实例1，orderId:1001orderId:2000放入实例2...
哈希计算，就像我们的hashmap一样，用hash函数加上位运算或者取模，高级玩法还有一致性Hash等操作，找到对应的实例进行操作
使用代理中间件
我们可以开发独立的代理中间件，屏蔽掉处理数据分片的逻辑，独立运行。
当然也有他人已经造好的轮子，Redis也有优秀的代理中间件，譬如Twemproxy，或者codis，可以结合场景选择是否使用。
缺点
无缘多key操作，key都不一定在一个实例上，那么多key操作或者多key事务自然是不支持。
维护成本，由于每个实例在物理和逻辑上，都属于单独的一个节点，缺乏统一管理。
灵活性有限，范围分片还好，比如hash+MOD这种方式，如果想动态调整Redis实例的数量，就要考虑大量数据迁移，这就非常麻烦了。
同为开发者，深知我们虽然总能“曲线救国”的完成一些当前环境不支持的功能，但是总归要麻烦一些。
主从
概述数据迁移
常说的主从(Master-Slave)，也就是复制(Replication)方式，怎么称呼都可以。
同上面的分区一样，也是Redis高可用架构的基础，新手可能会误以为这类基础模式即是“高可用”，这并不是十分正确的。
分区暂时能解决单点无法容纳的数据量问题，但是一个Key还是只在一个实例上，在大流量时代显得不那么可靠。
主从就是另一个纬度的拓展，节点将数据同步到从节点，就像将实例“分身”了一样，可靠性又提高了不少。
图画的有些夸张了，主要还是想体现结构灵活，是一主一从，还是一主多从，还是一主多从多从... 看你心情
有了“实例分身”，自然就可以做读写分离，将读流量均摊在各个从节点。
使用方式
高手云集的时代，聊天软件难免要备上这么一张表情包。
这表情包和使用方式有什么关系呢？首先看看使用方式：
作为主节点的Redis实例，并不要求配置任何参数，只需要正常启动
作为从节点的实例，使用配置文件或命令方式REPLICAOF 主节点Host 主节点port即可完成主从配置
是不是和表情包一样，“dalao”没动，我去“抱大腿”。
这样一个主从最小配置就完成了，主从实例即可对外提供服务。
命令里的“主节点”是相对的，slave也可以抱slave大腿，也就是上文提到的结构灵活。
缺点
slave节点都是只读的，如果写流量大的场景，就有些力不从心了。 那我把slave节点只读关掉不就行了？当然不行，数据复制是由主到从，从节点独有数据同步不到主节点，数据就不一致了。
故障转移不友好，主节点挂掉后，写处理就无处安放，需要手工的设定新的主节点，如使用REPLICAOF no one(谁大腿我都不抱了) 晋升为主节点，再梳理其他slave节点的新主配置，相对来说比较麻烦。
哨兵
概述
主从的手工故障转移，肯定让人很难接受，自然就出现了高可用方案-哨兵（Sentinel）。
我们可以在主从架构不变的场景，直接加入Redis Sentinel，对节点进行监控，来完成自动的故障发现与转移。
并且还能够充当配置提供者，提供主节点的信息，就算发生了故障转移，也能提供正确的地址。
哨兵本身也是Redis实例的一种，但不作为数据存储方使用，启动命令也是不一样的。
虽然图有些复杂，看起来像要召唤光能使者。
其实实际使用起来是很便捷的。
使用方式
