写在文章之前
上一篇redis文章主要是介绍了redis的基本概念和底层原理，这一篇着重于redis的数据淘汰策略和集群方案。
Redis 有哪几种数据淘汰策略？
1.noeviction:返回错误当内存限制达到，并且客户端尝试执行会让更多内存被使用的命令。
2.allkeys-lru: 尝试回收最少使用的键（LRU），使得新添加的数据有空间存放。
3.volatile-lru: 尝试回收最少使用的键（LRU），但仅限于在过期集合的键,使得新添加的数据有空间存放。
4.allkeys-random: 回收随机的键使得新添加的数据有空间存放。
5.volatile-random: 回收随机的键使得新添加的数据有空间存放，但仅限于在过期集合的键。
6.volatile-ttl: 回收在过期集合的键，并且优先回收存活时间（TTL）较短的键,使得新添加的数据有空间存放。
Redis 回收进程如何工作的？
一个客户端运行了新的命令，添加了新的数据。Redi 检查内存使用情况，如果大于 maxmemory 的限制, 则根据设定好的策略进行回收。
所以我们不断地穿越内存限制的边界，通过不断达到边界然后不断地回收回到边界以下。如果一个命令的结果导致大量内存被使用（例如很大的集合的交集保存到一个新的键），不用多久内存限制就会被这个内存使用量超越。
Redis 哈希槽的概念？
Redis 集群没有使用一致性 hash,而是引入了哈希槽的概念，Redis 集群有 16384 个哈希槽，每个 key 通过 CRC16 校验后对 16384 取模来决定放置哪个槽，集群的每个节点负责一部分hash 槽。
Redis 集群方案
1、 主从高可用（该方案就是单实例形式，只是为了保证数据的安全，对于用户数据少，业务的前期可以采用）
2、 客户端分片（典型代表：Jedis。自主写分片算法，代码掌握在自己手中，可控性强，但是需要专业的开发运维人员维护，技术要求和维护成本高）
3、代理分片（典型代表：Twemproxy，redis集群没有正式推出之前官网推荐的方案，也是目前使用最多的）
4、 Redis cluster（redis cluster3.0 自带的集群，特点在于他的分布式算法不是一致性 hash，而是 hash 槽的概念，以及自身支持节点设置从节点。）
5、 Codis集群（基本和 Twemproxy 一致的效果，但它支持在 节点数量改变情况下，旧节点数据可恢复到新 hash 节点。）
主从拓扑
Redis的主从拓扑支持单层或者多层结构，可分为一主一从，一主多从，树状主从。
**(1).一主一从：**用于主节点故障转移从节点，当主节点的“写”命令并发高且需要持久化，可以只在从节点开启AOF（主节点不需要），这样即保证了数据的安全性，也避免持久化对主节点的影响。
**(2).一主多从：**针对“读”较多的场景，“读”由多个从节点来分担，但节点越多，主节点同步到多节点的次数也越多，影响带宽，也加重主节点的负担。
**(3).树状主从：**一主多从的缺点（主节点推送次数多压力大）可用些方案解决，主节点只推送一次数据到从节点1，再由从节点2推送到11，减轻主节点推送的压力。
主从切换技术的方法是：当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工干预，费事费力，还会造成一段时间内服务不可用。这不是一种推荐的方式，更多时候，我们优先考虑哨兵模式。
哨兵模式概述
哨兵模式是一种特殊的模式，首先Redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独立运行。其原理是哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例。
**哨兵的原理：**Redis哨兵的三个定时任务，Redis哨兵判定一个Redis节点故障不可达主要就是通过三个定时监控任务来完成的：
- 每隔10秒每个哨兵节点会向主节点和从节点发送
"info replication"命令来获取最新的拓扑结构
- 每隔2秒每个哨兵节点会向Redis节点的
_sentinel_:hello频道发送自己对主节点是否故障的判断以及自身的节点信息，并且其他的哨兵节点也会订阅这个频道来了解其他哨兵节点的信息以及对主节点的判断
- 每隔1秒每个哨兵会向主节点、从节点、其他的哨兵节点发送一个
“ping”命令来做心跳检测
这里的哨兵有两个作用
- 通过发送命令，让Redis服务器返回监控其运行状态，包括主服务器和从服务器。
- 当哨兵监测到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换主机。
然而一个哨兵进程对Redis服务器进行监控，可能会出现问题，为此，我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控，这样就形成了多哨兵模式。
用文字描述一下故障切换（failover）的过程。假设主服务器宕机，哨兵1先检测到这个结果，系统并不会马上进行failover过程，仅仅是哨兵1主观的认为主服务器不可用，这个现象成为主观下线。当后面的哨兵也检测到主服务器不可用，并且数量达到一定值时，那么哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行failover操作。切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为客观下线。这样对于客户端而言，一切都是透明的。
codis架构
简单说明：
1、codis-proxy提供连接集群redis的服务入口
2、codis-config管理工具，支持包括添加/删除redis/proxy节点，发起数据迁移等操 作，自带一个dashboard工具，浏览器可以直观查看集群的运行状态
3、codis-server-group实现redis读写的水平扩展、高性能
4、codis-server实现redis实例服务，通过codis-ha实现服务的高可用
5、Zookeeper/etcd存放数据路由表和codis-proxy节点的元信息，codis-config发起的命令通过其同步到各个存活的codis-proxy，则zookeeper如果出问题则可能导致数据不一致的情况或者严重的会对外提供服务造成影响
Twemproxy架构
Twemproxy，大概概念是，它类似于一个代理方式，使用方法和普通 redis 无任何区别，设置好它下属的多个 redis 实例后，使用时在本需要连接 redis 的地方改为连接 Twemproxy，它会以一个代理的身份接收请求并使用一致性 hash 算法，将请求转接到具体 redis，将结果再返回 Twemproxy。
使用方式简便(相对 redis 只需修改连接端口)，对旧项目扩展的首选。
问题：Twemproxy 自身单端口实例的压力，使用一致性 hash 后，对 redis 节点数量改变时候的计算值的改变，数据无法自动移动到新的节点。
简单说明：
1、proxy提供分片算法和redis服务入口，支持高可用
2、Redis提供实现实例，并且通过sentinel支持高可用
3、Redis-Twemporxy提供通知底层HA切换至proxy
4、每个层结构出现问题或者变更节点信息等所有操作都需要重新规划分片算法，则需要重启服务
redis-cluster架构
简单说明：
1、redis cluster本身集群方案，客户端可以任一连接一个节点
2、redis-trib.rb脚本为集群的管理工具，比如自动添加节点，规划槽位，迁移数据等一系列操作（ruby语言）
3、每个节点都和N-1个节点通信，所以要维护好这个集群架构的每个节点信息，不然会导致整个集群不可工作
尾声
“每个人的生活都是一条通向自身的道路。每个人的真正职责只有一个：找到自我。然后在心中坚守一生，全心全意，永不停息。所有其它的路都是不完整的，是人的逃避方式，是对社会角色的懦弱伪装，是随波逐流，是对内心的恐惧。” ——《前方的路》
参考文章：
链接：https://www.cnblogs.com/caicz/p/10797167.html 作者：菜菜
链接：https://www.jianshu.com/p/c2abf726acc7 作者：千淘萬漉
链接：https://www.jianshu.com/p/06ab9daf921d 作者：秃头哥编程