这里主要记录了Redis的一些功能以及运维的简答理解。由于是初学，所以知识难免不完全。详情可以点击查看。
###慢查询
生命周期：
客户端发送命令给Redis，然后依次执行命令。最后将结果传输给客户端。慢查询发生在执行命令阶段，要注意的就是，客户端超时不一定是慢查询的原因，但是慢查询是客户端超时一个可能因素。
慢查询的命令：
1.slowlog get[n] 获取慢查询的队列信息
2.slowlog len 获取慢查询队列的长度
3.slowlog rest 清空慢查询的队列###pipeline 流水线
什么是流水线呢：将云游的一次传输命令和一次计算变为网络一次性传输多条命令再分次计算。就好像搬砖一样，你每次搬一块砖来来回回，费时费力。不如一次性搬10快。节省了来回的时间消耗。同样的流水线机制也节省了传输的时间。
但是要注意：每次pipeline携带的数据量要控制，否则过多会压迫网络的传输能力（为啥是网络呢，因为实际开发中不可能主机和数据库放在一起）同时一次性传输数据量过大，也会造成查询的时延。并且每次只能作用在一个Redis的节点上。
###发布订阅
角色：发布者 订阅者通过不同的频道接收信息。 但问题是就好像领导在开会，由于你进来晚了。所以之前的消息就不能接收到了。同样的，你可以收听多个频道。穿梭在各大会场。
命令：
publish 发布命令 public channel message
subscribe 订阅 shubscribe [channel] 频道可以有多个
unsubscribe 取关 同上 （意思就是我不听了我走了）
其他不做介绍了相对于消息队列，就是作为“抢”的功能，这个是谁都可以收到。
###Bitmap 位图
在某些场景下存储是有好处的 相对来说节省空间。但对于某些操作例如setbit的偏移量可能比较耗时。
命令：
setbit： setbit key offset value 给位图指定索引值
getbit： getbit key offset 获得
bitcount： bitcount key [start end] 获取指定范围的值为1的个数
bitop： bitmap opdestkey key··· 做多个bitmap的and，or，not操作并将结果保存在destkey中###HyperLoglog
一种数据结构，用极小的空间完成独立数量的统计，实质上就是字符串
命令：
pfadd： pfadd key element··· 向其中添加元素
pfcount： pfcount key··· 计算其中独立总数
pfmerga：pfmerga destkey sourcekey··· 合并多个hyperloglog要注意的就是，计实hyperloglog很好用且占用空间小，但是他有一定的错误率。
###GEO
用于存储经纬度，计算两地之间的距离
应用也广泛，例如查询一定范围的酒店帮助推送之类。
命令：
geoadd：geoadd key longitude latitude member 增加地理位置信息
geopos：geopos key member··· 获取地理位置信息
geodist：geodist member1 member2 用于计算两地的距离
其余的不做介绍 ##Redis持久化的取舍和选择
什么是持久化呢：Redis所有数据保存在内存中，对数据的更新将异步地保存到磁盘上。这样呢可以在关闭Redis的时候仍存储对于数据。
持久化的操作：
快照：Redis的RDB功能，类比于MySQL就是Dumpgongn
写日志：Redis的AOF功能，类比于MySQL就是BinLog###什么是RDB
①.Redis创建对应的RDB文件（二进制）格式，把偶才能在硬盘上。（以快照的形式保存）
②.当你需要的时候呢，重启RDB，Redis就从硬盘上启动载入相对于的二进制文件到内存。
命令介绍：
save命令：
Client->（save）启动①，成功就返回OK，但是相对应的当数据特别大时，因为Redis时单线程操作所有有可能会产生阻塞。
同时要注意就是RDB模式下存储为整体存储，就是一次性的替换和存储进入磁盘。不会说只更新操作的部分。
bgsave命令：
Client->（bgsave）Redis。【redis会在后台执行fork操作，因此不会阻塞Redis的操作】使用的是子进程。自动生成RDB，就是在一定时间内，数据量达到了要求目标就会自动生成文件。其触发的方式为1.全量复制，如果在主从复制的情况下自动生成。2.不清空重启机制。
同时RDB存在一些问题：例如保存的耗时性以及阻塞的消耗性能。并且呢操作时不可控的。当宕机的时候会造成数据的丢失。
###什么时AOF
AOF运行的原理：在客户端执行一条命令，在就日志中记录一条。所以呢如果在Redis宕机后，因为AOF的这种功能，所有的信息基本都会恢复。
命令介绍：
alway：
Redis->写命令到缓冲区->每条命令fsync到硬盘上->生成AOF文件。（注意这样的坏处时IO开销比较大）
everysec：
Redis->写命令到缓冲区->每条命令fsync到硬盘上->生成AOF文件。(有可能在宕机的那一秒数据丢失)
no：
操作系统自己决定是否刷新更新操作。（不可控）随着时间的变化，AOF文件也会越来越大，并且在恢复的时候也会越来越长。因此有了重写的功能。例如在更新数据的时候只存储最后的一部分。亦或者是过期的数据不进行存储来保证数据不会过大。
建议：
关闭RDB，但是在执行第一次主从复制的时候肯定要用到RDB。
建议开启AOF，用缓冲和存储。并且选用每秒刷盘方式存储数据。##运维的常见操作
fork操作
1.同步操作（主要是对内存的一些简要操作）
2.与内存信息量有关:内存越大，耗时越长，当然也与你选择的机器模型有关改善操作：
1.优化使用物理机或者高效支持fork操作的虚拟化技术
2.控制Redis实例最大化的内存：maxmemory
3.合理配置Linux内存分配策略，如：vm.overcommit_memory = 1
4.降低fork频率：例如放宽AOF重写主动出发机制，或者不必要的全量复制子进程开销和和优化
1.CPU
开销：RDB和AOF文件生成，都属于CPU密集型操作
优化：不做任何CPU绑定，不和CPU密集型部署
2.内存
开销：fork内存的开销，copy_on_write
优化：不允许单击多部署时的大量重写
3.硬盘
开销：AOF和RDB文件写入，可以结合iostart，iotop分析
优化：
1.不要和高硬盘负载部署到一起：存储服务器，消息队列等
2.根据写入量决定磁盘的类型：ssd之类
3.单机多实例持久文件目录操作可以考虑分盘AOF追加阻塞
##Redis的复制原理以及优化
主从复制的作业：达到备份的效果，当主机宕机后可以提供类似的资源，且支持一主多从。
一主多从呢可以实现读写分离以及高可用的实现。
命令实现：
slaveof再写入目的主机端口，当返回OK就成功除了命令，还有启动之前的配置操作。这里不做介绍
全量复制和部分复制
全量复制的开销:
1.bgsave时间：fork操作，生成一个子进程，因此对CPU和硬盘都有一定的开销
2.RDB文件因为时网络传输，因此要占用传输时延
3.从节点清空数据的时间
4.从节点加载RDB的时间
5.可能的AOF重写时间存在的问题：
1.读写分离：读流量分摊到从节点上
问题：复制数据的延迟，以及可能读到过期数据，或者从节点故障
2.配置的不一致
内存配置不一致导致的数据丢失，
3.规避全量复制
要注意就是第一次的全量复制不可避免
节点运用后ID不匹配，主节点重启后run_id的改变，或者故障你的转移
复制积压缓冲区不足，网络中断或者部分复制无法满足
4.复制风暴
1.节点对应多的重节点，主节点重启后，多个从节点复制的CPU和网络消耗过大。
2.单机挂在多个master节点时候造成的积压。后果可想而知。
