1. 前言
1.1 Reis是什么
Redis 是 C 语言开发的一个开源的（遵从 BSD 协议）高性能键值对（key-value）的 NoSQL的内存数据库，可以用作缓存、消息中间件等；具有以下特点：
1. 性能优秀，数据在内存中，读写速度非常快，支持并发 10W QPS；
2. 单进程单线程，是线程安全的，采用 IO 多路复用机制；
3. 丰富的数据类型，支持字符串（strings）、散列（hashes）、列表（lists）、集合（sets）、有序集合（sorted sets）等；
4. 支持数据持久化。可以将内存中数据保存在磁盘中，重启时加载；
5. 主从复制，哨兵，高可用；
可以用作分布式锁。可以作为消息中间件使用，支持发布订阅；
1.2 Redis支持的功能
1. 缓存： 提升数据的访问性能
2. 可用作低配版的消息中间件，支持发布订阅
3. 可用做分布式锁
4. 可以实现session共享
1.3 与memoryCache对比
| 对比内容 |
Redis |
memoryCache |
| 存储方式 | Redis 支持持久化 | Memcache不支持持久化，会把数据全部存在内存，很难解决缓存雪崩的问题 |
| 数据类型 | Redis 支持五种数据类型 | Memcache 对数据类型的支持简单，只支持简单的 key-value |
| 底层模型 |
Redis 直接自己构建了 VM 机制 因为一般的系统调用系统函数的话 会浪费一定的时间去移动和请求 |
调用系统 |
| Value大小 | Redis 可以达到 1GB | Memcache 只有 1MB |
2. Redis内存管理
2.1 redisObject
Redis对象的类型、内部编码、内存回收、共享对象等功能，都需要redisObject支持
这样设计的好处：可以针对不同场景，对5种常用的数据类型设置多种不同的数据结构实现，从而优化对象在不同场景下的使用效率；
type: 代表一个 value 对象具体是何种数据类型。
encoding: 不同数据类型在 redis 内部的存储方式。
比如：type=string 代表 value 存储的是一个普通字符串，那么对应的 encoding 可以是 raw 或者是 int。
如果是 int 则代表实际 redis 内部是按数值型类存储和表示这个字符串的。
当然前提是这个字符串本身可以用数值表示，比如："123" "456"这样的字符串。
vm字段: 只有打开了 Redis 的虚拟内存功能，此字段才会真正的分配内存，该功能默认是关闭状态的。
Redis 使用 redisObject 来表示所有的 key/value 数据是比较浪费内存的
当然这些内存管理成本的付出主要也是为了给 Redis 不同数据类型提供一个统一的管理接口，实际作者也提供了多种方法帮助我们尽量节省内存使用。
2.2 基础命令
服务端启动：redis-server redis.config
客户端启动： redis-cli -p [服务器端口] -h [服务端ip]
1. 查看所有的key：keys *
2. 设置过期时间：set username nick EX 10 // ttl username 查看key剩余时间
3. 选择库：select 1 // redis有16个库0~15，可以选择不同的库存储数据，redis集群默认用0号库
4. 判断key是否存在：exits username
5. 删除key：del username
6. 查看key类型： type username
7. 数据持久化： save //保存在dump.rdb文件
8. 清空redis所有数据：flushall //flushdb为清空分库的数据，不删除dump.rdb
9. 单节点批量操作：mset/mget //mset username nick mset address dg
10. 冷点数据设置超时清除：expire username 100 // expire为秒维度，pexpire为毫秒维度
11. 追加数据：如果 key 已经存在并且是一个字符串，append key value
2.3 五种数据类型
2.3.1 String
String类型的数据结构，是key-value形式，value为字符串/json串
1. 增(原生redis命令)：set user1 {name:nick, age:15, gender:male}
2. 查(原生redis命令)：get user1
3. 改(原生redis命令)：set user1 {name:nick, age:15, gender:male}
4. 删(原生redis命令)：del user1
5. 记步器：incrby/decrby key //对value进行自增/自减，例如统计在线人数；
2.3.2 Hash
Hash类型的数据结构是key-value形式，每一条value有是key-value形式
1. 增(原生redis命令)：
hset user1 name nick age 10 gender male //name age gender单条添加
hmset user1 name nick age 10 gender male //3个属性批量添加
hincrby user1 age //age自增
2. 查(原生redis命令)：
hget user1 name //获取key为user1指向的name这个key指向的数据
hmget user1 name age gender //批量获取数据
hgetall user1 // 获取key为user1指向的所有数据
hkeys user1 // 获取key为user1指向的所有的hkey字段
hlen user1 //获取key为user1指向的数据的个数
3. 改(原生redis命令)：hset user1 name nick1
4. 删(原生redis命令)：hdel user1 name
2.3.3 List
List类型字符串列表，按照插入顺序排序。可以添加一个元素到列表的头部（左边）或者尾部（右边）
1. 增(原生redis命令)：
LPUSH key value [value ...] // lpush nameList jack // 从左侧push
LINSERT key BEFORE|AFTER pivot value // linsert nameList before jerry tom//从左边，在jerty前面插入tom
LTRIM key begin end // 保留链表范围内的数据元素
rpoplpush key1 key2 // 原子级操作，两个链表数据交互，从key1删除，key2备份
2. 查(原生redis命令)：
LPOP key // lpop key 从链表中获取数据
LRANGE key start stop // lrange nameList 0 -1 查看nameList中所有元素的个数
3. 改(原生redis命令)：LSET key index value // lset nameList 1 nick2，修改nick->nick2
4. 删(原生redis命令)：LREM key count value // lrem key count value 删除count个 数据为value的元素 count取0时，全部删除value
2.3.4 Set
Set集合用来保存多个字符串元素，和list不用的是不允许有重复元素，并且无序
应用场景：用户的兴趣、爱好、关注人列表、粉丝列表等
1. 增(原生redis命令)：
SADD key member [member ...] // sadd nameList jack nick tom jerry
2. 查(原生redis命令)：
SRANDMEMBER key // srandmember nameList 随机获取一条数据，
SMEMBERS key // smembers nameList 查看nameList key的所有数据
3. 删(原生redis命令)：
SREM key member // srem nameList nick
4. 判断元素是否在集合中：
SISMEMBER key member // sismember nameList jack
5. 不同集合间的交、并、差集
SINTER key [key ...] // sinter nameList nameList2
SUINON key [key ...] // sinter nameList nameList2
SDIFF key [key ...] // sinter nameList nameList2 以第一个key为主
2.3.5 ZSet
ZSet在Set集合的基础之上绑定了一个score作为排序的依据
1. 增(原生redis命令)：
ZADD key [NX|XX] [CH] [INCR] score member [score member ...]
zadd result 100 jack //100为score
ZINCRBY key increment member // zincrby result 50 jack 增加jack成员的分数
2. 查(原生redis命令)：
ZCARD key // 查看key里面数据的个数
ZSCORE key member // zscore result jack 查看成员的score
ZRANGE key start stop [WITHSCORES] // zrange result 0 -1 查看排名
ZRANGEBYSCORE key min max [WITHSCORES] [LIMIT offset count] //根据score筛选
ZRANK key member //计算成员的score排名
3. 删(原生redis命令)：
ZREM key member [member ...] // zrem result jack 删除某个成员
ZREMRANGEBYRANK key start stop // 删除指定排名内的升序元素
ZREMRANGEBYSCORE key min max // 删除score在[min, max]范围的元素
4. 不同集合间的交、并、差集
ZINTERSTORE destination numkeys key [key ...] // zinterstore out 2 result result1，destination表示输出的ZSet 交集的score相加
3. Jedis客户端
3.1 redis配置文件
1. bind 127.0.0.1 ###指定redis只接收来自该IP地址的请求，如果不进行设置，将处理所有请求
2. protected-mode yes ###是否开启保护模式，默认开启；如果关闭，外部网络可以直接访问；如果开启，则需要bind ip或者设置访问密码（安全考虑）
3. port 6379 ###redis监听的端口
4. tcp-backlog 511 ###默认511，此参数标识确定了TCP连接中已完成队列（完成三次握手之后）的长度，可以理解为进程还没有accept的TCP连接的队列，tcp-backlog必须小于等于Linux系统定义的/proc/sys/net/somaxconn值
Linux的somaxconn默认为128，当系统并发量大，并且客户端速度缓慢的时候，可以将这两个参数一起参考设置，建议修改为2048，在/etc/sysctl.conf中添加 net.core.somaxconn=2048，然后终端执行sysctl -p命令生效
5. timeout 0 ###设置客户端空闲超过timeout时，redis服务端会断开连接，为0时表示服务端不会主动断开连接，此值不能小于0
6. tcp-keepalive 300 ###redis3.2以后默认为300秒，配置上这个参数之后，对于一些没有正常关闭的客户端，也可以及时关闭，连接超时受tcp-keepalive和另外三个参数影响：
tcp_keepalive_time default 7200 seconds
tcp_keepalive_probes default 9
tcp_keepalive_intvl default 75 seconds
连接超时公式为：tcp_keepalive_time+tcp_keepalive_intvl*tcp_keepalive_probes=7895s=131.58min7. daemonize yes
8. pidfile /var/run/redis/redis.pid ####redis的进程文件
9. loglevel notice ###服务端日志级别，包括debug（很多信息，方便开发、测试），verbose（许多有用的信息，但是没有debug级别信息多），notice（适当的日志级别，适合生产环境），warn（只有非常重要的信息）
3.2. redis客户端、服务端启动
基于上述配置文件的修改项：bind、port
1. 启动redis服务端
redis-server redis.config
2. 启动客户端
redis-cli redis-cli -h [host_ip] -p [port]
3. 停止redis服务端
登录客户端执行：redis-cli -h [host_ip] -p [port] shutdown
3.3 Jedis代码实践
3.3.1 Jedis连接池连接
1. 添加maven依赖
<dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-redis</artifactId> <version>1.4.7.RELEASE</version> </dependency> </dependencies>
2. application.properties配置
spring.redis.sharedpool.nodes=192.168.75.*:6739,192.168.75.*:6780,192.168.75.*:6381
spring.redis.sharedpool.maxTotal=200
spring.redis.sharedpool.maxIdle=10
spring.redis.sharedpool.minIdle=2
3. springboot管理redis连接池
@Configuration @ConfigurationProperties("spring.redis.sharedpool") @Setter @Getter public class SharedJedisConfigPool { private List<String> nodes; //[192.168.75.132:6739,192.168.75.132:6780,192.168.75.132:6381] private Integer maxTotal; private Integer maxIdle; private Integer minIdle; @Bean public ShardedJedisPool sharedPoolInit() { List<JedisShardInfo> infoList = new ArrayList<>(); for (String node : nodes) { String ip = node.split(":")[0]; int port = Integer.parseInt(node.split(":")[1]); infoList.add(new JedisShardInfo(ip, port)); } GenericObjectPoolConfig config = new GenericObjectPoolConfig(); config.setMaxTotal(maxTotal); config.setMaxIdle(maxIdle); config.setMinIdle(minIdle); return new ShardedJedisPool(config, infoList); } }
4. 连接池测试
class DemoApplicationTests { @Autowired private ShardedJedisPool pool; @Test public void func4() { ShardedJedis jedis = pool.getResource(); jedis.set("user", "nick"); } }
3.3.2 redis缓存逻辑
class DemoApplicationTests { @Autowired private ShardedJedisPool pool; @Test public void func1() { String key = "04f2c34c"; ShardedJedis jedis = pool.getResource(); if (jedis.exists(key)) { //redis缓存有数据 String value = jedis.get(key); } else { String key2 = "04f2c34c";//查询数据库 jedis.set(key2, "nick"); } }
}
3.3.3 SharedJedis分片对象
1. 旧版redis中通常使用客户端分片来解决水平扩容问题，即启动多个redis服务端，客户端决定key交由哪个节点存储，下次客户端直接到该节点读取key
2. 可以实现将整个数据分布存储在N个数据库节点中，每个节点只存放总数据量的1/N。
3. 对于需要扩容的场景来说，在客户端分片后，如果想增加节点，需要对数据进行手工迁移，在迁移时为了保证数据一致性，需要将集群暂时下线，相对比较复杂
自定义简单版分片规则如下：
n个redis服务端几乎均匀存储，hash取余，散列，只要有散列就会有数据倾斜
key.hashCode()结果可正可负
key.hashCode()&Integer.MAX_VALUE结果一定为正数，key和结果唯一对应
key.hashCode()&Integer.MAX_VALUE%n
4. 分片计算
4.1 自定义分片
如3.3.3小节讨论，在使用redis集群时，可以通过自定义的简单版的hash散列方式分片，但是有以下两个缺点，因此引出hash一致性算法
1. 数据倾斜不可避免，只要有hash散列，就一定会有数据倾斜，不可能完全均匀；
2. 扩容、缩容时，数据迁移量巨大★
4.2 hash一致性
SharedJedis实现了分片底层的算法——hash一致性（解决了取余算法再扩缩容时，数据迁移量过大的问题）；为什么？redis的hash逻辑为：将所有节点信息hash散列到0~2^32-1区间
4.2 hash一致性问题
引入问题：
1. 数据倾斜：
如果节点的数量很少，而hash环空间很大( 0 ~ 2^32），直接进行一致性hash会导致节点在环上的位置会很不均匀，挤在某个很小的区域。最终对分布式集群的每个实例上储存的缓存数据量不一致，会发生严重的数据倾斜；
2. 缓存雪崩
如果每个节点在环上只有一个节点，那么可以想象，当某一集群从环中消失时，它原本所负责的任务将全部交由顺时针方向的下一个集群处理。
例如当6379退出时，它原本所负责的缓存将全部交给6380处理。这就意味着6380的访问压力会瞬间增大。如果6380因为压力过大而崩溃，那么更大的压力又会向6381压过去，最终服务压力就像滚雪球一样越滚越大，最终导致雪崩
引入虚拟节点
解决上述两个问题最好的办法就是扩展整个环上的节点数量，因此我们引入了虚拟节点的概念。一个实际节点将会映射多个虚拟节点，多次hash，这样Hash环上的空间分割就会变得均匀。
5. 高可用
5.1 主从复制
在同一台虚拟机上构建1主3从的主从模式，一个主节点一般最多6个从节点；
0. 主节点redis配置文件bind要绑定0.0.0.0表示所有连接都可以访问，没有绑定的话，不可以访问主；
1. 创建从节点redis启动配置文件，redis02.config、redis03.config，并修改端口为6380、6381
2. 启动3个redis-server实例 redis-server redis.config、redis-server redis02.config、redis-server redis03.config
3. 主从关系创建，规定6379节点master、6380节点作为slave 、6381节点作为slave；
4. 登录查看节点状态的命令，以客户端登录6379节点为例：6379> info replication
4. 通过配置文件定义主从关系
5. 通过命令挂在主节点，命令如下：从节点> slaveof masterip masterport
6. 本处通过命令方式指定主从关系，客户端登录6080、6081服务端，执行第五步命令
7. 查看6379、6381、6382节点的replicatinon信息，
5.1.1 主从关系测试
测试过程：
主节点6379写数据，从节点6380读数据
1. 登录主节点客户端 set name nick
2. 登录从节点客户端 get name
3. 登录从节点 flushal 执行失败
4. 主节点shutdown
测试结果：
★从节点配置默认为只读模式read-only，主节点宕机，从节点不会自动变为主节点，从节点info replication状态变为如下：
master_link_status:down
master_last_io_seconds_ago:-1
5.2 哨兵模式
5.2.1 什么是哨兵
redis-cluster(redis 3.0)出现之前，redis的使用几乎都是围绕哨兵模式展开，哨兵过程如下：
1. 起单独线程(特殊的redis-cluster)开启对主从结构的监听
2. 监听主，从主节点调用命令info replication，获取主从结构的所有信息，保存在内存，每1秒钟发起一次心跳检测(RPC远程通信协议)，一旦主节点宕机，哨兵集群发起投票选举，过半票数确定结果，增加可信；
3. 哨兵容忍度：允许宕机的个数是哨兵的容忍度，为了保障多票选取，5个哨兵集群节点的容忍度为2，6个哨兵集群的容忍度为2；2n-1个集群和2n个集群的容忍度是一样的，因此哨兵集群都是奇数个(少用一个资源)
5.2.2 搭建哨兵集群
模式：3个哨兵节点，管理6379，6380，6382主从结构，过程如下：
1. 修改哨兵的模板配置文件(sentinel.conf)，配置3个哨兵端口：26379，26380，26381
2. 释放保护模式注释，修改为no
3. 修改监听主节点的配置核心内容：sentine monitor mymaster [master_ip] [master_port] [num]
3..1 mymaster是自定义名称 标识当前哨兵监听的主从结构的代号，多个哨兵监听同一个主从结构的话，此处要保持一致
3.2 num表示为主观下限票数，当哨兵集群不断宕机时，最少要剩下的节点数量，和宕机容忍度有关
4. 拷贝三份，分别做如上修改
5. 启动哨兵(启动之前确定主从集群正常)：redis-sentinel sentine.conf
6. 哨兵没有restart等操作
7. kill掉主节点，查看哨兵日志
8. 哨兵发现主节点宕机，开始投票，查看日志num，确定宕机，投票选取新的节点作为主节点，主节点一旦恢复，则会也从节点角色加入集群，继续提供服务
9. 重启哨兵日志时，删除尾部日志，避免影响本次启动
5.2.2 Jedis连接哨兵集群
1. application.properties配置
spring.redis.sentinel=192.168.75.132:26379,192.168.75.132:26380,192.168.75.132:26381 spring.redis.sharedpool.maxTotal=200 spring.redis.sharedpool.maxIdle=10 spring.redis.sharedpool.minIdle=2
2. springboot管理sentinel连接池
@Configuration @ConfigurationProperties("spring.redis.sentinel") @Getter @Setter public class SentinelConfig { private List<String> nodes; private Integer maxTotal; private Integer maxIdle; private Integer minIdle; @Bean public JedisSentinelPool sentinelPoolInit() { //搜集哨兵集群信息 Set<String> sentinelSet = new HashSet<>(); for (String node : nodes) { String ip = node.split(":")[0]; int port = Integer.parseInt(node.split(":")[1]); sentinelSet.add(new HostAndPort(ip, port).toString()); } //连接池配置对象 GenericObjectPoolConfig config = new GenericObjectPoolConfig(); config.setMaxTotal(maxTotal); config.setMaxIdle(maxIdle); config.setMinIdle(minIdle); //构建哨兵管理对象 return new JedisSentinelPool("mymaster", sentinelSet, config); } }
3. 连接池测试
@SpringBootTest class DemoApplicationTests {
@Autowired private JedisSentinelPool sentinelPool; @Test public void func5() { HostAndPort masterIP = sentinelPool.getCurrentHostMaster(); Jedis jedis = sentinelPool.getResource(); //哨兵模式只能操作主节点 String name = jedis.get("name"); } }
5.3. redis-cluster★
5.3.1 什么是redis集群模式
