Redis知识总结

时间 2019-11-07

标签 redis 知识总结栏目 Redis 繁體版

原文原文链接

最近在学校参与了一些项目，其中包含单点登录(集群)，由于使用的redis，因此这里简单对redis作一个学习总结，reids的API的话就不放在本文浪费时间了，主要谈谈知识的自己node

在开始redis以前，咱们要了解，如今看成非关系型数据库远远不止redis这一种，固然，之后可能也会更多，如果要依次学习全部的这类数据库，那是很困难的，但他们都属于nosql(not only sql非关系型数据库)，因此，咱们有必要先了解其根源，找到他们的通性，从其名字也能够看出，他和关系型数据库不是对立的，更多的是一种补充程序员

Nosql

为何要有Nosql?

目前互联网对技术提出了更多的要求，主要体如今如下方面：web

低延迟的读写速度：应用快速地反应能极大地提高用户的满意度;
海量的数据和流量：对于搜索这样大型应用而言，须要利用PB级别的数据和能应对百万级的流量;
大规模集群的管理：系统管理员但愿分布式应用能更简单的部署和管理;
庞大运营成本的考量：IT经理们但愿在硬件成本、软件成本和人力成本可以有大幅度地下降;

可是，关系型数据库因为自身的特色，让他很难实现这些需求：redis

扩展困难
读写慢
成本高
支撑容量有限

因此，Nosql很是关注并发读写，大量数据存储，它的优势以下：算法

高可扩展性
分布式计算
低成本
架构的灵活性，半结构化数据
没有复杂的关系

固然，Nosql也有缺点：sql

不提供SQL语句支持
特性不够多(例如事务，在等会redis中会总结)

Nosql四大分类

键值(Key-Value)存储数据库

相关产品： Tokyo Cabinet/Tyrant、Redis、Voldemort、Berkeley DB 典型应用：内容缓存，主要用于处理大量数据的高访问负载。数据模型：一系列键值对优点：快速查询劣势：存储的数据缺乏结构化数据库

列存储数据库

相关产品：Cassandra, HBase, Riak 典型应用：分布式的文件系统数据模型：以列簇式存储，将同一列数据存在一块儿优点：查找速度快，可扩展性强，更容易进行分布式扩展劣势：功能相对局限缓存

文档型数据库

相关产品：CouchDB、MongoDB 典型应用：Web应用(与Key-Value相似，Value是结构化的) 数据模型：一系列键值对优点：数据结构要求不严格劣势：查询性能不高，并且缺少统一的查询语法安全

图形(Graph)数据库

相关数据库：Neo4J、InfoGrid、Infinite Graph 典型应用：社交网络数据模型：图结构优点：利用图结构相关算法。劣势：须要对整个图作计算才能得出结果，不容易作分布式的集群方案。bash

CAP定理

CAP定理意思是在分布式计算系统中，只能同时最多知足如下两点：

一致性(Consistency) (全部节点在同一时间具备相同的数据)
可用性(Availability) (保证每一个请求无论成功或者失败都有响应)
分隔容忍(Partition tolerance) (系统中任意信息的丢失或失败不会影响系统的继续运做) CAP理论的核心是：一个分布式系统不可能同时很好的知足一致性，可用性和分区容错性这三个需求，最多只能同时较好的知足两个。

所以，根据 CAP 原理将 NoSQL 数据库分红了知足 CA 原则、知足 CP 原则和知足 AP 原则三大类：

CA - 单点集群，知足一致性，可用性的系统，一般在可扩展性上不太强大。(传统Oracle数据库)
CP - 知足一致性，分区容忍性的系统，一般性能不是特别高。(Redis、Mongodb)
AP - 知足可用性，分区容忍性的系统，一般可能对一致性要求低一些。(大多数网站架构的选择)

注意：分布式架构的时候必须作出取舍。一致性和可用性之间取一个平衡。多余大多数web应用，其实并不须要强一致性。所以牺牲C换取P，这是目前分布式数据库产品的方向

Nosql总结

综上所述，Nosql的出现更多的是为了解决数据量大，分布式中的问题，为了数据吞吐量上的数量而对数据一致性打一点折扣。

e.g:

微博上一篇文章的点赞数，可能三秒内就会新增几百个赞(行为数据)，这时，不可能保证用户点一个赞就更新一次，这时，就可使用Nosql了。

而对于像转帐这类(交易数据)的事务型操做，只能使用关系型数据库了。

Redis

Redis是什么

它是一个缓存数据库，由C语言编写，key-value存储系统，属于nosql

五大基本数据类型

1.字符串类型(String) 2.散列类型(hash) 3.列表类型(list) 4.集合类型(set) 5.有序集合类型(zset)

由于redis中都是存取的k-v键值对形式，这里的基本数据类型指的是value的数据类型，全部的key都是字符串类型

关于它的API，这里就不赘述了，看官方文档便可

字符串类型

字符串是Redis最基本的数据类型，不只全部key都是字符串类型，其它几种数据类型构成的元素也是字符串。注意字符串的长度不能超过512M。

这里的字符串能够是字符串，整数或者是浮点数，例如想知道一个ip访问了多少次本网站，就能够用INCRBY实现递增。

列表类型

一个List结构能够有序的存储多个字符串，而且是容许元素重复的，能够按照插入顺序排序，能够添加一个元素到列表的头部（左边）或者尾部（右边），它的底层其实是个双向链表结构。

Set集合类型

集合对象 set 是 string 类型（整数也会转换成string类型进行存储）的无序集合。经过散列表来保证本身存储的每一个字符串都是各不相同的，即内部使用值为空的散列表。

集合和列表的区别：集合中的元素是无序的，所以不能经过索引来操做元素；集合中的元素不能有重复。

Hash散列类型

哈希对象的键是一个字符串类型，值是一个键值对集合。

有序集合ZSET

有序集合对象是有序的。与列表使用索引下标做为排序依据不一样，有序集合为每一个元素设置一个分数（score）做为排序依据。

应用场景

对于string 数据类型，由于string 类型是二进制安全的，能够用来存放图片，视频等内容，另外因为Redis的高性能读写功能，而string类型的value也能够是数字，能够用做计数器（INCR,DECR），好比分布式环境中统计系统的在线人数，秒杀等。
对于 hash 数据类型，value 存放的是键值对，好比能够作单点登陆存放用户信息。
对于 list 数据类型，能够实现简单的消息队列，另外能够利用lrange命令，作基于redis的分页功能
对于 set 数据类型，因为底层是字典实现的，查找元素特别快，另外set 数据类型不容许重复，利用这两个特性咱们能够进行全局去重，好比在用户注册模块，判断用户名是否注册；另外就是利用交集、并集、差集等操做，能够计算共同喜爱，所有的喜爱，本身独有的喜爱等功能。
对于 zset 数据类型，有序的集合，能够作范围查找，排行榜应用，取 TOP N 操做等。

配置文件介绍

#redis.conf
# Redis configuration file example.
# ./redis-server /path/to/redis.conf

################################## INCLUDES ###################################
#这在你有标准配置模板可是每一个redis服务器又须要个性设置的时候颇有用。
# include /path/to/local.conf
# include /path/to/other.conf

################################ GENERAL #####################################

#是否在后台执行，yes：后台运行；no：不是后台运行（老版本默认）
daemonize yes

  #3.2里的参数，是否开启保护模式，默认开启。要是配置里没有指定bind和密码。开启该参数后，redis只会本地进行访问，拒绝外部访问。要是开启了密码 和bind，能够开启。否 则最好关闭，设置为no。
  protected-mode yes
#redis的进程文件
pidfile /var/run/redis/redis-server.pid

#redis监听的端口号。
port 6379

#此参数肯定了TCP链接中已完成队列(完成三次握手以后)的长度， 固然此值必须不大于Linux系统定义的/proc/sys/net/core/somaxconn值，默认是511，而Linux的默认参数值是128。当系统并发量大而且客户端速度缓慢的时候，能够将这二个参数一块儿参考设定。该内核参数默认值通常是128，对于负载很大的服务程序来讲大大的不够。通常会将它修改成2048或者更大。在/etc/sysctl.conf中添加:net.core.somaxconn = 2048，而后在终端中执行sysctl -p。
tcp-backlog 511

#指定 redis 只接收来自于该 IP 地址的请求，若是不进行设置，那么将处理全部请求
bind 127.0.0.1

#配置unix socket来让redis支持监听本地链接。
# unixsocket /var/run/redis/redis.sock
#配置unix socket使用文件的权限
# unixsocketperm 700

# 此参数为设置客户端空闲超过timeout，服务端会断开链接，为0则服务端不会主动断开链接，不能小于0。
timeout 0

#tcp keepalive参数。若是设置不为0，就使用配置tcp的SO_KEEPALIVE值，使用keepalive有两个好处:检测挂掉的对端。下降中间设备出问题而致使网络看似链接却已经与对端端口的问题。在Linux内核中，设置了keepalive，redis会定时给对端发送ack。检测到对端关闭须要两倍的设置值。
tcp-keepalive 0

#指定了服务端日志的级别。级别包括：debug（不少信息，方便开发、测试），verbose（许多有用的信息，可是没有debug级别信息多），notice（适当的日志级别，适合生产环境），warn（只有很是重要的信息）
loglevel notice

#指定了记录日志的文件。空字符串的话，日志会打印到标准输出设备。后台运行的redis标准输出是/dev/null。
logfile /var/log/redis/redis-server.log

#是否打开记录syslog功能
# syslog-enabled no

#syslog的标识符。
# syslog-ident redis

#日志的来源、设备
# syslog-facility local0

#数据库的数量，默认使用的数据库是DB 0。能够经过”SELECT “命令选择一个db
databases 16

################################ SNAPSHOTTING ################################
# 快照配置
# 注释掉“save”这一行配置项就可让保存数据库功能失效
# 设置sedis进行数据库镜像的频率。
# 900秒（15分钟）内至少1个key值改变（则进行数据库保存--持久化） 
# 300秒（5分钟）内至少10个key值改变（则进行数据库保存--持久化） 
# 60秒（1分钟）内至少10000个key值改变（则进行数据库保存--持久化）
save 900 1
save 300 10
save 60 10000

#当RDB持久化出现错误后，是否依然进行继续进行工做，yes：不能进行工做，no：能够继续进行工做，能够经过info中的rdb_last_bgsave_status了解RDB持久化是否有错误
stop-writes-on-bgsave-error yes

#使用压缩rdb文件，rdb文件压缩使用LZF压缩算法，yes：压缩，可是须要一些cpu的消耗。no：不压缩，须要更多的磁盘空间
rdbcompression yes

#是否校验rdb文件。从rdb格式的第五个版本开始，在rdb文件的末尾会带上CRC64的校验和。这跟有利于文件的容错性，可是在保存rdb文件的时候，会有大概10%的性能损耗，因此若是你追求高性能，能够关闭该配置。
rdbchecksum yes

#rdb文件的名称
dbfilename dump.rdb

#数据目录，数据库的写入会在这个目录。rdb、aof文件也会写在这个目录
dir /var/lib/redis

################################# REPLICATION #################################
#复制选项，slave复制对应的master。
# slaveof <masterip> <masterport>

#若是master设置了requirepass，那么slave要连上master，须要有master的密码才行。masterauth就是用来配置master的密码，这样能够在连上master后进行认证。
# masterauth <master-password>

#当从库同主机失去链接或者复制正在进行，从机库有两种运行方式：1) 若是slave-serve-stale-data设置为yes(默认设置)，从库会继续响应客户端的请求。2) 若是slave-serve-stale-data设置为no，除去INFO和SLAVOF命令以外的任何请求都会返回一个错误”SYNC with master in progress”。
slave-serve-stale-data yes

#做为从服务器，默认状况下是只读的（yes），能够修改为NO，用于写（不建议）。
slave-read-only yes

#是否使用socket方式复制数据。目前redis复制提供两种方式，disk和socket。若是新的slave连上来或者重连的slave没法部分同步，就会执行全量同步，master会生成rdb文件。有2种方式：disk方式是master建立一个新的进程把rdb文件保存到磁盘，再把磁盘上的rdb文件传递给slave。socket是master建立一个新的进程，直接把rdb文件以socket的方式发给slave。disk方式的时候，当一个rdb保存的过程当中，多个slave都能共享这个rdb文件。socket的方式就的一个个slave顺序复制。在磁盘速度缓慢，网速快的状况下推荐用socket方式。
repl-diskless-sync no

#diskless复制的延迟时间，防止设置为0。一旦复制开始，节点不会再接收新slave的复制请求直到下一个rdb传输。因此最好等待一段时间，等更多的slave连上来。
repl-diskless-sync-delay 5

#slave根据指定的时间间隔向服务器发送ping请求。时间间隔能够经过 repl_ping_slave_period 来设置，默认10秒。
# repl-ping-slave-period 10

#复制链接超时时间。master和slave都有超时时间的设置。master检测到slave上次发送的时间超过repl-timeout，即认为slave离线，清除该slave信息。slave检测到上次和master交互的时间超过repl-timeout，则认为master离线。须要注意的是repl-timeout须要设置一个比repl-ping-slave-period更大的值，否则会常常检测到超时。
# repl-timeout 60

#是否禁止复制tcp连接的tcp nodelay参数，可传递yes或者no。默认是no，即便用tcp nodelay。若是master设置了yes来禁止tcp nodelay设置，在把数据复制给slave的时候，会减小包的数量和更小的网络带宽。可是这也可能带来数据的延迟。默认咱们推荐更小的延迟，可是在数据量传输很大的场景下，建议选择yes。
repl-disable-tcp-nodelay no

#复制缓冲区大小，这是一个环形复制缓冲区，用来保存最新复制的命令。这样在slave离线的时候，不须要彻底复制master的数据，若是能够执行部分同步，只须要把缓冲区的部分数据复制给slave，就能恢复正常复制状态。缓冲区的大小越大，slave离线的时间能够更长，复制缓冲区只有在有slave链接的时候才分配内存。没有slave的一段时间，内存会被释放出来，默认1m。
# repl-backlog-size 5mb

#master没有slave一段时间会释放复制缓冲区的内存，repl-backlog-ttl用来设置该时间长度。单位为秒。
# repl-backlog-ttl 3600

#当master不可用，Sentinel会根据slave的优先级选举一个master。最低的优先级的slave，当选master。而配置成0，永远不会被选举。
slave-priority 100

#redis提供了可让master中止写入的方式，若是配置了min-slaves-to-write，健康的slave的个数小于N，mater就禁止写入。master最少得有多少个健康的slave存活才能执行写命令。这个配置虽然不能保证N个slave都必定能接收到master的写操做，可是能避免没有足够健康的slave的时候，master不能写入来避免数据丢失。设置为0是关闭该功能。
# min-slaves-to-write 3

#延迟小于min-slaves-max-lag秒的slave才认为是健康的slave。
# min-slaves-max-lag 10

# 设置1或另外一个设置为0禁用这个特性。
# Setting one or the other to 0 disables the feature.
# By default min-slaves-to-write is set to 0 (feature disabled) and
# min-slaves-max-lag is set to 10.

################################## SECURITY ###################################
#requirepass配置可让用户使用AUTH命令来认证密码，才能使用其余命令。这让redis可使用在不受信任的网络中。为了保持向后的兼容性，能够注释该命令，由于大部分用户也不须要认证。使用requirepass的时候须要注意，由于redis太快了，每秒能够认证15w次密码，简单的密码很容易被攻破，因此最好使用一个更复杂的密码。
# requirepass foobared

#把危险的命令给修改为其余名称。好比CONFIG命令能够重命名为一个很难被猜到的命令，这样用户不能使用，而内部工具还能接着使用。
# rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52

#设置成一个空的值，能够禁止一个命令
# rename-command CONFIG ""
################################### LIMITS ####################################

# 设置能连上redis的最大客户端链接数量。默认是10000个客户端链接。因为redis不区分链接是客户端链接仍是内部打开文件或者和slave链接等，因此maxclients最小建议设置到32。若是超过了maxclients，redis会给新的链接发送’max number of clients reached’，并关闭链接。
# maxclients 10000

#redis配置的最大内存容量。当内存满了，须要配合maxmemory-policy策略进行处理。注意slave的输出缓冲区是不计算在maxmemory内的。因此为了防止主机内存使用完，建议设置的maxmemory须要更小一些。
# maxmemory <bytes>

#内存容量超过maxmemory后的处理策略。
#volatile-lru：利用LRU算法移除设置过过时时间的key。
#volatile-random：随机移除设置过过时时间的key。
#volatile-ttl：移除即将过时的key，根据最近过时时间来删除（辅以TTL）
#allkeys-lru：利用LRU算法移除任何key。
#allkeys-random：随机移除任何key。
#noeviction：不移除任何key，只是返回一个写错误。
#上面的这些驱逐策略，若是redis没有合适的key驱逐，对于写命令，仍是会返回错误。redis将再也不接收写请求，只接收get请求。写命令包括：set setnx setex append incr decr rpush lpush rpushx lpushx linsert lset rpoplpush sadd sinter sinterstore sunion sunionstore sdiff sdiffstore zadd zincrby zunionstore zinterstore hset hsetnx hmset hincrby incrby decrby getset mset msetnx exec sort。
# maxmemory-policy noeviction

#lru检测的样本数。使用lru或者ttl淘汰算法，从须要淘汰的列表中随机选择sample个key，选出闲置时间最长的key移除。
# maxmemory-samples 5

############################## APPEND ONLY MODE ###############################
#默认redis使用的是rdb方式持久化，这种方式在许多应用中已经足够用了。可是redis若是中途宕机，会致使可能有几分钟的数据丢失，根据save来策略进行持久化，Append Only File是另外一种持久化方式，能够提供更好的持久化特性。Redis会把每次写入的数据在接收后都写入 appendonly.aof 文件，每次启动时Redis都会先把这个文件的数据读入内存里，先忽略RDB文件。
appendonly no

#aof文件名
appendfilename "appendonly.aof"

#aof持久化策略的配置
#no表示不执行fsync，由操做系统保证数据同步到磁盘，速度最快。
#always表示每次写入都执行fsync，以保证数据同步到磁盘。
#everysec表示每秒执行一次fsync，可能会致使丢失这1s数据。
appendfsync everysec

# 在aof重写或者写入rdb文件的时候，会执行大量IO，此时对于everysec和always的aof模式来讲，执行fsync会形成阻塞过长时间，no-appendfsync-on-rewrite字段设置为默认设置为no。若是对延迟要求很高的应用，这个字段能够设置为yes，不然仍是设置为no，这样对持久化特性来讲这是更安全的选择。设置为yes表示rewrite期间对新写操做不fsync,暂时存在内存中,等rewrite完成后再写入，默认为no，建议yes。Linux的默认fsync策略是30秒。可能丢失30秒数据。
no-appendfsync-on-rewrite no

#aof自动重写配置。当目前aof文件大小超过上一次重写的aof文件大小的百分之多少进行重写，即当aof文件增加到必定大小的时候Redis可以调用bgrewriteaof对日志文件进行重写。当前AOF文件大小是上第二天志重写获得AOF文件大小的二倍（设置为100）时，自动启动新的日志重写过程。
auto-aof-rewrite-percentage 100
#设置容许重写的最小aof文件大小，避免了达到约定百分比但尺寸仍然很小的状况还要重写
auto-aof-rewrite-min-size 64mb

#aof文件可能在尾部是不完整的，当redis启动的时候，aof文件的数据被载入内存。重启可能发生在redis所在的主机操做系统宕机后，尤为在ext4文件系统没有加上data=ordered选项（redis宕机或者异常终止不会形成尾部不完整现象。）出现这种现象，能够选择让redis退出，或者导入尽量多的数据。若是选择的是yes，当截断的aof文件被导入的时候，会自动发布一个log给客户端而后load。若是是no，用户必须手动redis-check-aof修复AOF文件才能够。
aof-load-truncated yes

################################ LUA SCRIPTING ###############################
# 若是达到最大时间限制（毫秒），redis会记个log，而后返回error。当一个脚本超过了最大时限。只有SCRIPT KILL和SHUTDOWN NOSAVE能够用。第一个能够杀没有调write命令的东西。要是已经调用了write，只能用第二个命令杀。
lua-time-limit 5000

################################ REDIS CLUSTER ###############################
#集群开关，默认是不开启集群模式。
# cluster-enabled yes

#集群配置文件的名称，每一个节点都有一个集群相关的配置文件，持久化保存集群的信息。这个文件并不须要手动配置，这个配置文件有Redis生成并更新，每一个Redis集群节点须要一个单独的配置文件，请确保与实例运行的系统中配置文件名称不冲突
# cluster-config-file nodes-6379.conf

#节点互连超时的阀值。集群节点超时毫秒数
# cluster-node-timeout 15000

#在进行故障转移的时候，所有slave都会请求申请为master，可是有些slave可能与master断开链接一段时间了，致使数据过于陈旧，这样的slave不该该被提高为master。该参数就是用来判断slave节点与master断线的时间是否过长。判断方法是：
#比较slave断开链接的时间和(node-timeout * slave-validity-factor) + repl-ping-slave-period
#若是节点超时时间为三十秒, 而且slave-validity-factor为10,假设默认的repl-ping-slave-period是10秒，即若是超过310秒slave将不会尝试进行故障转移 
# cluster-slave-validity-factor 10

#master的slave数量大于该值，slave才能迁移到其余孤立master上，如这个参数若被设为2，那么只有当一个主节点拥有2 个可工做的从节点时，它的一个从节点会尝试迁移。
# cluster-migration-barrier 1

#默认状况下，集群所有的slot有节点负责，集群状态才为ok，才能提供服务。设置为no，能够在slot没有所有分配的时候提供服务。不建议打开该配置，这样会形成分区的时候，小分区的master一直在接受写请求，而形成很长时间数据不一致。
# cluster-require-full-coverage yes

################################## SLOW LOG ###################################
###slog log是用来记录redis运行中执行比较慢的命令耗时。当命令的执行超过了指定时间，就记录在slow log中，slog log保存在内存中，因此没有IO操做。
#执行时间比slowlog-log-slower-than大的请求记录到slowlog里面，单位是微秒，因此1000000就是1秒。注意，负数时间会禁用慢查询日志，而0则会强制记录全部命令。
slowlog-log-slower-than 10000

#慢查询日志长度。当一个新的命令被写进日志的时候，最老的那个记录会被删掉。这个长度没有限制。只要有足够的内存就行。你能够经过 SLOWLOG RESET 来释放内存。
slowlog-max-len 128

################################ LATENCY MONITOR ##############################
#延迟监控功能是用来监控redis中执行比较缓慢的一些操做，用LATENCY打印redis实例在跑命令时的耗时图表。只记录大于等于下边设置的值的操做。0的话，就是关闭监视。默认延迟监控功能是关闭的，若是你须要打开，也能够经过CONFIG SET命令动态设置。
latency-monitor-threshold 0

############################# EVENT NOTIFICATION ##############################
#键空间通知使得客户端能够经过订阅频道或模式，来接收那些以某种方式改动了 Redis 数据集的事件。由于开启键空间通知功能须要消耗一些 CPU ，因此在默认配置下，该功能处于关闭状态。
#notify-keyspace-events 的参数能够是如下字符的任意组合，它指定了服务器该发送哪些类型的通知：
##K 键空间通知，全部通知以 __keyspace@__ 为前缀
##E 键事件通知，全部通知以 __keyevent@__ 为前缀
##g DEL 、 EXPIRE 、 RENAME 等类型无关的通用命令的通知
##$ 字符串命令的通知
##l 列表命令的通知
##s 集合命令的通知
##h 哈希命令的通知
##z 有序集合命令的通知
##x 过时事件：每当有过时键被删除时发送
##e 驱逐(evict)事件：每当有键由于 maxmemory 政策而被删除时发送
##A 参数 g$lshzxe 的别名
#输入的参数中至少要有一个 K 或者 E，不然的话，无论其他的参数是什么，都不会有任何 通知被分发。详细使用能够参考http://redis.io/topics/notifications

notify-keyspace-events ""

############################### ADVANCED CONFIG ###############################
#数据量小于等于hash-max-ziplist-entries的用ziplist，大于hash-max-ziplist-entries用hash
hash-max-ziplist-entries 512
#value大小小于等于hash-max-ziplist-value的用ziplist，大于hash-max-ziplist-value用hash。
hash-max-ziplist-value 64

#数据量小于等于list-max-ziplist-entries用ziplist，大于list-max-ziplist-entries用list。
list-max-ziplist-entries 512
#value大小小于等于list-max-ziplist-value的用ziplist，大于list-max-ziplist-value用list。
list-max-ziplist-value 64

#数据量小于等于set-max-intset-entries用iniset，大于set-max-intset-entries用set。
set-max-intset-entries 512

#数据量小于等于zset-max-ziplist-entries用ziplist，大于zset-max-ziplist-entries用zset。
zset-max-ziplist-entries 128
#value大小小于等于zset-max-ziplist-value用ziplist，大于zset-max-ziplist-value用zset。
zset-max-ziplist-value 64

#value大小小于等于hll-sparse-max-bytes使用稀疏数据结构（sparse），大于hll-sparse-max-bytes使用稠密的数据结构（dense）。一个比16000大的value是几乎没用的，建议的value大概为3000。若是对CPU要求不高，对空间要求较高的，建议设置到10000左右。
hll-sparse-max-bytes 3000

#Redis将在每100毫秒时使用1毫秒的CPU时间来对redis的hash表进行从新hash，能够下降内存的使用。当你的使用场景中，有很是严格的实时性须要，不可以接受Redis时不时的对请求有2毫秒的延迟的话，把这项配置为no。若是没有这么严格的实时性要求，能够设置为yes，以便可以尽量快的释放内存。
activerehashing yes

##对客户端输出缓冲进行限制能够强迫那些不从服务器读取数据的客户端断开链接，用来强制关闭传输缓慢的客户端。
#对于normal client，第一个0表示取消hard limit，第二个0和第三个0表示取消soft limit，normal client默认取消限制，由于若是没有寻问，他们是不会接收数据的。
client-output-buffer-limit normal 0 0 0
#对于slave client和MONITER client，若是client-output-buffer一旦超过256mb，又或者超过64mb持续60秒，那么服务器就会当即断开客户端链接。
client-output-buffer-limit slave 256mb 64mb 60
#对于pubsub client，若是client-output-buffer一旦超过32mb，又或者超过8mb持续60秒，那么服务器就会当即断开客户端链接。
client-output-buffer-limit pubsub 32mb 8mb 60

#redis执行任务的频率为1s除以hz。
hz 10

#在aof重写的时候，若是打开了aof-rewrite-incremental-fsync开关，系统会每32MB执行一次fsync。这对于把文件写入磁盘是有帮助的，能够避免过大的延迟峰值。
aof-rewrite-incremental-fsync yes
复制代码

持久化

前文说过，redis是内存数据库，为了保证数据在断电后不会丢失，须要将它持久化到硬盘上。redis持久化分为两种。

RDB持久化

RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘。

也是默认的持久化方式，这种方式是就是将内存中数据以快照的方式写入到二进制文件中,默认的文件名为dump.rdb。

能够经过配置设置自动作快照持久化的方式。咱们能够配置redis在n秒内若是超过m个key被修改就自动作快照，下面是默认的快照保存配置

save 900 1 #900秒内若是超过1个key被修改，则发起快照保存
save 300 10 #300秒内容如超过10个key被修改，则发起快照保存
save 60 10000

RDB保存过程

redis调用fork，如今有了子进程和父进程
父进程继续处理client请求，子进程负责将内存内容写入到临时文件。因为os的写时复制机制（copy on write)父子进程会共享相同的物理页面，当父进程处理写请求时os会为父进程要修改的页面建立副本，而不是写共享的页面。因此子进程的地址空间内的数据是fork时刻整个数据库的一个快照。
当子进程将快照写入临时文件完毕后，用临时文件替换原来的快照文件，而后子进程退出。

如何触发快照

client 也可使用save或者bgsave命令通知redis作一次快照持久化。save操做是在主线程中保存快照的，因为redis是用一个主线程来处理全部 client的请求，这种方式会阻塞全部client请求。因此不推荐使用。

另外一点须要注意的是，每次快照持久化都是将内存数据完整写入到磁盘一次，并不是增量的只同步脏数据。若是数据量大的话，并且写操做比较多，必然会引发大量的磁盘io操做，可能会严重影响性能。

优点

一旦采用该方式，那么你的整个Redis数据库将只包含一个文件，这样很是方便进行备份。
方便备份，咱们能够很容易的将一个一个RDB文件移动到其余的存储介质上
RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。
RDB 能够最大化 Redis 的性能：父进程在保存 RDB 文件时惟一要作的就是 fork 出一个子进程，而后这个子进程就会处理接下来的全部保存工做，父进程无须执行任何磁盘 I/O 操做。

劣势

若是你须要尽可能避免在服务器故障时丢失数据，那么 RDB 不适合你。虽然 Redis 容许你设置不一样的保存点（save point）来控制保存 RDB 文件的频率，可是，由于RDB 文件须要保存整个数据集的状态，因此它并非一个轻松的操做。所以你可能会至少 5 分钟才保存一次 RDB 文件。在这种状况下， 一旦发生故障停机，你就可能会丢失好几分钟的数据。（丢失数据）
每次保存 RDB 的时候，Redis 都要 fork() 出一个子进程，并由子进程来进行实际的持久化工做。在数据集比较庞大时， fork() 可能会很是耗时，形成服务器在某某毫秒内中止处理客户端；若是数据集很是巨大，而且 CPU 时间很是紧张的话，那么这种中止时间甚至可能会长达整整一秒。虽然 AOF 重写也须要进行 fork() ，但不管 AOF 重写的执行间隔有多长，数据的耐久性都不会有任何损失。（耗时）

rdb总结

AOF持久化

AOF保存过程

redis会将每个收到的写命令都经过write函数追加到文件中(默认是 appendonly.aof)。

当redis重启时会经过从新执行文件中保存的写命令来在内存中重建整个数据库的内容。固然因为os会在内核中缓存 write作的修改，因此可能不是当即写到磁盘上。这样aof方式的持久化也仍是有可能会丢失部分修改。不过咱们能够经过配置文件告诉redis咱们想要经过fsync函数强制os写入到磁盘的时机。有三种方式以下（默认是：每秒fsync一次）

appendonly yes //启用aof持久化方式

appendfsync always //每次收到写命令就当即强制写入磁盘，最慢的，可是保证彻底的持久化，不推荐使用

appendfsync everysec //每秒钟强制写入磁盘一次，在性能和持久化方面作了很好的折中，推荐

appendfsync no //彻底依赖os，性能最好,持久化没保证

aof 的方式也同时带来了另外一个问题。持久化文件会变的愈来愈大。例如咱们调用incr test命令100次，文件中必须保存所有的100条命令，其实有99条都是多余的。由于要恢复数据库的状态其实文件中保存一条set test 100就够了。

为了压缩aof的持久化文件。redis提供了bgrewriteaof命令。收到此命令redis将使用与快照相似的方式将内存中的数据以命令的方式保存到临时文件中，最后替换原来的文件。具体过程以下

redis调用fork，如今有父子两个进程子进程根据内存中的数据库快照，往临时文件中写入重建数据库状态的命令父进程继续处理client请求，除了把写命令写入到原来的aof文件中。同时把收到的写命令缓存起来。这样就能保证若是子进程重写失败的话并不会出问题。当子进程把快照内容写入已命令方式写到临时文件中后，子进程发信号通知父进程。而后父进程把缓存的写命令也写入到临时文件。如今父进程可使用临时文件替换老的aof文件，并重命名，后面收到的写命令也开始往新的aof文件中追加。须要注意到是重写aof文件的操做，并无读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件,这点和快照有点相似。

优点

耐久
不断电
易读

劣势

数据量大
慢

抉择

通常来讲，应该同时使用两种持久化功能。若是你很是关心你的数据，但仍然能够承受数分钟之内的数据丢失，那么你能够只使用 RDB 持久化。

redis事务

是什么

能够一次执行多个命令，本质是一组命令的集合。一个事务中的，全部命令都会序列化，按顺序地串行化执行而不会被其它命令插入，不准加塞

能干吗

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

3个阶段

开启：以MULTI开始一个事务
入队：将多个命令入队到事务中，接到这些命令并不会当即执行，而是放到等待执行的事务队列里面
执行：由EXEC命令触发事务

3特性

单独的隔离操做：事务中的全部命令都会序列化、按顺序地执行。事务在执行的过程当中，不会被其余客户端发送来的命令请求所打断。
没有隔离级别的概念：队列中的命令没有提交以前都不会实际的被执行，由于事务提交前任何指令都不会被实际执行，
也就不存在”事务内的查询要看到事务里的更新，在事务外查询不能看到”这个让人万分头痛的问题
不保证原子性：redis同一个事务中若是有一条命令执行失败，其后的命令仍然会被执行，没有回滚

关于redis事务

首先，让咱们来看一个例子：

这个操做采用了事务模式，并在第6个指令 进入队列的时候就已经出错，因此致使整个事务的命令都不会被执行

接下来，再看一个操做

实际上这个问题很简单，这个incr name错误指令在入队的时候没有出错，却在执行的时候出错了，redis默认跳过这个命令执行后续命令

因此，这就是为何我在开头说redis的事务只是部分事务

redis的锁机制

redis的锁CAS相似于乐观锁，使用方式为用watch关键字监视一个(或多个)数据，例如：

假设如今两个客户端A，B

1.客户端A监控count，并修改count

2.待A执行完毕后，客户端B修改count

3.待B执行完毕后，A提交事务

能够看到，显示了(nil)，即此次事务失败，count变为50

事务总结

单独的隔离操做：事务中的全部命令会被序列化、按顺序执行，在执行的过程当中不会被其余客户端发送来的命令打断
没有隔离级别的概念：队列中的命令在事务没有被提交以前不会被实际执行
不保证原子性：redis中的一个事务中若是存在命令执行失败，那么其余命令依然会被执行，没有回滚机制

消息发布订阅

Redis提供了发布订阅功能，可用于消息传输，进程间的一种通讯方式，Redis的发布订阅机制包括三个部分，发布者，订阅者和Channel。

发布者和订阅者都是Redis客户端，Channel则为Redis服务器端，发布者将消息发送到某个的频道，订阅了这个频道的订阅者就能接收到这条消息。

固然，通常不多人用redis的发布订阅，取而代之的是消息队列MQ(ActiveMQ)，但仍是有必要了解redis有该功能的。

主从复制

为何有它

读写分离：和关系型数据库同样，虽然redis做为内存数据库，他一样面临读写压力，经过设置主从redis能够实现读写分离减轻压力
容灾恢复：假设某位程序员不当心把库房烧了😭，主库没了，若是咱们设计了从库，这时咱们将彻底不用担忧数据没了的问题，由于从库和主库有一样的数据

是什么

行话：也就是咱们所说的主从复制，主机数据更新后根据配置和策略，自动同步到备机的master/slaver机制，Master以写为主，Slave以读为主，一个从服务器只能有一个主服务器，而且不支持主主复制。

复制原理

全量同步

Redis全量复制通常发生在Slave初始化阶段，这时Slave须要将Master上的全部数据都复制一份。具体步骤以下：

1.从服务器链接主服务器，发送SYNC命令；

2.主服务器接收到SYNC命名后，开始执行BGSAVE命令生成RDB文件并使用缓冲区记录此后执行的全部写命令；

3.主服务器BGSAVE执行完后，向全部从服务器发送快照文件，并在发送期间继续记录被执行的写命令；

4.从服务器收到快照文件后丢弃全部旧数据，载入收到的快照；

5.主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令；

6.从服务器完成对快照的载入，开始接收命令请求，并执行来自主服务器缓冲区的写命令；

增量同步

Redis增量复制是指Slave初始化后开始正常工做时主服务器发生的写操做同步到从服务器的过程。增量复制的过程主要是主服务器每执行一个写命令就会向从服务器发送相同的写命令，从服务器接收并执行收到的写命令。

如今，出现了几个问题：

从机是否能够写？
若是从库死了以后活了他仍是从库吗？
若是主库死了以后它的从库该怎么办？(普通模式和哨兵模式)主库活了以后仍是主库吗？

为了减小阅读量，这里就不实验论证了，客官们能够自行尝试

先回答第一个问题：

从机不可写

先回答第二个问题：

在Redis2.8版本以前，从库死后复活会发送sync请求和主机全量同步，因此死后复活仍是从库，可是，当多个从库同时复活的话会致使主机IO剧增而宕机

2.8版本以后，主服务器只须要将断线期间执行的命令发给从服务器便可

第三个问题：

主机死后，从机待命。而且主库回来后，他将仍然是主库

哨兵模式：反客为主，即哨兵模式在后台监控，主库死后根据投票将它的从库设置为新的主库

哨兵模式的出现正是为了解决主库死后无人领导的状态。

那么有了哨兵模式后，原来死掉的主库回来后会发生什么呢？答案是原来的主库回来后就变为了从库。

最后一点点

对于一个slave从库他一样能够接收其余从库的链接请求，即该slave做为下一个的master

Redis适用场景

数据高并发读写
海量数据读写
扩展性要求高的数据

例子：

1.保存热点信息 2.排行榜 3.计数 4.单点登录(解决session共享问题) 5.等等。。。