Redis框架详解
目录
1. redis是什么
主要特点
2. redis中存储的数据类型
2.1 String类型
2.2 List类型
2.3 Hash类型
2.4 Set类型
2.5 Zset类型
2.6 其它类型
3.redis高可用框架
1. redis是什么
Redis 是一个开源的、基于内存的数据结构存储系统，是 Remote Dictionary Server（远程字典服务器）的缩写。可用作：
- 数据库
- 缓存
- 消息中间件
主要特点
- 基于内存操作，性能极高
- 支持丰富的数据结构（字符串、哈希表、列表、集合等）
- 支持数据持久化
- 支持主从复制和集群
- 单线程模型（核心操作）
2. redis中存储的数据类型
常见的5种数据类型：String(字符串)、Hash(哈希)、List(列表)、Set(集合)、Zset(有序集合)。
2.1 String类型
String 是最基本的 key-value 结构，key 是唯一标识，value 是具体的值，value其实不仅是字符串， 也可以是数字（整数或浮点数），value 最多可以容纳的数据长度是512M。
常见指令：
| 操作 | 常用指令 | value类型 |
| 查询 | GET key | 字符串 |
| 增加 | SET key value | |
| 删除 | DEL key | |
| 判断key是否存在 | EXISTS key | |
| 判断key中value长度 | STRLEN key | |
| value值+1 | INCR key | 整数 |
| value值-1 | DECR key | |
| value值+10 | INCR key 10 | |
| 设置过期时间60秒 | EXPIRE key 60 | |
| 查看数据还有多久过期 | TTL key | time to live |
| 设置值和过期时间 | SETEX key 60 value SET key value EX 60 | |
| 不存在插入 | SETNX key value |
应用场景：
- 缓存对象数据
- 计数(单线程原子操作)：INCR key
- 分布式锁：SETNX key value PX 1000，若key不存在，则插入成功即加锁成功，若key存在，加锁失败，同时给该key锁设置过期时间1秒。
- 共享session信息：分布式系统，服务器共享redis中存储的session信息。
扩展：SETEX 是较早引入的命令，当时Redis主要使用秒作为时间单位；SET 命令的选项是后来添加的，增加了更精细的毫秒级控制，PX = Precise eXpire (in milliseconds)
2.2 List类型
简单的字符串列表，底层采用双链表，列表的最大长度为 2^32 - 1，也即每个列表支持超过 40 亿个元素。
常用指令：
| 操作 | 常用指令 | |
| 在value列表left左侧插入数据 | LPUSH key value | |
| 在value列表右侧right插入数据 | RPUSH key value | |
| 列表左侧弹出头元素 | LPOP key | |
| 列表右侧弹出尾元素 | RPOP key | |
| 返回指定区间内的元素 | LRANGE key start stop |
应用场景：
- 消息队列：
2.3 Hash类型
Hash 是一个键值对（key - value）集合，其中 value 的形式如： value=[{field1，value1}，...{fieldN，valueN}]。Hash 特别适合用于存储对象。
常用指令：
| 操作 | 常用指令 |
| 增加 | HSET key field value(HMSET key field1 value1 field2 value2 ) |
| 获取 | HGET key field |
| 删除 | HDEL key field |
| field的数量 | HLEN key |
2.4 Set类型
无序并唯一的键值集合，一个集合最多可以存储 2^32-1 个元素。
常见指令：
| 操作 | 指令 | 备注 |
| 增加元素 | SADD key value | |
| 删除元素 | SREM key value | |
| 获取所有元素 | SMEMBERS key |
应用场景：数据去重，数据唯一性，集合之间交集、并集、错集。
点赞：文章下点赞的用户数据
共同关注：不同的用户关注的相同的公众号数据
2.5 Zset类型
有序集合类型：元素依然是唯一的，不允许重复，但是每个元素是有顺序的。每个元素存储两个值，一个是顺序号，一个是元素值。
常用指令
| 操作 | 指令 | 备注 |
| 增加 | ZADD key score value | |
| 删除 | ZREM key value | |
| 返回元素的分值 | ZSCORE key value | |
| 某个元素的score增加 | ZINCRBY key score value |
应用场景：排行榜、排序
2.6 其它类型
- BitMap（2.2 版新增）：二值状态统计的场景，比如签到、判断用户登陆状态、连续签到用户总数等；
- HyperLogLog（2.8 版新增）：海量数据基数统计的场景，比如百万级网页 UV 计数等；
- GEO（3.2 版新增）：存储地理位置信息的场景，比如滴滴叫车；
- Stream（5.0 版新增）：消息队列，相比于基于 List 类型实现的消息队列，有这两个特有的特性：自动生成全局唯一消息ID，支持以消费组形式消费数据。
3.redis高可用框架
框架：主从模式，数据修改只在主服务器上，然后将最新的数据同步给从服务器。
如果主服务器挂了，如何选择新的主服务器呢，引入哨兵机制，它会检测主节点是否存活，哨兵的作用：监控、选主、通知。
为了减少一个哨兵节点对主服务器判断的失误，所以，为了减少误判的情况，哨兵在部署的时候不会只部署一个节点，而是用多个节点部署成哨兵集群（最少需要三台机器来部署哨兵集群），通过多个哨兵节点一起判断，就可以就可以避免单个哨兵因为自身网络状况不好，而误判主节点下线的情况。同时，多个哨兵的网络同时不稳定的概率较小，由它们一起做决策，误判率也能降低。
这张图展示的是Redis哨兵（Sentinel）模式的架构相关逻辑。 在Redis哨兵模式中，存在主节点（Master）、从节点（Slave）和哨兵节点（Sentinel）。主节点负责处理写操作，从节点通过“写同步”从主节点同步数据，主要处理读操作。
哨兵节点的作用是监控主节点的状态。图中的哨兵A、B、C会对主节点是否下线进行判断与协商。比如哨兵B和C判定主节点“主观下线”（即自身认为主节点可能下线）后，会相互询问对方是否也认为主节点下线，哨兵C表示认同，而哨兵A则判定主节点在线且不认同其他哨兵的观点。当多数哨兵（通常是超过半数）判定主节点真正下线（客观下线）后，会触发故障转移流程，从从节点中选举出新的主节点，保证Redis服务的高可用性。
参考：https://www.xiaolincoding.com/redis/cluster/master_slave_replication.html