Redis知识点总结

思维导图如下:

首先来了解一下NoSQL
1.互联网环境大机遇下,为什么要用NoSQL

1.单机Mysql的美好年代

据说现在的mysql的单表可以支持500万的数据量,但是真正的DBA大概在300万的时候就需要进行优化.

2.Memcached(缓存)+mysql+垂直拆分

对于数据库而言,比较受伤害的就是频繁的查询,如果频繁的查询的是一些固定的数据,那么我们可以把这些数据拿出来放到缓存中,来减轻数据库的访问压力.

3.mysql主从读写分离

对于写操作,都是在主库(master)内进行,读操作都是在从库(slave),主从读写分离可以减轻数据库的压力.

4.分表分库+水平拆分+mysql集群

分库:我们尽量把业务相关信息放在一个库,把那些和业务不相关的比较冷门的信息放在另外一个库(例如,用户的注册信息中的身份证好,一般很少会改动),频繁的热点的,和业务紧密相关的我们会放在一个库,稳定的变化很少的信息放在另外一个库中.
分表:假如,一组数据总共有9000万条,如果全部放在一张表中,可想而知,无论你的SQL或者是索引如何优化,性能肯定会很低,这时,我们可以借助一些算法,利用3个或者更多的库做一个集群,1~3000w的数据进入1号库,3001~6000w的进入二号库,6001~9000w的进入三号库.这样可以明显的减轻数据库服务器的压力了.

5.mysql的拓展性瓶颈

一些VCR和一些比较大的二进制的数据(例如一个2G的电影,如果我们写的SQL中包含了select * ,那么结果可想而知.)等.是不适合存入mysql的

6.今天是什么样子了?

7.为什么要用NoSQL?

虽然社交网络的发展,传统的关系型数据库已经难以支撑这些复杂的关系网络了,然而NoSQL却能很好的进行支持.

2.是什么

3.能干嘛

1.易扩展

对于关系型数据库而言,横向的扩展是有限制的,还有就是比如社交关系,亲情关系,传统的关系型数据库的数据类型很难进行描述,但是我们可以使用NoSQL中的树或者是图来进行描述

2.大数据量高性能

我们的mybatis或者是hibernate都是有缓存的,当我们第二次发送出相同的SQL,它便会从缓存中取数据.
redis的性能是非常强悍的,官方给出的数据是,写操作 8w/s 次 ,读操作  12w/s次

3.多样灵活的数据模型

4.传统 RDBMS VS NoSQL

4.去哪下

Redis:一专多能,数据类型丰富,redis和tair更加的出色,(其中美团用的就是tair ,是淘宝的多隆写的.)
Memcache:纯粹用来完成高速缓存,它是最强悍的.
Mongdb:主要是用来存放文档类数据

5.怎么玩
面试题谈谈你对redis的理解

我们应该回答,redis是什么,主要拿来干什么,说白了就是我们下面的.
kv 键值对
cache:缓存
persistence:

第二节:3V+3高

大数据时代的3V

海量Volume:
多样Variety:
实时Velocity

互联网需求的3高

高并发
高可扩
高性能(或者称为是 高可用)

第三节 :当下NoSQL的经典应用

面试题:redis的使用场景?

当下用用是SQL和NoSQL一起使用

千万不能说,redis把Oracle给干掉了,他们两个的应用领域不同.各有千秋,不是对手敌人的关系

阿里巴巴中文站的商品信息是如何存放的

0 和我们相关的，多数据源多数据类型的存储问题

相关关键早指的就是,我们在网站上看到的搜索框,称为是站内搜索

1 商品基本信息

2 商品描述、详情、评价信息(多文字类)

3 商品的图片

商品的图片展现放在分布式的文件系统中

4 商品的关键字

站内搜索,多隆自己开发的.(ISearch和tair都是他自己完成的)

5 商品的波段性的热点高频信息

6 商品的交易、价格计算、积分累计

总结大型互联网应用(大数据、高并发、多样数据类型)的难点和解决方案

经过刚才的充饥,我们可以想象到,一张页面的内容不是直接从一个mysql中全部加载的,而不是从不同的数据源中进行加载.但是个人在短期内很难穷尽这么多中数据库技术.

难点:

数据类型多样化
数据源多样性和变化重构
数据源改造而数据服务平台不需要大面积防洪沟

解决方法

类似于面向接口变成一样,我们在数据库和dao之间包装了一层口,来看看阿里是如何做到的

udsl(统一数据平台服务层)

第四节 NoSQL的数据模型简介

{
 "customer":{
   "id":1136,
   "name":"Z3",
   "billingAddress":[{"city":"beijing"}],
   "orders":[
    {
      "id":17,
      "customerId":1136,
      "orderItems":[{"productId":27,"price":77.5,"productName":"thinking in java"}],
      "shippingAddress":[{"city":"beijing"}]
      "orderPayment":[{"ccinfo":"111-222-333","txnid":"asdfadcd334","billingAddress":{"city":"beijing"}}],
      }
    ]
  }
}

传统的数据库称为是关系模型
NoSQL称为是聚合模型,他能够比传统的关系型数据库更好的支持数据.比如,对于员工和部门表而言,员工表中一定会有一个部门表ode外键,但是对用BSon而言,它只要符合json的语法规范就行,一组数据中可以包含订单信息,用户信息等,不需要主外键这种强连接.比较容易扩展,只要符合json的语法,到最后就变成了字符串的解析.在redis中,我们在查询时,通过KV键值对进行查找,我们只需要查询到K为员工的id,那么查出的数据中就包含了用户信息,和订单信息等.我们只要对该json串进行解析,皆可以理清所有的关系,而不用像传统的关系数据库那样通过表之间的各种join来拿到目标数据,
对于分布式系统而言,最忌讳的就是多表的join,它会拖慢系统的性能.

以前,我们的关系型数据库中,数据都是横向扩展的,每一行可以表示一个对象,但是,在列族中,数据没有进行横向的扩展,只有KV两列,对数据进行的是纵向的扩展.如上图所示,我们只需要查询到一个行键,就可以获取到像用户或者订单这样的信息.

传统的关系型数据库对于下图中的关系很难描述:

第五节 NoSQL数据库的四大分类

KV键值：典型介绍

文档型数据库(bson格式比较多)：典型介绍

列存储数据库

图关系数据库

四者对比

第六节 在分布式数据库中CAP原理CAP+BASE

1. 传统的ACID分别是什么

A(Atomicity):原子性
C(Consistency):一致性
I(Isolation):独立性
D(Durability):持久性

那么ACID具体是什么?

关系型数据库遵循ACID规则
事务在英文中是transaction，和现实世界中的交易很类似，它有如下四个特性：

1、A (Atomicity) 原子性
原子性很容易理解，也就是说事务里的所有操作要么全部做完，要么都不做，事务成功的条件是事务里的所有操作都成功，只要有一个操作失败，整个事务就失败，需要回滚。比如银行转账，从A账户转100元至B账户，分为两个步骤：1）从A账户取100元；2）存入100元至B账户。这两步要么一起完成，要么一起不完成，如果只完成第一步，第二步失败，钱会莫名其妙少了100元。
 
2、C (Consistency) 一致性
一致性也比较容易理解，也就是说数据库要一直处于一致的状态，事务的运行不会改变数据库原本的一致性约束。
 
3、I (Isolation) 独立性
所谓的独立性是指并发的事务之间不会互相影响，如果一个事务要访问的数据正在被另外一个事务修改，只要另外一个事务未提交，它所访问的数据就不受未提交事务的影响。比如现有有个交易是从A账户转100元至B账户，在这个交易还未完成的情况下，如果此时B查询自己的账户，是看不到新增加的100元的
 
4、D (Durability) 持久性
持久性是指一旦事务提交后，它所做的修改将会永久的保存在数据库上，即使出现宕机也不会丢失。

2. CAP

注意:在NoSQL的世界中,对于CAP理论,最好的结果就是满足其中的两个,一个系统,不可能3个全部满足.只能3选2.

C(Consistency):强一致性
A(Availability):可用性
P(Partition tolerance):分区容错性(它是我们在NoSQL过程中必须要实现的)

3. CAP的3进2

大多数的网站只能妥协到AP

对于分布式的系统而言,他有可能系统的服务器并没有全部部署在同一个城市,所以分布式系统必须都要满足CAP理论中的,P(分区容错性),所以我们只需要在C(强一致性)和A(高可用性)之间来进行选择.
强一致性主要保证的就是你系统数据的精准度比较高.
高可用性就是为了保证网站的正常运行,不会瘫痪,尤其是在海量的数据和访问量的情况下
根据两害相衡取其轻的原则,想京东和淘宝这样的分布式系统,尤其是双11当天,AP是至关重要的,比起CP中数据的精确性,网站能够正常的运行,不瘫痪更为重要.所以大多数的分布式网站都是满足AP.弱一致性.我们使用redis的目的是为了帮助mysql减轻负担,来保证网站的AP.

在我们的日常生活中,比如我们发了一个微博,或者更新了一条动态,那么我们肯定是第一个作者,要保证是读己之所写是第一位,我们朋友她们可能会在几秒或者是十几秒之后才能看到我的动态,这是可以接受的.这就是弱一致性,还有就是一些常见的购票网站,携程,艺龙等,她们都是说是实时购票系统,其实只能做到准实时,所以分布式的系统大多数都是,AP然后加弱一致性.

4. 经典CAP图

CA:RDMS传统关系型数据库满足的是
AP:CouchDB等
CP:Mon个DB,Redis HBase等满足

5. BASE

说白了BASE理论的重点就是最终一致性,例如双11过了之后,可能还是需要数据的准确性,分布式系统在一定的时间内牺牲了C来保证了AP,但是最后,还是要求数据一致性,即弱一致性.

6. 分布式+集群简介

第二章,Redis的入门介绍

第一节.入门概述

1.是什么

Redis:REmote DIctionary Server(远程字典服务器)

是完全开源免费的，用C语言编写的，遵守BSD协议，
是一个高性能的(key/value)分布式内存数据库，基于内存运行
并支持持久化的NoSQL数据库，是当前最热门的NoSql数据库之一,
也被人们称为数据结构服务器

Redis 与其他 key - value 缓存产品有以下三个特点:

Redis支持数据的持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用
Redis不仅仅支持简单的key-value类型的数据，同时还提供list，set，zset，hash等数据结构的存储
Redis支持数据的备份，即master-slave模式的数据备份

2.能干嘛

3.去哪下

4.怎么玩

第二节.VMWare+VMTools千里之行始于足下

第三节. Redis的安装

安装过程中可能会遇到的问题:
执行make命令之后,报出gcc没有找到的错误:

他说明,我们机器上缺少gcc的环境,

如果联网了话,直接使用命令, yum install gcc-c++
安装gcc-c++之后,执行gcc-v,然后再次执行make,如果报错说,Jemalloc/jemalloc.h：没有那个文件或目录,他表示的是由于之前我们没有gcc的环境,执行了make,可能会有残留文件,我们需要执行运行make distclean之后再make,然后只需要静静的等待几分钟,什么也不用操作.
执行完成之后如下图:

最好不要执行make test 操作.因为会很慢,test之前要求我们要安装一个TCL

在Linux中,如果我们需要从外网下载的话,我们可以使用  wget 应用对用的具体网址

注意:我们的/etc目录主要是用来存放,安装软件的配置文件的,
软件的安装包一般是上传到/opt目录下
/usr/local/bin是我们的软件的安装位置

redis的入门案例:

第四节.Redis启动后杂项基础知识讲解

说白了就是一些很重要但是有很零散的知识点,后面的课程都会用到的知识点.
我们可以执行 redis-benchmark 来测试自己电脑上redis服务器的性能,就算以后工作之后公司给你配备了一个本子,你想知道它的性能如何,可以执行该命令来看看redis的性能就可以知道了.

1.单进程

单进程模型来处理客户端的请求。对读写等事件的响应
是通过对Linux内核的epoll函数的包装来做到的。Redis的实际处理速度完全依靠主进程的执行效率
Epoll是Linux内核为处理大批量文件描述符而作了改进的epoll，是Linux下多路复用IO接口select/poll的增强版本，
它能显著提高程序在大量并发连接中只有少量活跃的情况下的系统CPU利用率。

2.redi 数据库的个数

默认16个数据库，类似数组下表从零开始，初始默认使用零号库
默认的数据库的下标是从 0 开始的,也就是说范围是(0~15) ,我们可以使用 select 数据库的id值    来切换到我们需要的数据库. 

3.DBsize

DBsize可以可以用来查看当前数据库的key的总数量
redis对Linux很好的支持就是table可以进行自动补全,并且字母全部变为大写
keys *  可以用来查看当前数据库中的所有的key值,但是在实际的生产环境中,尽量少使用
flushdb:清空当前数据库
flushall:清空所有数据库.无论在那个数据库都有效.
我们在使用table自动补全时,要注意,因为自动补全先出现的是flushall,六神别全部清空了啊.
redis是统一密码管理的,16个库使用的都是同一个密码,要么全部成功,要么一个也连不上.
redis的索引都是从0 开始的,并且默认的端口是  6379

第三章 ,redis的数据类型
redis中尝尝考到的数据类型就是,String ,list hash

第一节 Redis的五大数据类型

String :字符串(他可以包含任何数据,最大值存储数值是512M)

string是redis最基本的类型，你可以理解成与Memcached一模一样的类型，一个key对应一个value。
string类型是二进制安全的。意思是redis的string可以包含任何数据。比如jpg图片或者序列化的对象 。
string类型是Redis最基本的数据类型，一个redis中字符串value最多可以是512M

Hash（哈希，类似java里的Map）

Redis hash 是一个键值对集合。
Redis hash是一个string类型的field和value的映射表，hash特别适合用于存储对象。
类似Java里面的Map<String,Object>

List（列表）

Redis 列表是简单的字符串列表，按照插入顺序排序。你可以添加一个元素导列表的头部（左边）或者尾部（右边）。
它的底层实际是个链表,类似java中 linkedlist,底层都是链表实现的.

Set（集合）:set都是无序无重复的.

Redis的Set是string类型的无序集合。它是通过HashTable实现实现的，
其实在java的世界中,Hashset和HashMap是一回事,Hashset的底层其实就是HashMap

Zset(sorted set：有序集合)

它的实质和之前的set是差不多的,只不过关联了一个值,在游戏中经常使用,例如关联的值是分数,并且是按照这个分数进行排序的.

第二节 哪里去获得redis常见数据类型操作命令

命令大全还是去官网 Http://redisdoc.com.下面还是有一份比较常用的命令手册.常用的命令都在脑图中.

第三节 Redis 键(key)

案例:

 keys *
  exists key的名字，判断某个key是否存在,如果存在则显示数量值,不存在显示0
   move key 目标db下标   --->当前库就没有了，被移除了
    expire key 秒钟：为给定的key设置过期时间
     ttl key 查看还有多少秒过期，-1表示永不过期，-2表示已过期(过期之后,就表示生命周期已经终结,无法被get 或者是keys * 访问了)
      type key 查看你的key是什么类型
      del key :删除指定的key
      set 键 值 :如果键是已经存在的,那么不会报错,而是会对原来的值产生覆盖.
      get 键 :查询指定的值.

第四节 Redis字符串(String)

String总结出来一句话就是 单值单value

set/get/del/append/strlen
Incr/decr/incrby/decrby,一定要是数字才能进行加减
getrange/setrange   ( getrange  键  0 -1 表示查看对应值)
 setex key   秒值   Value   给key设置存活时间,到期之后会自动死掉.   (set with expire)
 setnx  k  v  :只有当键在数据库中不存在时,才会保存值,可以避免发生覆盖(set if not exist)
 mset  多个key  多个v  : 一次进项多个键值对的插入,如果多个值中有失败的,那么全部都失败,都不能执行.
 mget 多个k:  一次查询多个v
 msetnx  多个k ,多个v:和mset 的结果差不多,避免发生覆盖.
 getset:将给定 key 的值设为 value ，并返回 key 的旧值(old value)。
简单一句话，先get然后立即set

第五节 Redis列表(List)

是单值多value

lpush k  多个v :就是 left push ,对一个集合添加多个值,在底层链表上时从左侧进行的插入,查出来的结果和插入的顺序相反
rpush k 多个v :right push 和 lpush的作用是一样的,只不过底层是从右侧进行饿插入,结果和插入的顺序相同
lrange k 0  -1 :课可以查看指定的集合中的所有的元素

lpop K : left pop ,相当于从左侧进行出栈,每次都弹出栈顶元素
rpop K: right pop 相当于从右侧进行出栈,每次都弹出栈顶元素

lindex k 数字 :按照索引下标从0开始到当前数字-1 获得元素(从上到下)
llen k :用来查看K的长度.
lrem k n m :删除k键对应的值中的n个m.
 ltrim key 开始index 结束index，截取指定范围的值后再赋值给key(从上往下的顺序截取.)
  rpoplpush 源列表 目的列表 :源列表栈底弹出的元素压栈到目的列表的栈顶(l代表栈顶,r代表栈底),执行之后显示的结果是被操作的元素.
   lset key index value:通过下标给指定的集合中的设值.
    linsert key  before/after 值1 值2 : 在v中的值1前或者后插入值2.

性能总结

它是一个字符串链表，left、right都可以插入添加；
如果键不存在，创建新的链表；
如果键已存在，新增内容；
如果值全移除，对应的键也就消失了。
链表的操作无论是头和尾效率都极高，但假如是对中间元素进行操作，效率就很惨淡了。

第六节 Redis集合(Set)

单值多value,并且是不可重复的.可以用来去重或者是过滤

sadd k 多个v : 为一个set添加多个值,重复的值会被覆盖
smembers k  :查看一个set的所有元素
sismember k v :查看k中是否包含v,如果有显示1,没有显示0.
scard k : 获取集合k里面的元素个数
 srem key value 删除集合key中指定的值value
  srandmember key 数字n : 在key的值内,随机出n个值.
   spop key :随机出栈一个值.
    smove key1 key2 key1里某个v : 作用是将key1里的某个值v赋值给key2,放在key2的栈顶
    差集：sdiff
    交集：sinter
    并集：sunion

第七节 Redis哈希(Hash),很重要.非常重要,极其重要

KV模式不变，但V是一个键值对

hset key  键   值  : 添加值,只不过v变成的一个键值对组成
hget key  键 : 
hmset key  k1 v1 k2 v2 等等 : 一次完成多个值的录入
hmget key  k1 k2 k3 等等 : 一次查询多个值.(只查询值)
hgetall key  :查询所有的键值对(包含了键和值)
hdel key k1 : 删除指定的值
hlen key :获取key的长度.
hexists key k1 :判断key 是否存在k1,存在显示1,不存在显示0
hkeys key :查看key中所有的key
hvals key : 查看key中所有的value
hincrby key  k1 数字n : k1的值加n
hincrbyfloat k1 数字n :k1的float类型的值加n.
hsetnx key k1 v1 :如果k1不存在的情况下才进行数据的录入,存在是加不进去的饿.

第八节 Redis有序集合Zset(sorted set)

在set基础上，加一个score值。之前set是k1 v1 v2 v3，
现在zset是k score1 v1 score2 v2

zadd k score1 v1 score2 v2 等等 :创建zset并且传入值.
zrange k 0 -1 :查看所有的v
zrange  k 0 -1 withscores : 查看所有的v和scores
 zrangebyscore key 开始score 结束score : 查看指定score范围的v(这个是包含了边界值的)
  zrangebyscore key (开始score (结束score :这样的是不包含辩解值的
  zrangebyscore key score1 score2 limit m n : 查询score1到score2范围的v,然后对结果集进行截取,从第m个元素向下截取n个元素.(相当于是做分页查询)
   zrem key 某score下对应的value值 :作用是删除元素,会把对应的screen和value都删除
   zcard key :查看key的元素的总数
   zcount key 开始score1 结束score2  查看指定score区间内的值的数量(包含边界值)
   zrank key value : 通过value获取相对应的key的下标  
   zscore key value : 获取value对应的分数.
   zrevrank key value :逆序获取下标值.
   zrevrange key 0 -1 : 逆序输出value
    zrevrangebyscore  key 结束score1 开始score2 : 按照分数逆序输出区间的value

第四章 解析配置文件 redis.conf
重点是下图中的蓝色部分:

第一节 它在哪

默认路径:

由于我们不能保证每次修改都是正确的,所以需要进行备份,修改的都是备份文件

第二节 Units单位

    1  配置大小单位,开头定义了一些基本的度量单位，只支持bytes，不支持bit
   	2  对大小写不敏感

第三节 INCLUDES包含

可以通过includes包含，redis.conf可以作为总闸，包含其他的配置文件

第四节 GENERAL通用

它指的是通用常见的配置,端口号,管道进程的pid等都是在这配置的.

tcp-backlog 511(在学习阶段该项就保持出厂的默认值就行)

设置tcp的backlog，backlog其实是一个连接队列，backlog队列总和=未完成三次握手队列 + 已经完成三次握手队列。
在高并发环境下你需要一个高backlog值来避免慢客户端连接问题。注意Linux内核会将这个值减小到/proc/sys/net/core/somaxconn的值，所以需要确认增大somaxconn和tcp_max_syn_backlog两个值
来达到想要的效果

timeout 0

他表示的是服务器在经过多少秒之后会关闭掉空闲的连接,0表示禁用该功能

Tcp-keepalive

单位为秒，如果设置为0，则不会进行Keepalive检测，建议设置成60 

loglevel : 日志的级别

级别的取值分别是 由上往下日志级别越来越高,打印的日志信息越来越少
debug :开发测试阶段适合使用
verbose :  开发阶段,但是没有debug级别打印的信息多.
notice   :用于实际的生产环境中
warning :系统比较稳定,上线之后,出故障之后使用它查看出问题的信息.(它只打印非常重要的信息)

logfile “”

日志的名字,如果日志的名字是空的话,redis会在控制台上进行标准的日志输出

Syslog-enabled :系统日志

系统日志,默认是关闭的,它决定是否把日志输出到syslog文件中

Syslog-ident :redis

如果我们打开了系统日志,它会指定syslog的日志标志,默认是以redis开头的.

Syslog-facility:local0

指定syslog设备，值可以是USER或LOCAL0-LOCAL7,默认值是local0

Databases : 16

默认安装完成之后就是16个数据库,下标从0开始到15结束.并且16个库的密码都是一样的饿

第五节 SNAPSHOTTING快照

1 Save

默认的出厂配置是,save 秒数 写操作的次数 来触发snapshotting快照的操作.

禁用RDB持久化:

我们跟面试官侃的时候,就说自己对redis很熟悉,如果他问你是如果备份的,你可以说是用RDB的出厂的默认配置,就是上面的3行红字.

正常情况,我们都是2min内改动10次,或者是15min内改动了数据,redis就会自动的帮我们进行数据的备份,但是如果我们有一个数据很重要,等不了2min我就要执行备份,怎么办?

执行save命令,系统就会立马进行备份,不用等了.相当于是自动挡变成了手动挡,我们可以自己进行备份
flushall也会进行数据的备份,也会产生新的dump.rdb文件,只不过该文件是空的,没有数据的.

2 Stop-writes-on-bgsave-error

大致理解为就是,后台在持久化的过程中出错的话,前台是否要停止写操作.默认值就是yes,就是会停止写操作.no的话就是不停止写操作.

3 rdbcompression :rdb压缩(默认值是yes)

意思就是,询问你是否启用这个LZF压缩算法,默认值yes是启用的,如果你想要节约你的CPU的耗损和内存的话,就设置成no,不在进行压缩了.如果压缩的话,会让CPU多做一些工作.
但是在实际的生产中,我们还是不要节省这一点CPU和内存了,还是设置为yes,连毛毛雨都算不上,直接在买两台机器就行了.能用钱解决的问题永远不要花费自己的时间和精力.永远有更重要的事情在等你.

4 rdbchecksum:它主要是对快照的对数据进行检验,默认值是yes.

尽管会有10%的CPU性能消耗,但是我们还是选择yes,开启此功能,因为快照的压缩和数据的检验都是运维在晚上,夜深人静的时候,服务器空闲的时候做数据的备份.

5 dbfilename

默认名称是.dump.rdb

6 dir

文件的存储位置,可以使用 config get dir:来获取redis是在那个文件下启动的.

第六节 REPLICATION复制

第七节 SECURITY安全

redis是负责缓存的,所以在安全方面,为了快捷和方便,如果每次连接都要输入一次密码,是比较慢的,同时redis是基于Linux平台的,所以它的安全是基于Linux平台的,只要是在Linux安装了,可以直接使用的.
在vim打开文件时,命令行模式下 /XXX : 可以在该文件中进行搜索XXX.

访问密码的查看、设置和取消:
config get requirepass : 获取redis的登录密码
config set requirepass “密码” : 设置redis的登录密码
config get dir :查看当前redis的启动路径,有时候配置文件 例如日志 就写在当前启动路径下.

只要我们设置密码之后,redis就会立马加强防火墙,再次执行ping就会报错,必须要输入密码.我们需要输入  auth  密码  :才能继续执行其他的命令.
学习阶段,为了方便,密码一般都是设置为空的.

第八节 LIMITS限制

我们可以不关心redis是用来做缓存还是做消息中间件等,但是这些限制级别的信息要懂.

1 Maxclients : 最大连接数(默认值是1w)

设置redis同时可以与多少个客户端进行连接。默认情况下为10000个客户端。当你
无法设置进程文件句柄限制时，redis会设置为当前的文件句柄限制值减去32，因为redis会为自
身内部处理逻辑留一些句柄出来。如果达到了此限制，redis则会拒绝新的连接请求，并且向这
些连接请求方发出“max number of clients reached”以作回应。

2 Maxmemory :最大内存

	设置redis可以使用的内存量。一旦到达内存使用上限，redis将会试图移除内部数据，移除规则可以通过maxmemory-policy来指定。如果redis无法根据移除规则来移除内存中的数据，或者设置了“不允许移除”，
那么redis则会针对那些需要申请内存的指令返回错误信息，比如SET、LPUSH等。
 
但是对于无内存申请的指令，仍然会正常响应，比如GET等。如果你的redis是主redis（说明你的redis有从redis），那么在设置内存使用上限时，需要在系统中留出一些内存空间给同步队列缓存，只有在你设置的是“不移除”的情况下，才不用考虑这个因素

3 Maxmemory-policy

面试题:如何设置redis的缓存过期清除策略
官方文档如下:

 MAXMEMORY POLICY: how Redis will select what to remove when maxmemory
 is reached. You can select among five behaviors:
 volatile-lru -> remove the key with an expire set using an LRU algorithm
 allkeys-lru -> remove any key according to the LRU algorithm
 volatile-random -> remove a random key with an expire set
 allkeys-random -> remove a random key, any key
 volatile-ttl -> remove the key with the nearest expire time (minor TTL)
 noeviction -> don't expire at all, just return an error on write operations

个人翻译如下:

LRU算法指的是: Least recently used,最近最少使用

MAXMEMORY POLICY : 当达到最大内训限制时,redis将如何选择移除那些无用,快过期的数据.共以下5个方式:也就是说下面5中缓存过期策略任选其一:默认值是noeviction,永不过期.
（1）volatile-lru：使用LRU算法移除key，只对设置了过期时间的键
（2）allkeys-lru：使用LRU算法移除key
（3）volatile-random：在过期集合中移除随机的key，只对设置了过期时间的键
（4）allkeys-random：移除随机的key
（5）volatile-ttl：移除那些TTL值最小的key，即那些最近要过期的key
（6）noeviction：永不过期,不进行移除。针对写操作，只是返回错误信息
我们可以通过来查看该处的配置,来检验公司的实力,因为noeviction选项在实际中根本不敢用来做配置,它只能用在教学环境中.

4 Maxmemory-samples:最大内存样例(默认值是5个)

设置样本数量，LRU算法和最小TTL算法都并非是精确的算法，而是估算值，所以你可以设置样本的大小，
redis默认会检查这么多个key并选择其中LRU的那个
redis在清洁时,会选取一定数量的样本来做内部的一个测试.

第九节 APPEND ONLY MODE追加(默认值是no,关闭的)

默认,redis是异步把数据存储到磁盘上,这种模式非常适合于大多数的应用,该功能默认是关闭的,默认的文件名称是 appendonly.aof ,名字保持默认就行了.redis 的强大之处就是他能够让你进行各种功能不同的选择,来达到你的需求

它也是有三种策略的 : 也就是appendsync的取值有三个:默认值是everysec.

Always：同步持久化 每次发生数据变更会被立即记录到磁盘  性能较差但数据完整性比较好(小心使用)
Everysec：出厂默认推荐，异步操作，每秒记录   如果一秒内宕机，有数据丢失,
No:它会关闭aof持久化的功能(小心使用) 

No-appendfsync-on-rewrite：重写时是否可以运用Appendfsync，用默认no即可，保证数据安全性。
Auto-aof-rewrite-min-size：设置重写的基准值,默认值64M
Auto-aof-rewrite-percentage：设置重写的基准值 默认值 100
注意:

我们一般是不会选用always的,除非你的数据非常的重要,但是如果你的机器的性能低或者SQL还有程序没有做过大的优化的话,你的系统的性能会被拖到很低.然后运维和开发的就需要动用监控,查看超过阙值的SQL,使用ps -ef等命令,杀死一些比较大长难的SQL,来保证系统的AP

下面我们来解决第二个问题,

,redis-check-aof --fix appendonly.aof ,:也就是说它会修复appendonly.aof

当<font color = red>dump.rdb </font>和<font color = red>appendonly.aof</font> 同时存在时,redis会首先加载的会是aof 来做数据的恢复.
如果我们的 appendonly.aof 文件不小心写错了(实际环境中是不允许修改这个文件的),由于redis会先加在appendonly.aof 文件进行数据的恢复,该文件有错误,redis的就会启动失败,
我们可以执行,<font color= red>redis-check-aof --fix appendonly.aof </font>,该命令的执行,会把所有不符合appendonly.aof文件语法规定的错误统统删除.**也就是说它会修复appendonly.aof** ,然后我们就可以正常的启动redis了.

第十节 常见配置redis.conf介绍

参数说明
redis.conf 配置项说明如下：
1. Redis默认不是以守护进程的方式运行，可以通过该配置项修改，使用yes启用守护进程
  daemonize no
2. 当Redis以守护进程方式运行时，Redis默认会把pid写入/var/run/redis.pid文件，可以通过pidfile指定
  pidfile /var/run/redis.pid
3. 指定Redis监听端口，默认端口为6379，作者在自己的一篇博文中解释了为什么选用6379作为默认端口，因为6379在手机按键上MERZ对应的号码，而MERZ取自意大利歌女Alessia Merz的名字
  port 6379
4. 绑定的主机地址
  bind 127.0.0.1
5.当 客户端闲置多长时间后关闭连接，如果指定为0，表示关闭该功能
  timeout 300
6. 指定日志记录级别，Redis总共支持四个级别：debug、verbose、notice、warning，默认为verbose
  loglevel verbose
7. 日志记录方式，默认为标准输出，如果配置Redis为守护进程方式运行，而这里又配置为日志记录方式为标准输出，则日志将会发送给/dev/null
  logfile stdout
8. 设置数据库的数量，默认数据库为0，可以使用SELECT <dbid>命令在连接上指定数据库id
  databases 16
9. 指定在多长时间内，有多少次更新操作，就将数据同步到数据文件，可以多个条件配合
  save <seconds> <changes>
  Redis默认配置文件中提供了三个条件：
  save 900 1
  save 300 10
  save 60 10000
  分别表示900秒（15分钟）内有1个更改，300秒（5分钟）内有10个更改以及60秒内有10000个更改。
 
10. 指定存储至本地数据库时是否压缩数据，默认为yes，Redis采用LZF压缩，如果为了节省CPU时间，可以关闭该选项，但会导致数据库文件变的巨大
  rdbcompression yes
11. 指定本地数据库文件名，默认值为dump.rdb
  dbfilename dump.rdb
12. 指定本地数据库存放目录
  dir ./
13. 设置当本机为slav服务时，设置master服务的IP地址及端口，在Redis启动时，它会自动从master进行数据同步
  slaveof <masterip> <masterport>
14. 当master服务设置了密码保护时，slav服务连接master的密码
  masterauth <master-password>
15. 设置Redis连接密码，如果配置了连接密码，客户端在连接Redis时需要通过AUTH <password>命令提供密码，默认关闭
  requirepass foobared
16. 设置同一时间最大客户端连接数，默认无限制，Redis可以同时打开的客户端连接数为Redis进程可以打开的最大文件描述符数，如果设置 maxclients 0，表示不作限制。当客户端连接数到达限制时，Redis会关闭新的连接并向客户端返回max number of clients reached错误信息
  maxclients 128
17. 指定Redis最大内存限制，Redis在启动时会把数据加载到内存中，达到最大内存后，Redis会先尝试清除已到期或即将到期的Key，当此方法处理 后，仍然到达最大内存设置，将无法再进行写入操作，但仍然可以进行读取操作。Redis新的vm机制，会把Key存放内存，Value会存放在swap区
  maxmemory <bytes>
18. 指定是否在每次更新操作后进行日志记录，Redis在默认情况下是异步的把数据写入磁盘，如果不开启，可能会在断电时导致一段时间内的数据丢失。因为 redis本身同步数据文件是按上面save条件来同步的，所以有的数据会在一段时间内只存在于内存中。默认为no
  appendonly no
19. 指定更新日志文件名，默认为appendonly.aof
   appendfilename appendonly.aof
20. 指定更新日志条件，共有3个可选值： 
  no：表示等操作系统进行数据缓存同步到磁盘（快） 
  always：表示每次更新操作后手动调用fsync()将数据写到磁盘（慢，安全） 
  everysec：表示每秒同步一次（折衷，默认值）
  appendfsync everysec
 
21. 指定是否启用虚拟内存机制，默认值为no，简单的介绍一下，VM机制将数据分页存放，由Redis将访问量较少的页即冷数据swap到磁盘上，访问多的页面由磁盘自动换出到内存中（在后面的文章我会仔细分析Redis的VM机制）
   vm-enabled no
22. 虚拟内存文件路径，默认值为/tmp/redis.swap，不可多个Redis实例共享
   vm-swap-file /tmp/redis.swap
23. 将所有大于vm-max-memory的数据存入虚拟内存,无论vm-max-memory设置多小,所有索引数据都是内存存储的(Redis的索引数据 就是keys),也就是说,当vm-max-memory设置为0的时候,其实是所有value都存在于磁盘。默认值为0
   vm-max-memory 0
24. Redis swap文件分成了很多的page，一个对象可以保存在多个page上面，但一个page上不能被多个对象共享，vm-page-size是要根据存储的 数据大小来设定的，作者建议如果存储很多小对象，page大小最好设置为32或者64bytes；如果存储很大大对象，则可以使用更大的page，如果不 确定，就使用默认值
   vm-page-size 32
25. 设置swap文件中的page数量，由于页表（一种表示页面空闲或使用的bitmap）是在放在内存中的，，在磁盘上每8个pages将消耗1byte的内存。
   vm-pages 134217728
26. 设置访问swap文件的线程数,最好不要超过机器的核数,如果设置为0,那么所有对swap文件的操作都是串行的，可能会造成比较长时间的延迟。默认值为4
   vm-max-threads 4
27. 设置在向客户端应答时，是否把较小的包合并为一个包发送，默认为开启
  glueoutputbuf yes
28. 指定在超过一定的数量或者最大的元素超过某一临界值时，采用一种特殊的哈希算法
  hash-max-zipmap-entries 64
  hash-max-zipmap-value 512
29. 指定是否激活重置哈希，默认为开启（后面在介绍Redis的哈希算法时具体介绍）
  activerehashing yes
30. 指定包含其它的配置文件，可以在同一主机上多个Redis实例之间使用同一份配置文件，而同时各个实例又拥有自己的特定配置文件
  include /path/to/local.conf

第六章 Redis的持久化,重点中的重点

面试题1 :什么是redis的持久化?

这时就别废话,直接要出口 ,RDB 和 AOF 这两个关键字眼

第一节 总体介绍

第二节 RDB（Redis DataBase）

2 是什么：

在指定的时间间隔内将内存中的数据集快照写入磁盘，
也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里
Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到
一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。
整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能
如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方
式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。

3 Fork

Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等）
数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程
fork的隐患:如果我们当前的系统比较紧张,然后我们的宿主程序又比较的大,如果我们fork了一个子进程做备份,那么会非常消耗资源,导致性能下降.

4 Rdb 保存的是dump.rdb文件

RDB会包snapshot快照以文件的形式保存在磁盘上个 ,名称就是dump.rdb.记住,
保存的备份文件dump.rdb文件在实际的生产换件中,称为是容灾备份,
备份的文件一定要和生产环境的主机相分离,放在备份机上,为了保证数据的及时恢复
redis在数据恢复时,不管你有多少个.rdb文件,它默认值读取dump.rdb

注意:dump.rdb的数据恢复策略如下:

当我们执行shutdown或者flushall命令之后,就像在mysql中执行了commit操作是一样的,会立马把内存中的数据存储到磁盘,在磁盘上会产生dump.rdb文件,但是flushall会把内存中的数据清空,所以产生的dump.rdb文件其实是空的.
redis每次重启默认都会加载dump.rdb文件,恢复数据到内存中.如果我们主机的dump.rdb文件被损坏或者为空,一般都是运维的兄弟,会从备份机器上给传过来我们一份备份文件,然后我们把原来的dump.rdb文件删除,然后把传过来的文件重命名为dump.rdb,然后重启redis服务器,数据就可以恢复了.

5 配置位置

6 如何触发RDB快照

(1).符合我们对配置文件redis.conf中snapshotting的默认配置,例如我们例子中的,2min写入10次.默认的是1min 1w 次, 5min  10次 , 15min  1次都可以出发snapshotting操作.
(2) 主机和备份机一定要分开,如果备份的dum.rdb文件放在了主机上,主机一旦出了问题,想恢复都很难.使用 cp 备份的dump.rdb dump.rdb.这样redis在重启的时候就会通过dump.rdb把数加载到内存进行恢复.也就是冷拷贝后重新使用(冷拷贝指的是备份机拷贝到主机).
(3) 命令 save 和 bgsave 都可以迅速马上生成dump.rdb文件.
但是 Save：save时只管保存，其它不管，全部阻塞,执行save操作时,数据不能写入,写操作会被阻塞
BGSAVE：Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。可以通过lastsave命令获取最后一次成功执行快照的时间
(4) 执行flushall也会差生dump.rdb文件,但是该文件是空的,没有任何数据,也就是没有意义的.

7 如何恢复

如何恢复数据?

将备份文件(dump.rdb)移动到redis的安装目录,并且启动redis服务即可.(redis服务启动会自动加载dump.rdb文件,把数据加载到内存)
redis登录成功之后,执行 config get dir 可以查看出redis的安装路径.:

8 优势

适合大规模的数据恢复
对数据的完整性和一致性要求不高.(因为在备份的时候如果出现了故障,例如在备份的时候我们 kill 了备份的进程,那么就会导致最后一次的数据没有备份,但之前的都还在.)

9 劣势

在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改,会导致最后一次时间间隔内的数据没有被备份.
Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑

10 如何停止

动态所有停止RDB保存规则的方法：redis-cli config set save "",虽然我们一般都会使用中主从复制来进行数据的备份,但是我们一般也不会关闭RDB备份,防止万一.

11 小总结

第三节 AOF（Append Only File）

AOF的引出:(RDB最大的缺陷就是可能会丢失最后一次的数据,最后一次的数据可能会没有备份,但是从工作来说,影响并不是很大,但是redis的技术大牛,可能是处于对技术的极致的追求,还真的把这个问题给解决了,最后的实际效果可能会损失1秒左右的数据)

新技术的出现,一定要弥补老技术的不足,RDB可以完成数据的恢复,为什么还要出AOF?
系统中同时出现RDB和AOF,那么二者是冲突还是协作的关系?
为什么AOF在RDB之后产生?
AOF的优缺点?

1.是什么：

它是以日志的形式记录.

以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)，
只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis
重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作

2.AOF保存的是appendonly.aof文件

3.配置位置

4.AOF启动/修复/恢复

正常恢复:

启动：设置Yes 修改默认的appendonly no，改为yes
将有数据的aof文件复制一份保存到当前你redis启动所在的目录(config get dir:可以获取redis是在那个目录下启动的)
恢复：重启redis然后重新加载

异常恢复:

启动：设置Yes 修改默认的appendonly no，改为yes
备份被写坏的AOF文件
修复：Redis-check-aof --fix appendofly.aof的备份文件进行修复
恢复：重启redis然后重新加载

小结:

如果redis能够正常启动,说明appendonly.aof文件是没有任何问题的,可以直接启动redis,它会通过对appendonly.aof的加载来恢复数据
如果redis启动失败,(可以通过ps -ef | grep redis 来查看是否启动成功),使用命令: redis-check-aof --fix appenonly.aof来对已经备份过的aof文件进行修复,修复完成之后,重新启动redis(教学的haul备份文件都是在主机上,真正的话容灾备份文件肯定是在备机上,和主机是分离的,一般备份文件都是运维的发过来的)

举一反三:

5.Rewrite(重写)

aof的优势很明显,但是在实际的生产环境中,这个appendonly.aof文件的膨胀性非常快,占用的内存也会越来越大.例如,如果 incr k1,一共被执行了100w次,由于appendonly.aof文件会在后台偷偷的记录所有的写操作,他在文件内部就会写100w次的 incr k1,那么我们可想而知,记录了很多无用的操作,我们不如直接写 ince k1 100w,这就引发rewrite,它会

rewrite的功能就是,
精简并且重写appendonly.aof,压缩它的大小.那么如何进行压缩和精简,触发条件优势什么呢?

1 是什么：

AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制,
当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，
只保留可以恢复数据的最小指令集.可以使用命令bgrewriteaof

2 重写原理

AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)，
遍历新进程的内存中数据，每条记录有一条的Set语句。重写aof文件的操作，并没有读取旧的aof文件，
而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似

3 触发机制

Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发Rewrite

如果你进的公司在使用redis,你可以偷偷的打开redis.conf然后找到上图中的值,
Auto-aof-rewrite-min-size：设置重写的基准值,默认是64M
Auto-aof-rewrite-percentage：设置重写的基准值,100表示是之前aof文件的一倍大小
如果使用的还是默认值64M,那么这个公司对redis的使用也就很一般,一般大型的公司该值的大小起步就是3GB.

6.优势

每修改同步：appendfsync always   同步持久化 每次发生数据变更会被立即记录到磁盘  性能较差但数据完整性比较好
每秒同步：appendfsync everysec    异步操作，每秒记录   如果一秒内宕机，有数据丢失
不同步：appendfsync no   从不同步

7.劣势

相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb
Aof运行效率要慢于rdb,每秒同步策略效率较好，不同步效率和rdb相同

最担心的还是aof的文件比较的大,然后你在恢复的过程再次宕机.这个就比较尴尬了.

8.小总结

第四节 总结(Which one)

RDB和AOF都聊完了,最终我们要选择使用哪个来做数据恢复呢?

官网建议翻译如下:

RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储
AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些
命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾.
Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大
只做缓存：如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化方式.

同时开启两种持久化方式

性能建议

小结:
rdb,不完美,数据不完整,当程序较大时fork子进程,2倍的数据膨胀性需要考虑.,aof他虽然解决了rdb的数据不准确性和数据膨胀性,但是也带来了新的问题,它会有频繁的IO和rewrite重写操作,IO是很消耗性能的,然后我们又利用主从复制来解决aof的问题.

第七章 Redis的事务

是什么

可以一次执行多个命令，本质是一组命令的集合。一个事务中的
所有命令都会序列化，按顺序地串行化执行而不会被其它命令插入，不许加塞

能干嘛

一个队列中，一次性、顺序性、排他性的执行一系列命令

怎么玩

简单来说:

multi:开始一个事务(它会恢复OK,它会把你接下来的指令全部入队,但是还没有执行)
exec:执行事务
discard:放弃事务

1.常用命令

2.Case1：正常执行

3.Case2：放弃事务

4.Case3：全体连坐

顾名思义就是,只要事务或者是批量的命令中有一个出现了错误,该批量所有命令都不会被执行.

5.Case4：冤头债主

注意:

	在批量操作时,有些命令,我们还没有执行exec时,就已经报错了,.比如你的命令写错了,或者系统认为你的命令危险比较大时,那么会导致全体连坐,这一批命令全部都刽被执行 戏称为是 全体连坐
	有些命令只有在运行时才会报错,例如,incr k1,那么这时只有出错的命令不会被执行,并且报错,事务中其他没有出错的都会被正常执行,戏称为是 冤头债主
	由以上两种情况可以检出,redis其实是部分支持事务的,它并没有像mysql,Oracle那样对数据强一致性.正确的命令还是正常执行,错误的命令就不执行,不会影响正确的命令.谁出错了,就报谁的错

6.Case5：watch监控,重点,非常重点,绝对的重点.

由于这个redis多用于在高并发的环境,缓存中的数据大家都经常进行修改,为了避免发生冲突和数据的覆盖,我们需要使用锁和对数据进行标记.

乐观锁,悲观锁 ,CAS (Check And Set)
悲观锁:

悲观锁,他认为数据一定会被修改,所以它给整张表加锁了.(其实这个悲观锁和乐观锁,非常像mysql中的表锁和行锁.),它会把整张表给加锁

乐观锁:(工作中一般都是乐观锁)

他认为数据不会被修改,但是不怕一万就怕万一了,乐观锁想到了一个法办法,既保证了高并发,又能够不锁整张表,他在每条记录的后面添加了一个version字段,就是版本号,
例如,当有多个客户端,甲和乙同时修改同一条数据D,甲修改的是电话号,乙修改的是微信号,二者在修改之前都要先到数据库中拿到数据D,假如乙比甲晚一步拿到了数据D,D数据的version字段默认值是1,
甲在修改完电话号之后,同时在version基础上进行值加1 ,变成了2进行了数据的提交,而乙拿到的数据D中的version的值是1,他在修改完成后进行数据发现,version也会加1,但是并没有大于服务器上的version的值,一旦提交,立即报异常.他表示的就是乙拿到的不是最新的数据,此次修改是无效的,需要重新去数据库中获取最新的数据进行修改.

示例如下
初始化信用卡可用余额和欠额

无加塞篡改，先监控再开启multi，保证两笔金额变动在同一个事务内

有加塞篡改

监控了key，如果key被修改了，后面一个事务的执行失效

Unwatch:

一旦执行了 UNwatch 和 exec 之前加的监控锁都会被取消掉了

小结:

Watch指令，类似乐观锁，事务提交时，如果Key的值已被别的客户端改变，
比如某个list已被别的客户端push/pop过了，整个事务队列都不会被执行
通过WATCH命令在事务执行之前监控了多个Keys，倘若在WATCH之后有任何Key的值发生了变化，
EXEC命令执行的事务都将被放弃，同时返回Nullmulti-bulk应答以通知调用者事务执行失败

3阶段 

3特性

第八章 Redis的发布订阅
redis在高速缓存方面干掉了memcache,他自身其实也支持用来做消息中间件的,企业很少拿它来做消息中间件,多数还是做分布式的数据缓存.

是什么

进程间的一种消息通信模式：发送者(pub)发送消息，订阅者(sub)接收消息。大致就是,客户端订阅了频道a,当发布者通过命令publish把消息发送到频道a上时,它的订阅者们都能接收到这个信息.

消息订阅图:

命令

案例

1 可以一次性订阅多个，SUBSCRIBE c1 c2 c3
2 消息发布，PUBLISH c2 hello-redis
3 订阅多个，通配符*， PSUBSCRIBE new*
4 收取消息， PUBLISH new1 redis2015

第九章 Redis的复制(Master/Slave)
cd REPLICATION复制

是什么

行话：也就是我们所说的主从复制，主机数据更新后根据配置和策略，
自动同步到备机的master/slaver机制，Master以写为主，Slave以读为主

能干嘛

读写分离
容灾恢复

怎么玩

1.配从(库)不配主(库)

2.从库配置：slaveof 主库IP 主库端口

每次与master断开之后，都需要重新连接，除非你配置进redis.conf文件
Info replication

3.修改配置文件细节操作

4.常用3招

4.1 一主二仆(它是主从复制中最常用的)

info replication :可以用来查看当前的机器到底是主机还是从机,是主机的话包含了几台从机,以及从机的信息.
slaveof 主机 端口号:为当前机器设置主机,自己也随之变成了从机.(只要执行了该命令,从机会把主机上所有的数据都进行备份,无论是主从关系创建的前后,主机中包含的所有数据都可以在从机中拿到)
如果在从机上执行写操作是要报错的,读操作只能在主机上执行,这就是读写分离

当如果主机意外宕机死掉了,从机是抢班夺上位,还是保持原地待命,等待主机归来呢?

主机意外宕机的话,从机并不会升级成为主机,不会发生野鸡变凤凰,从机们依然会原地待命,保持原来的状态,只不过连接状态由up变成了down,等待主机恢复,但是从机中的数据都还在,不会丢失,

如果主机宕机死掉了,从机们会原地待命,然后主机又活了,从机们会继续保持原来的主从关系吗?是照旧,还是原来的体系发生崩溃?

主机恢复之后,之前的主从关系在当前这种配置下,依然保留,从机的连接状态会从down变为up,不会发生从机变成主机的情况,非常像是领导出差了,小的们原地待命,领导回来之后,大家依然如旧.就当做设么都没有发生一样的.

如果系统的主机从机们正在正茬网运行,突然从机宕机了,那么从机恢复之后,是称为主机,还是续接上之间的主从关系呢?到底会发生什么呢?

从机会变成master,之前的没发生故障的主机从机依然保持正常的主从关系,宕机的从机会变成一个没有任何从机的主机 ,宕机之后的从机依然表留着没宕机之前的数据,但是宕机期间的原来主机的数据它是没有的.
只要和master断开了,都重新建立关系,除非你把这种关系写入配置文件redis.conf中保存,那样 断开之后依然可以保存这种主从关系.

4.2 薪火相传

命令:slaveof 新主库的ip 新主库的端口: 
上一个Slave可以是下一个slave的Master，Slave同样可以接收其他
slaves的连接和同步请求，那么该slave作为了链条中下一个的master,
可以有效减轻master的写压力
中途变更转向:会清除之前的数据，重新建立拷贝最新的,保证数据的一致,完整和有效性.
除了第一个主机和最后一个从机之外,中间的每一个机器既是上一个机器的从机,又是下一个的主机,但总体而言还是从机.

按照刚才一主二仆的模式来说,当然也可以一主,三 四等,但是中心化比较的严重,薪火相传主要是为了减轻master的负担,但是这种模式也有缺点,就是在传递的过程中,数据复制的延时,

4.3 反客为主

简单理解起来就是,主机宕机了,在和主机数据相一致的从机中选出来一个当主机用,
slaveof no one : 手动的把该从机神升级成主机.使得当前数据库停止和其他的数据库的同步.

如果,主机宕机了,我们手动的选了一个从机升级成了主机,手动的把其他的从机连接到了新主机上,此时如果原来的主机恢复的话怎么办?

由于原来的主机宕机了之后m,我们手动的修改了这个主从关系,新的关系格局已经确定了,恢复过来的老主机已经和新确定的主从关系没有了任何的联系,已经变成了一个没有任何从机的master.

复制原理

总结出来就是一句话:首次连接master是全量复制,之后的都是增量复制.

Slave启动成功连接到master后会发送一个sync命令
Master接到命令启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，
在后台进程执行完毕之后，master将传送整个数据文件到slave,以完成一次完全同步
全量复制：而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中。
增量复制：Master继续将新的所有收集到的修改命令依次传给slave,完成同步
但是只要是重新连接master,一次完全同步（全量复制)将被自动执行

哨兵模式(sentinel)

反客为主的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库
一组sentinel能同时监控多个Master

怎么玩

1.调整结构，6379带着80、81

2.自定义的/myredis目录下新建sentinel.conf文件，名字绝不能错

3.配置哨兵,填写内容

 sentinel monitor 被监控的主机名字(自己起名字) 127.0.0.1 6379 1
 上面最后一个数字1，其实是票数,表示主机挂掉后salve投票看让谁接替成为主机，得票数多少后成为主机

4.启动哨兵

Redis-sentinel /myredis/sentinel.conf 
上述目录依照各自的实际情况配置，可能目录不同

5.正常主从演示

6.原有的master挂了

7.投票新选

8.重新主从继续开工,info replication查查看

9.问题：如果之前的master重启回来，会不会双master冲突？

原来的主机a宕机之后如果恢复了,如果a还没有被哨兵所监控到,那么它就是一个没有任何从机的主机,一旦被哨兵监控到,就会让它变成现在主机的从机.不会像之前的一主二仆那样,和新的主从结构毫无关系.

复制的缺点

由于所有的写操作都是先在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使这个问题更加严重。

第十章 Redis的Java客户端Jedis