redis关注点：
1、redis命令：Redis 命令参考 — Redis 命令参考
字符串：SET key value [EX seconds] [PX milliseconds] [NX|XX]
hash表：HSET hash field value
列表：LPUSH key value [value …]
集合：SADD key member [member …]
有序集合：ZADD key score member [[score member] [score member] …]
集合有交集、并集、差集等操作，注意有序集合是有score的，区别下无序集合。
结合整体用法可以实现购物车、抢红包、点赞、投票等功能。
2、存储机制：
从 redis 的官网查阅了相关资料，在 3.2 版本以后，redis 提供了 quicklist 内部编码，它结合了 ziplist 和 linkedlist 两者的优势，之前的 ziplist 是存在 BUG的，使用 quicklist 内部编码效率更高，所以我们现在 3.2 以后看不到这两个编码，只看到quicklist, 英语好的同学可以看一下https://matt.sh/redis-quicklist国外的这篇博客有重点提到
3、 持久化机制：ADB 和AOF
4、lua脚本(需要安装，很小，http://www.lua.org/ftp/lua-5.3.5.tar.gz )
减少网络开销，在Lua脚本中可以把多个命令放在同一个脚本中运行
原子操作，redis会将整个脚本作为一个整体执行，中间不会被其他命令插入。换句话说，编写脚本的过程中无需担心会出现竞态条件
复用性，客户端发送的脚本会永远存储在redis中，这意味着其他客户端可以复用这一脚本来完成同样的逻辑
运行lua: eval "return redis.call('get',KEYS[1])" 1 name //eval+脚本+KEYS[1]+键个数+键
/redis-cli -h 192.168.42.111 -a 12345678 script load "$(cat xxxx.lua)" //将LUA脚本内容加载到redis， 得到 返回的sha1值： xxxxxx
evalsha xxxxxxcount param...
5、关注redis慢查询
设置时间：slowlog-log-slower-than
获取超时查询：slowlog get
6、redis性能测试 --redis-benchmark
Redis 服务器与客户端通过 RESP（REdis Serialization Protocol）协议通信。底层采用tcp方式，如serverSocket。
A、redis-benchmark -h 192.168.42.111 -p 6379 -c 100 -n 10000
//100 个并发连接，10000 个请求，检测服务器性能B、redis-benchmark -h
B、192.168.42.111 -p 6379 -q -d 100
//测试存取大小为 100 字节的数据包的性能
C、redis-benchmark -h 192.168.42.111 -p 6379 -t set,get -n 100000 -q
//只测试 set,lpush 操作的性能
D 、 redis-benchmark -h 192.168.42.111 -p 6379 -n 100000 -q script load
"redis.call('set','foo','bar')"
//只测试某些数值存取的性能
7、管道PIPE
将多个指令打包后,一次性提交到 Redis, 网络通信只有一次
mysql -utest -ptest stress --default-character-set=utf8 --skip-column-names --raw < order.sql |
redis-cli -h 192.168.42.111 -p 6379 -a 12345678 --pipe
8、弱事务
multi 为开始，exec为结束，discard为终止事务
有些情况下不能回滚，例如类型错误时候。
watch让事务失效
9、发布、订阅
subscrible channel:test//订阅消息
publish channel:test "hello world" //发布消息
pubsub numsub channel:test // 频道 channel:test 的订阅数
unsubscribe channel:test //取消订阅
psubscribe ch* //订阅以 ch 开头的所有频道
punsubscribe ch* //取消以 ch 开头的所有频道
10、键的迁移：把部分数据迁移到另一台 redis 服务器
1, move key db //reids 有 16 个库， 编号为 0－15
2, dump key;restore key ttl value//实现不同 redis 实例的键迁移，ttl=0 代表没有过期时间
3,migrate 用于在 Redis 实例间进行数据迁移，实际上 migrate 命令是将 dump、
restore、del 三个命令进行组合，从而简化了操作流程。
migrate 命令具有原子性，从 Redis 3.0.6 版本后已经支持迁移多个键的功能。
migrate 命令的数据传输直接在源 Redis 和目标 Redis 上完成，目标 Redis 完成
restore 后会发送 OK 给源 Redis。
11、键的遍历
1，键全量遍历：
mset country china city bj name lilei //设置 3 个字符串键值对
keys * //返回所有的键, *匹配任意字符多个字符
keys *y //以结尾的键，
keys n*e //以 n 开头以 e 结尾，返回 name
keys n?me // ?问号代表只匹配一个字符 返回 name,全局匹配
keys n?m* //返回 name
keys [l,n]* //返回以 l n 开头的所有键
keys [l]ilei 全量匹配 lilei
2，渐进式遍历
遍历匹配:匹配以 n 开头的键，最大是取 5 条，第一次 scan 0 开始
scan 0 match n* count 5
第二次从游标 4096 开始取 20 个以 n 开头的键，相当于一页一页的取当最后
返回 0 时，键被取完,但 count 不准,一般用来代替 keys *操作，可避免阻塞
12、高可用
一、主从方式
1.）主从复制
a,方式一、新增 redis6380.conf, 加入 slaveof 192.168.42.111 6379, 在 6379 启动完
后再启 6380，完成配置；
b,方式二、redis-server --slaveof 192.168.42.111 6379
c,查看状态：info replication
d,断开主从复制：在 slave 节点，执行 6380:>slaveof no one
e,断开后再变成主从复制：6380:> slaveof 192.168.42.111 6379
f,数据较重要的节点，主从复制时使用密码验证： requirepass
e,从节点建议用只读模式 slave-read-only=yes, 若从节点修改数据，主从数据不一致
h,传输延迟：主从一般部署在不同机器上，复制时存在网络延时问题，redis 提供repl-disable-tcp-nodelay 参数决定是否关闭 TCP_NODELAY,默认为关闭参数关闭时：无论大小都会及时发布到从节点，占带宽，适用于主从网络好的场景，参数启用时：主节点合并所有数据成 TCP 包节省带宽，默认为 40 毫秒发一次，取决于内核，主从的同步延迟 40 毫秒，适用于网络环境复杂或带宽紧张，如跨机房
2）主从拓扑：支持单层或多层
二、 哨兵机制
A，原理：当主节点出现故障时，由 redis sentinel 自动完成故障发现和转移，并
通知应用方，实现高可用性。
主从复制与 redis sentinel 拓扑结构图
其实整个过程只需要一个哨兵节点来完成，首先使用 Raft 算法（感兴趣的同学可以查一下，其实就是个选举算法）实现选举机制，选出一个哨兵节点来完成转移和通知哨兵有三个定时监控任务完成对各节点的发现和监控：
任务 1，每个哨兵节点每 10 秒会向主节点和从节点发送 info 命令获取最拓扑结构图，哨兵配置时只要配置对主节点的监控即可，通过向主节点发送 info，获取从节点的信息，并当有新的从节点加入时可以马上感知到
任务 2，每个哨兵节点每隔 2 秒会向 redis 数据节点的指定频道上发送该哨兵节点对于主节点的判断以及当前哨兵节点的信息，同时每个哨兵节点也会订阅该频道，来了解其它哨兵节点的信息及对主节点的判断，其实就是通过消息 publish 和 subscribe 来完成的；
任务 3，每隔 1 秒每个哨兵会向主节点、从节点及其余哨兵节点发送一次 ping 命令做一次心跳检测，这个也是哨兵用来判断节点是否正常的重要依据
主观下线：刚我知道知道哨兵节点每隔 1 秒对主节点和从节点、其它哨兵节点发送 ping 做心跳检测，当这些心跳检测时间超过 down-after-milliseconds 时，哨兵节点则认为该节点错误或下线，这叫主观下线；这可能会存在错误的判断。
客观下线：当主观下线的节点是主节点时，此时该哨兵 3 节点会通过指令 sentinel is-masterdown-by-addr 寻求其它哨兵节点对主节点的判断，当超过 quorum（法定人数）个数，此时哨兵节点则认为该主节点确实有问题，这样就客观下线了，大部分哨兵节点都同意下线操作，也就说是客观下线。
三、集群
RedisCluster 是 redis 的分布式解决方案，在 3.0 版本后推出的方案，有效地解决了Redis 分布式的需求，当遇到单机内存、并发等瓶颈时，可使用此方案来解决这些问题。
节点之间采用 Gossip 协议进行通信，Gossip 协议就是指节点彼此之间不断通信交换信息
虚拟槽分区了解下
