Redis&memcache

目录

一. Memcached

服务架构：

原理：

 1.安装

 编译安装的memcached启动方法

编译安装的memcached开机启动

2.修改配置文件

3.启动

4.测试

 1.使用memcached的原始命令

二.redis

特点：

1.安装

安装redis

 开机启动

测试

**2.redis持久化**

方式:        RDB        AOF

如何选择方式？

配置持久化

3.redis主从

主从 – 用法

主从 – 同步原理

环境:

192.168.31.212        master

192.168.31.213        slave1

192.168.31.214        slave2

测试

4.redis-sentinel

sentinel介绍

工作方式

 主观下线和客观下线 

1. 每台机器上修改redis主配置文件设置：

3.每台机器启动服务：

4.关闭主服务器，观察从服务器改变状态 

redis有哪些好处

redis相比memcached有哪些优势

redis常见性能问题和解决方案

redis集群的工作原理

---

      

  许多Web应用都将数据保存到 RDBMS中，应用服务器从中读取数据并在浏览器中显示。 但随着数据量的增大、访问的集中，就会出现RDBMS的负担加重、数据库响应恶化、 网站显示延迟等重大影响。Memcached/redis是高性能的分布式内存缓存服务器,通过缓存数据库查询结果，减少数据库访问次数，以提高动态Web等应用的速度、 提高可扩展性。

        RDBMS即关系数据库管理系统(Relational Database Management System)

NOSQL名词解释：Not Only SQL 以键值对的方式存储数据

一. Memcached

服务架构：

原理：

        1.检查用户请求的数据是缓存中是否有存在，如果有存在的话，只需要直接把请求的数据返回，无需查询数据库。
        2.如果请求的数据在缓存中找不到，这时候再去查询数据库。返回请求数据的同时，把数据存储到缓存中一份。
        3.保持缓存的“新鲜性”，每当数据发生变化的时候（比如，数据有被修改，或被删除的情况下），要同步的更新缓存信息，确保用户不会在缓存取到旧的数据。

 1.安装

yum install memcached -y

 编译安装的memcached启动方法

# /usr/local/memcached/bin/memcached -u memcached -p 11211 -m 1500 -c 1024

编译安装的memcached开机启动

1.把启动命令写到rc.local里面

chmod a+x /etc/rc.d/rc.local
echo '/usr/local/memcached/bin/memcached -u memcached -p 11211 -m 1500 -c 1024' >> /etc/rc.d/rc.local
systemctl enable  rc-local      

2.编写shell启动脚本

#! /bin/sh
# chkconfig: - 55 45
# description: The memcached daemon is a network memory cache service.
# processname: memcached
# config: /etc/sysconfig/memcached
# Source function library - for other linux
#. /etc/rc.d/init.d/functions
# Source function library - for SUSE linux

. /lib/lsb/init-functions
PORT=11211
USER=root
#最大连接数，根据实际需求修改
MAXCONN=1024
#最大内存量，单位M
CACHESIZE=128
OPTIONS=""

if [ -f /etc/sysconfig/memcached ];then
. /etc/sysconfig/memcached
fi

# Check that networking is up.
if [ "$NETWORKING" = "no" ]
then
exit 0
fi

RETVAL=0
prog="memcached"

start () {
echo -n $"Starting $prog: "
# insure that /usr/local/memcached has proper permissions
chown $USER /usr/local/memcached

/usr/local/memcached/bin/memcached -d -p $PORT -u $USER -m $CACHESIZE -c $MAXCONN -P /usr/local/memcached/memcached.pid $OPTIONS

RETVAL=$?

echo
[ $RETVAL -eq 0 ] && touch /var/lock/subsys/memcached
}

stop () {
echo -n $"Stopping $prog: "
killproc memcached
RETVAL=$?
echo
if [ $RETVAL -eq 0 ] ; then
rm -f /var/lock/subsys/memcached
rm -f /usr/local/memcached/memcached.pid
fi
}

restart () {
stop
start
}

# See how we were called.
case "$1" in

start)
start
;;
stop)
stop
;;
status)
status memcached
;;
restart|reload)
restart
;;
condrestart)
[ -f /var/lock/subsys/memcached ] && restart || :
;;
*)
echo $"Usage: $0 {start|stop|status|restart|reload|condrestart}"
exit 1
esac

exit $?

2.修改配置文件

vim  /etc/sysconfig/memcached 

PORT="11211"                 //同台机编译安装多个memcached，多实例
USER="memcached"
MAXCONN="1024"
CACHESIZE="1500"            //单位是 MB
OPTIONS=""                  //监听的网络地址

3.启动

systemctl start memcached.service 

 ps aux | grep memcache

4.测试

 1.使用memcached的原始命令

yum install telnet
telnet  127.0.0.1  11211
    set name 0 900 5   //设置名称为name的key
    why
    get name
    why

二.redis

特点：

丰富的数据结构
支持持久化
支持事务        众所周知，事务是指“一个完整的动作，要么全部执行，要么什么也没有做”。
支持主从

1.安装

安装redis

wget http://download.redis.io/releases/redis-4.0.9.tar.gz -O /redis-4.0.9.tar.gz
cd  /
tar xzf redis-4.0.9.tar.gz

cd /redis-4.0.9/
make

 开机启动

mkdir  /etc/redis
cp   /redis-4.0.9/redis.conf  /etc/redis/6379.conf
cp /redis-4.0.9/utils/redis_init_script   /etc/init.d/redis

vim /etc/init.d/redis  更改文件路径，&放到后台静默执行

EXEC=/redis-4.0.9/src/redis-server
CLIEXEC=/redis-4.0.9/src/redis-cli
$EXEC $CONF &

chmod 777 /etc/init.d/redis
chkconfig --add redis
chkconfig  redis  on
systemctl daemon-reload
systemctl start redis

测试

 /redis-4.0.9/src/redis-cli

127.0.0.1:6379> set name why

OK

127.0.0.1:6379> get name

"why"

**2.redis持久化**

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

方式:        RDB        AOF

RDB(Redis databases)：RDB，是在不同的时间点，将redis存储的数据生成快照并存储到磁盘等介质上；

特点：

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

AOF（append only  file）

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

特点：

实时性
完整性较好
体积大        记录数据的指令，删除数据的指令都会被记录下来。

如何选择方式？

缓存
    不用开启任何的持久化方式
双开
    因RDB数据不实时，但同时使用两者时服务器只会找AOF文件,所以RDB留作万一的手段。

配置持久化

RDB默认开启        rdbcompression yes

AOF默认关闭        appendonly no

3.redis主从

主从 – 用法

像MySQL一样，redis是支持主从同步的，而且也支持一主多从以及多级从结构。

主从结构，一是为了纯粹的冗余备份，二是为了提升读性能，比如很消耗性能的SORT就可以由从服务器来承担。

redis的主从同步是异步进行的，这意味着主从同步不会影响主逻辑，也不会降低redis的处理性能。

主从架构中，可以考虑关闭主服务器的数据持久化功能，只让从服务器进行持久化，这样可以提高主服务器的处理性能。

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

主从 – 同步原理

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

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

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

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

增量同步功能，需要服务器端支持全新的PSYNC指令。这个指令，只有在redis-2.8之后才具有。

环境:

192.168.31.212        master

192.168.31.213        slave1

192.168.31.214        slave2

192.168.31.212        master

 vim /etc/redis/6379.conf

bind 0.0.0.0
protected-mode no

systemctl restart redis

192.168.31.213        slave1

 vim /etc/redis/6379.conf

slaveof 192.168.31.212  6379
bind 0.0.0.0
protected-mode no

systemctl restart redis

192.168.31.214        slave2

 vim /etc/redis/6379.conf

slaveof 192.168.31.212  6379
bind 0.0.0.0
protected-mode no

systemctl restart redis

测试

数据一致性

        master1记录键值对
        slave1查询数据，验证数据一致性

服务状态

        /redis-4.0.9/src/redis-cli        登录redis客户端

        info replication        查看复制状态

4.redis-sentinel

sentinel介绍

是Redis官方推荐的高可用性(HA)解决方案。实际上这意味着你可以使用Sentinel模式创建一个可以不用人为干预而应对各种故障的Redis部署。
作用：
 1)：Master状态检测
 2)：如果Master异常，则会进行Master-Slave切换，将其中一个Slave作为Master，将之前的Master作为Slave
 3)：Master-Slave切换后，master_redis.conf、slave_redis.conf和sentinel.conf的内容都会发生改变，即master_redis.conf中会多一行slaveof的配置，sentinel.conf的监控目标会随之调换

工作方式

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

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

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

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

 主观下线和客观下线 

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

1. 每台机器上修改redis主配置文件设置：

bind 0.0.0.0（略）

2.每台机器上修改sentinel配置文件：

添加如下配置

vim /redis-4.0.9/sentinel.conf

sentinel monitor mymaster 192.168.31.212 6379 2
sentinel down-after-milliseconds mymaster 3000
sentinel failover-timeout mymaster 10000
protected-mode no

当集群中有2个sentinel认为master死了时，才能真正认为该master已经不可用了。

如果在down-after-millisecondes毫秒内，没有收到有效的回复，则会判定该节点为主观下线。

若sentinel在该配置值内未能完成failover(故障转移)操作（即故障时master/slave自动切换），则认为本次failover失败。

3.每台机器启动服务：

 /redis-4.0.9/src/redis-sentinel sentinel.conf

4.关闭主服务器，观察从服务器改变状态 

停掉master，并在新的master上面查看信息

        /redis-4.0.9/src/redis-cli

        info replication

redis有哪些好处

(1) 速度快，因为数据存在内存中，类似于HashMap，HashMap的优势就是查找和操作的时间复杂度都是O(1)
(2) 支持丰富数据类型，支持string，list，set，sorted set，hash
(3) 支持事务，操作都是原子性，所谓的原子性就是对数据的更改要么全部执行，要么全部不执行
(4) 丰富的特性：可用于缓存，消息，按key设置过期时间，过期后将会自动删除

redis相比memcached有哪些优势

(1) memcached所有的值均是简单的字符串，redis作为其替代者，支持更为丰富的数据类型
(2) redis可以持久化其数据

redis常见性能问题和解决方案

(1) Master最好不要做任何持久化工作，如RDB内存快照和AOF日志文件
(2) 如果数据比较重要，某个Slave开启AOF备份数据，策略设置为每秒同步一次
(3) 为了主从复制的速度和连接的稳定性，Master和Slave最好在同一个局域网内
(4) 尽量避免在压力很大的主库上增加从库
(5) 主从复制不要用树状结构，用单向链表结构更为稳定，即：Master（写） <- Slave1（读） <- Slave2（读） <- Slave3（读）...
这样的结构方便解决单点故障问题，实现Slave对Master的替换。如果Master挂了，可以立刻启用Slave1做Master，其他不变。

redis集群的工作原理

主多从+哨兵模式（keelalived）