一、redis基础与入门实践
1、Redis介绍
Redis是一种高级key-value数据库。它跟memcached类似，不过数据可以持久化，而且支持的数据类型很丰富。有字符串，链表、哈希、集合和有序集合5种。支持在服务器端计算集合的并、交和补集(difference)等，还支持多种排序功能。所以Redis也可以被看成是一个数据结构服务器。Redis的所有数据都是保存在内存中，然后不定期的通过异步方式保存到磁盘上(这称为“半持久化模式”)；也可以把每一次数据变化都写入到一个append only file(aof)里面(这称为“全持久化模式”)。
2、安装redis
$ wget http://download.redis.io/releases/redis-5.0.3.tar.gz$ cd redis-5.0.3$ make$make install$cp redis.conf /etc/参数介绍：
make install命令执行完成后，会在redis-5.0.3/src目录下生成本个可执行文件，分别是redis-server、redis-cli、redis-benchmark、redis-check-aof 、redis-check-dump，它们的作用如下：
redis-server：Redis服务器的daemon启动程序
redis-cli：Redis命令行操作工具。也可以用telnet根据其纯文本协议来操作
redis-benchmark：Redis性能测试工具，测试Redis在当前系统下的读写性能
redis-check-aof：数据修复
redis-check-dump：检查导出工具
3、修改系统配置文件，执行命令
a) echo vm.overcommit_memory=1 >> /etc/sysctl.confb) sysctl vm.overcommit_memory=1 或执行echo vm.overcommit_memory=1 >>/proc/sys/vm/overcommit_memory使用数字含义：
0，表示内核将检查是否有足够的可用内存供应用进程使用；如果有足够的可用内存，内存申请允许；否则，内存申请失败，并把错误返回给应用进程。
1，表示内核允许分配所有的物理内存，而不管当前的内存状态如何。
2，表示内核允许分配超过所有物理内存和交换空间总和的内存
二、redis参数调优与维护管理
1、redis配置文件讲解
Redis配置文件上面我们拷贝到了/etc/redis.conf路径下，其实可以是任意路径。redis.conf文件参数介绍：
bind 127.0.0.1bind指定redis只接收来自IP对应网卡的请求，如果不进行设置，那么将处理所有请求。bind绑定的是本机的IP地址，准确的说是本机的网卡对应的IP地址，每一个网卡都有一个IP地址，可以设置绑定到哪块网卡上，如果指定了bind，则说明只允许来自指定网卡的Redis请求。如果没有指定，就说明可以接受来自任意一个网卡的Redis请求。
注意，此参数不是设置redis允许来自其他计算机请求的客户端IP地址。
protected-mode yes此参数是redis3.2版本之后加入的新特性，默认是yes，即开启，这是为了禁止公网直接访问redis新增的设定，用于加强redis安全的。protected-mode在启用状态，redis无法提供对外连接。
要启用redis对外连接功能，有如下两种方法：
1)关闭protected-mode模式
2) 设置访问密码或配置bind IP
tcp-backlog 511此参数确定了TCP连接中已完成队列(完成三次握手之后)的长度， 默认是511，当然此值不能大于Linux系统定义的/proc/sys/net/core/somaxconn值，而Linux的默认参数值是128。当系统并发量大并且客户端速度缓慢的时候，可以将这二个参数一起设定为一个一样的值。对于负载很大的服务程序来说，默认128太少。一般会将它修改为2048或者更大。在/etc/sysctl.conf中添加:net.core.somaxconn = 2048，然后在终端中执行sysctl -p。
daemonize yes：是否以后台daemon方式运行。
pidfile /var/run/redis.pid： 当Redis以守护进程方式运行时，Redis默认会把pid写入/var/run/redis.pid文件，可以通过pidfile指定。
port 6379：指定Redis监听端口，默认端口为6379。
timeout 300：当客户端闲置多长时间后关闭连接，如果指定为0，表示服务端不会主动断开连接。
loglevel verbose：指定日志记录级别，Redis总共支持四个级别：debug、verbose、notice、warning，默认为verbose。
Logfile ：日志记录方式，默认为标准输出，可指定一个文件，将日志输出到这里。
databases 16：设置开启数据库的数量，默认数据库为0。
# 下面的例子的意思是：
# 900 秒内如果至少有 1 个 key 的值变化，则保存
# 300 秒内如果至少有 10 个 key 的值变化，则保存
# 60 秒内如果至少有 10000 个 key 的值变化，则保存
# 注意：也可以注释掉所有的 save 行来停用保存功能。save表示在一定时间内执行一定数量的写操作时，自动保存快照。可设置多个条件。
save 900 1save 300 10save 60 10000rdbcompression yes：指定存储至本地数据库时是否压缩数据，默认为yes，Redis采用LZF压缩，如果为了节省CPU时间，可以关闭该选项，但会导致数据库文件变的巨大
dbfilename dump.rdb：数据快照文件名(只是文件名，不包括目录)
dir ./ 数据快照的保存目录(这个是目录)
slaveof 192.168.1.100 6379 设置当本机为slave服务时，设置master服务的IP地址及端口，在Redis启动时，它会自动从master进行数据同步
appendonly no：是否开启appendonlylog，开启的话每次写操作会记一条log，这会提高数据抗风险能力，但影响效率。Redis在默认情况下是异步的把数据写入磁盘，如果不开启，可能会在断电时导致一段时间内的数据丢失。因为 redis本身同步数据文件是按上面save条件来同步的，所以有的数据会在一段时间内只存在于内存中。默认为no。
appendfilename appendonly.aof： 指定更新日志文件名，默认为appendonly.aof
appendfsync everysec： 指定更新日志条件，共有3个可选值：
no：表示等操作系统进行数据缓存同步到磁盘(快)
always：表示每次更新操作后手动调用fsync()将数据写到磁盘(慢，安全)
everysec：表示每秒同步一次(折衷，默认值)
maxmemory 8G：指定Redis最大内存限制，Redis在启动时会把数据加载到内存中，达到最大内存后，Redis会先尝试清除已到期或即将到期的Key，当此方法处理后，仍然到达最大内存设置，将无法再进行写入操作，但仍然可以进行读取操作。Redis新的vm机制，会把Key存放内存，Value会存放在swap区。
maxclients 128：设置同一时间最大客户端连接数，默认无限制，Redis可以同时打开的客户端连接数为Redis进程可以打开的最大文件描述符数，如果设置 maxclients 0，表示不作限制。当客户端连接数到达限制时，Redis会关闭新的连接并向客户端返回max number of clients reached错误信息。
2、启动redis
a) $ cd /usr/local/bin
b) ./redis-server /etc/redis.conf
检查是否启动成功
a) $ ps -ef | grep redis3、Redis监控
首先判断客户端和服务器连接是否正常
# 客户端和服务器连接正常，返回PONG
redis> PINGPONG# 客户端和服务器连接不正常(网络不正常或服务器未能正常运行)，返回连接异常
redis 127.0.0.1:6379> PINGCould not connect to Redis at 127.0.0.1:6379: Connection refusedRedis 监控最直接的方法就是使用系统提供的 info 命令，只需要执行下面一条命令，就能获得 Redis 系统的状态报告。
redis-cli info结果会返回 Server、Clients、Memory、Persistence、Stats、Replication、CPU、Keyspace 8个部分。从info大返回结果中提取相关信息，就可以达到有效监控的目的。
先解释下各个参数含义：
# Serverredis_version:2.8.8 # Redis 的版本redis_git_sha1:00000000redis_git_dirty:0redis_build_id:bf5d1747be5380fredis_mode:standaloneos:Linux 2.6.32-220.7.1.el6.x86_64 x86_64arch_bits:64multiplexing_api:epollgcc_version:4.4.7 #gcc版本process_id:49324 # 当前 Redis 服务器进程idrun_id:bbd7b17efcf108fdde285d8987e50392f6a38f48tcp_port:6379uptime_in_seconds:1739082 # 运行时间(秒)uptime_in_days:20 # 运行时间(天)hz:10lru_clock:1734729config_file:/home/s/apps/RedisMulti_video_so/conf/zzz.conf# Clientsconnected_clients:1 #连接的客户端数量client_longest_output_list:0client_biggest_input_buf:0blocked_clients:0# Memoryused_memory:821848 #Redis分配的内存总量 used_memory_human:802.59Kused_memory_rss:85532672 #Redis分配的内存总量(包括内存碎片)used_memory_peak:178987632used_memory_peak_human:170.70M #Redis所用内存的高峰值used_memory_lua:33792mem_fragmentation_ratio:104.07 #内存碎片比率mem_allocator:tcmalloc-2.0# Persistenceloading:0rdb_changes_since_last_save:0 #上次保存数据库之后，执行命令的次数rdb_bgsave_in_progress:0 #后台进行中的 save 操作的数量rdb_last_save_time:1410848505 #最后一次成功保存的时间点，以 UNIX 时间戳格式显示rdb_last_bgsave_status:okrdb_last_bgsave_time_sec:0rdb_current_bgsave_time_sec:-1aof_enabled:0 #redis是否开启了aofaof_rewrite_in_progress:0aof_rewrite_scheduled:0aof_last_rewrite_time_sec:-1aof_current_rewrite_time_sec:-1aof_last_bgrewrite_status:okaof_last_write_status:ok# Statstotal_connections_received:5705 #运行以来连接过的客户端的总数量total_commands_processed:204013 # 运行以来执行过的命令的总数量instantaneous_ops_per_sec:0rejected_connections:0sync_full:0sync_partial_ok:0sync_partial_err:0expired_keys:34401 #运行以来过期的 key 的数量evicted_keys:0 #运行以来删除过的key的数量keyspace_hits:2129 #命中key 的次数keyspace_misses:3148 #没命中key 的次数pubsub_channels:0 #当前使用中的频道数量pubsub_patterns:0 #当前使用中的模式数量latest_fork_usec:4391# Replicationrole:master #当前实例的角色master还是slaveconnected_slaves:0master_repl_offset:0repl_backlog_active:0repl_backlog_size:1048576repl_backlog_first_byte_offset:0repl_backlog_histlen:0# CPUused_cpu_sys:1551.61used_cpu_user:1083.37used_cpu_sys_children:2.52used_cpu_user_children:16.79# Keyspacedb0:keys=3,expires=0,avg_ttl=0 #各个数据库的 key 的数量，以及带有生存期的 key 的数量对redis内存使用监控
如果 Redis 使用的内存超出了可用的物理内存大小，那么 Redis 很可能系统会被杀掉。针对这一点，可以通过 info 命令对 used_memory 和 used_memory_peak 进行监控，为使用内存量设定阀值，并设定相应的报警机制。当然，报警只是手段，重要的是你得预先计划好，当内存使用量过大后，应该做些什么，是清除一些没用的冷数据，还是把 Redis 迁移到更强大的机器上去。
redis持久化数据的问题
如果因为你的机器或 Redis 本身的问题导致 Redis 崩溃了，那么你唯一的救命稻草可能就是 dump 出来的rdb文件了，所以，对 Redis dump 文件进行监控也是很重要的。可以通过对rdb_last_save_time 进行监控，了解最近一次 dump 数据操作的时间，还可以通过对rdb_changes_since_last_save进行监控来获得如果这时候出现故障，会丢失(即已改变)多少数据。
