memcache&redis构建缓存服务

memcache特点

内置内存存储方式（重启操作系统会导致全部数据消失）

简单key/value存储（服务器不关心数据本身的意义及结构，只要是可序列化数据即可。存储项由“键、过期时间、可选的标志及数据”四个部分组成。方便数据的查询和使用）

不互相通信的分布式（memcache尽管是“分布式”缓存服务器，但服务器端并没有分布式供能。各个memcache不会互相通信共享信息。如何进行分布式完全取决于客户端的实现。）

memcache支持的平台：linux、FreeBSD、Solarias（memcache1.2.5以上）、Mac OS X、Windows

memcached服务框架：

1、检查用户请求的数据在缓存中是否存在，如果存在的话，只需要直接把请求的数据返回给用户，无需再查询数据库。

2、如果请求的数据没有再缓存中找到，就会去查询数据库，返回请求数据的同时把数据存储到缓存中。

3、保持缓存的“新鲜性”，每当数据发生变化的时候，就会同步更新缓存信息，确保用户不会在缓存渠道旧的数据。

memcached实施

1、安装

yum list | grep memcache

yum install -y memcached

2、修改配置文件

vim /etc/sysconfig

3、启动

4、生产环境

web集群+memcached

环境：php，memcache分离部署

前端部署apache，mysql和php服务器（需要安装memcache客户端，php-memcached扩展包）

独立部署memcached服务器

redis

简介：redis是一个开源的、使用c语言编写的、支持网络交互的、可基于内存也可持久化的key-value数据库。

特点：

丰富的数据结构、支持持久化、支持事务、支持主从

redis持久化：启持久化功能重启redis后，数据会自动通过持久化文件恢复。

开持久化方式：

RDB（redis database）：在不同的时间点，将redis存储的数据生成快照并存储到磁盘等介质上。

特点：周期性、不影响数据写入（RDB会启动子进程，备份所有数据。当前进程继续提供数据的读写。当备份完成才替换老的备份文件）、高效（一次性还原所有数据）、完整性较差（故障点到上一次备份之间的数据无法恢复）

AOF（append only file）：换了一个角度来实现持久化，将redis执行过的所有写指令（每秒钟）记录在日志中，在下次redis重新启动时，只要把这些写指令从前到后在重新执行一遍就可以实现数据恢复了

特点：实时性、完整性较好、体积大

默认启动RDB，可以不用开启任何的持久化方式，也可以选择双开

redis主从

用法：主从结构，一是为了纯粹的冗余备份，而是为了提升读性能，比如很消耗性能的sort就可以有从服务器来承担。reids主从同步时异步进行的，这意味着主从同步不会影响主逻辑，也不会降低reids的处理性能。主从架构中，可以考虑关闭服务器的数据持久化功能，只让从服务器进行持久化，这样可以提高主服务器的处理性能。

在主从架构中，从服务器通常被设置为只读模式，这样可以避免从服务器的数据呗误修改。但是从服务器仍然可以接收config等指令，所以不应该将从服务器直接暴露到不安全的网络环境中。如果必须如此，那可以考虑给重要指令进行重命名来避免命令被误执行。

原理：从服务器会向主服务器发出SYNC指令，当主服务器收到指令后就会调用BGSAVE指令来创建一个子进程专门进行数据持久化工作，也就是将主服务器的数据写入RDB文件中。在数据持久化期间，主服务器执行的写指令都缓存在内存中。

在BGSAVE指令执行完成后，主服务器会将持久化后的RDB文件发送给从服务器。从服务器街道此文件后会将其存储到磁盘上，然后将其读取到内存中。这个动作完成后，主服务器会将这段时间缓存的写指令再以rdis协议的格式发送给从服务器。

即使由多个服务器同时发来SYNC指令，主服务器也只会执行一次BGSAVE。然后把持久化后的RDB文件发送给多个西安有。在reids2.8版本之前，如果从服务器与主服务器因某些原因断开连接到话都会进行一次主从之间的全量的数据同步。在redis2.8版本后，redis支持了效率更高的增量同步策略，这大大降低了连接断开的回复成本。

主服务器会在内存中维护一个缓冲区，缓冲区中存储着将要发给从服务器的内容。从服务器在与主服务器出现网路瞬断之后，从服务器会尝试再次与主服务器连接，一旦连接成功，从服务器会把“希望同步的主服务器ID“和”希望请求的数据的偏移位置（replication offset）“发送出去。主服务器接收到这样的同步请求后，首先验证主服务器ID是否和自己的ID匹配，其次回检查请求的偏移位置是否存在与自己的缓冲区中，如果两者都满足的话，主服务器就会向从服务器发送增量内容。

redis-sentinel（哨兵）

简介：redis-sentinel时redis官方推荐的高可用性（HA）解决方案。意味着可以使用sentinel模式创建一个可以不用认为干预而应对各种故障的redis部署。

作用：Master状态检测；如果Master异常，则会进行Master-Slave切换，将其中一个Slave作为Master，将之前的Master作为Slave；Mater-Slave切换后，Master_redis.conf、slave_redis.conf和sentinel.conf的内容都会发生改变，即master_redis.conf中会多一行slaveof的配置，seninel.conf的监控目标会随之调换。

工作方式：

1、每个sentinel以每秒钟一次的频率向它所知的Master、Slave以及其他的Sentinel实例发送一个ping命令。

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

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

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

主观下线和客观下线：

主观下线：subjectively down，简称SDOWN，指的是当前Sentinel实例对某个rdis服务器做出的下线判断。

客观下线：objectively down，简称ODOWN，指的是多个Sentinel实例在对Master Server做出DOWN判断，并且通过sentinel is-master-down-by-addr命令互相交流之后得出的Master Server下线判断，然后开启failover

sentinel配置文件：

sentinel monitor mymaster 192.168.100.22 6379 2 当集群中有2个sentinel认为master死了时，才能真正认为该master以及不可用了

sentinel down-after-millisecond mymaster 3000 如果在3000毫秒内没有收到有效回府，则会判定该节点为主观下线

sentinel failover-timeout mymaster 10000 若sentinel在10000毫秒内未能完成failover（故障转移）操作，则认为本次failover失败