Memcached/redis是高性能的分布式内存缓存服务器,通过缓存数据库查询结果，减少数据库访问次数，以提高动态Web等应用的速度、提高可扩展性。

缓存服务器作用: 加快访问速度 ,缓解数据库压力

1. memcached（单节点在用）

1.1 特点

1.内置内存存储方式-----------为了提高性能，memcached中保存的数据都存储在memcache内置的内存存储空间中。由于数据仅存在于内存中，重启操作系统会导致全部数据消失
2.简单key/value存储---------------服务器不关心数据本身的意义及结构，存储项由“键、过期时间、可选的标志及数据”四个部分组成；可以设置过期时间
3.不互相通信的分布式 ------------- memcached尽管是“分布式”缓存服务器，但服务器端并没有分布式功能。各个memcached不会互相通信以共享信息。那么，怎样进行分布式呢？这完全取决于客户端的实现。---首先向memcached中添加“tokyo”。将“tokyo”传给客户端程序库后，客户端实现的算法就会根据“键”来决定保存数据的memcached服务器。服务器选定后，即命令它保存“tokyo”及其值。独立的

　Tokyo Tyrant 是由同一作者开发的 Tokyo Cabinet 数据库网络接口。它拥有Memcached兼容协议

1.2 原理

1、检查客户端的请求数据是否在memcached中，如有，直接把请求数据返回，不再对数据库进行任何操作，路径操作为①②③⑦。
2、如果请求的数据不在memcached中，就去查数据库，把从数据库中获取的数据返回给客户端，同时把数据缓存一份到memcached中（memcached客户端不负责，需要程序明确实现），路径操作为①②④⑤⑦⑥。

1.3 缺点

存储的数据类型单一，而且数据只能存储在内存中。无法实现数据的持久化，服务器重启，数据将消失

2. redis服务

redis是一个开源的、使用C语言编写的、可基于内存也可持久化的Key-Value数据库，采用单线程基于epoll模型实现IO多路复用非阻塞的处理模式。性能高

2.1 redis的特点：

1.丰富的数据结构 -----Redis支持五种数据类型：string（字符串），hash（哈希），list（列表），set（集合：有序和无序）及zset(sorted set：有序集合)等数据结构的存储
2.支持持久化
3.支持主从、集群、哨兵功能多
4.性能极高 – Redis能读的速度是110000次/s,写的速度是81000次/s。适合数据大
5.pub/sub模式的发布、订阅消息队列服务器

2.2 redis和memcache区别

1).Redis不仅仅支持简单的k/v类型的数据,同时还提供了list,set,zset,hash等数据结构的存储
2).Redis支持master-slave(主-从)模式应用
3).Redis支持数据的持久化
4).Memcached是多线程，非阻塞IO复用的网络模型,而redis单线程基于epoll模型实现IO多路复用的处理模式

3. redis的数据持久化

数据持久化：即把数据保存到可永久保存的存储设备中（如磁盘）

3.1 redis持久化 – 两种方式

RDB（默认）（Redis DataBase）和 AOF（Append Only File）

RDB（Redis DataBase）：是在不同的时间点，将redis存储的数据生成快照并存储到磁盘等介质上；快照是以文件的形式存在
特点:
1.周期性
2.不影响数据写入 RDB会启动子进程，备份所有数据。当前进程，继续提供数据的读写。当备份完成，才替换老的备份文件
3.高效一次性还原所有数据
4.完整性较差，有数据丢失的可能由于拍快照是有周期性的，当拍快照时发生故障了，所以恢复到故障点到上一次的备份，到下次备份之间的数据无法恢复

AOF（Append Only File）则是换了一个角度来实现持久化，那就是将redis执行过的所有写指令记录下来保存到文件中，在下次redis重新启动时，只要把这些写指令从前到后再重复执行一遍，就可以实现数据恢复了。
特点:
1.实时性
2.完整性较好
3.体积大记录数据的指令，删除数据的指令都会被记录下来。文件体积大

RDB和AOF两种方式也可以同时使用，在这种情况下，如果redis重启的话，则会优先采用AOF方式来进行数据恢复，这是因为AOF方式的数据恢复完整度更高

如何选择方式？
缓存：不用开启任何持久方式
双开:因RDB数据不实时，但同时使用两者时服务器只会找AOF文件,所以RDB留作万一的手段。
官方的建议是两个同时使用。这样可以提供更可靠的持久化方案。
写入速度快 ------------AOF
写入速度慢 ------------RDB

4. redis主从配置

像MySQL一样，redis是支持主从同步的，而且也支持一主多从以及多级从结构。主从结构，一是为了纯粹的冗余备份，二是为了提升读性能，比如很消耗性能的SORT就可以由从服务器来承担。redis的主从同步是异步进行的。

4.1 主从同步原理

主从 – 同步原理
从服务器会向主服务器发出SYNC指令（请求同步），当主服务器接到此命令后，就会调用BGSAVE指令来创建一个子进程专门进行数据持久化工作，也就是将主服务器的数据写入RDB文件中。在数据持久化期间，主服务器将执行的写指令都缓存在内存中。
在BGSAVE指令执行完成后，主服务器会将持久化好的RDB文件发送给从服务器，从服务器接到此文件后会将其存储到磁盘上，然后再将其读取到内存中。这个动作完成后，主服务器会将这段时间缓存的写指令再以redis协议的格式发送给从服务器。

另外，要说的一点是，即使有多个从服务器同时发来SYNC指令，主服务器也只会执行一次BGSAVE，然后把持久化好的RDB文件发给多个从服务器。

BGSAVE指令:
在后台异步(Asynchronously)保存当前数据库的数据到磁盘。
BGSAVE 命令执行之后立即返回 OK ，然后 Redis fork 出一个新子进程，原来的 Redis 进程(父进程)继续处理客户端请求，而子进程则负责将数据保存到磁盘，然后退出。

5. redis-sentinel---哨兵模式

Sentinel(哨兵)是用于监控redis集群中Master状态的工具，其已经被集成在redis2.4+的版本中是Redis官方推荐的高可用性解决方案

5.1 作用

1)：检测Master状态
2)：如果Master异常，则会进行Master-Slave切换，将其中一个Slave作为Master，将之前的Master作为Slave
Master-Slave切换后，sentinel的监控目标会随之调换

5.2 工作模式

1)：每个Sentinel以每秒钟一次的频率向它所知的Master，Slave以及其他 Sentinel 实例发送一个 PING 命令

2)：如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值，则这个实例会被 Sentinel 标记为主观下线。

3)：如果一个Master被标记为主观下线，则正在监视这个Master的所有 Sentinel 要以每秒一次的频率确认Master的确进入了主观下线状态。

4)：当有足够数量（看定义的哨兵数）的 Sentinel（大于等于配置文件指定的值）在指定的时间范围内确认Master的确进入了主观下线状态，则Master会被标记为客观下线

主从转移

ps:quorum 的值一般设置为哨兵个数的二分之一加1，例如 3 个哨兵就设置 2。

5.3 主观下线和客观下线

主观下线：Subjectively Down，简称 SDOWN，指的是当前 Sentinel 实例对某个redis服务器做出的下线判断。
客观下线：Objectively Down，简称 ODOWN，指的是多个 Sentinel 实例在对Master Server做出 SDOWN 判断，并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后，得出的Master Server下线判断，然后开启failover

如何故障转移？

前面说过，为了更加“客观”的判断主节点故障了，一般不会只由单个哨兵的检测结果来判断，而是多个哨兵一起判断，这样可以减少误判概率，所以哨兵是以哨兵集群的方式存在的。

那么问题来了，由哨兵集群中的哪个节点进行主从故障转移呢？

这时候，还需要在哨兵集群中选出一个 leeder，让 leeder 来执行主从切换。选举 leeder 的过程其实是一个投票的过程，在投票开始前，肯定得有个「候选者」。

那谁来作为候选者呢？

哪个哨兵节点判断主节点为「客观下线」，这个哨兵节点就是候选者，所谓的候选者就是想当 Leader 的哨兵。