“本节主要介绍 Redis的基本内容”
linux软件-Redis(一)
一、Redis的特点
- Redis支持数据的持久化，可以将内存中的数据保存在磁盘中，重启的时候可以再次加载进行使用。
- Redis不仅仅支持简单的key-value类型的数据，同时还提供字符串（strings）、lists（列表）、sets（集合）和zsets（有序集合）、散列（hash）等数据结构的存储。
- Redis支持数据的备份，即master-slave模式的数据备份。
- 性能极高：Redis能读的速度是110000次/s,写的速度是81000次/s 。
- 原子性：Redis的所有操作都是原子性的，意思就是要么成功执行要么失败完全不执行。单个操作是原子性的。多个操作也支持事务，即原子性，通过MULTI和EXEC指令包起来。
- 丰富的特性：Redis还支持 publish(发布)/subscribe（订阅）, 通知, key 过期等等特性。
二、持久化的两种方式
由于Redis的数据都存放在内存中，如果没有配置持久化，redis重启后数据就全丢失了，于是需要开启redis的持久化功能，将数据保存到磁盘上，当redis重启后，可以从磁盘中恢复数据。redis提供两种方式进行持久化：
- 一种是RDB持久化，原理是将Reids在内存中的数据定时dump到磁盘上。性能高，但可能会引起一定程度的数据丢失。
- 一种是AOF（append only file）持久化，原理是将Reids的操作日志以追加的方式写入文件，类似mysql的binlog，记录每次更新的日志。
三、Redis的应用场景
1、缓存（热点数据的缓存）
热点数据（经常会被查询，但是不经常被修改或者删除的数据），由于redis访问速度快、支持的数据类型比较丰富，首选是使用redis缓存。Select 数据库前查询redis，有的话使用redis数据，放弃select 数据库，没有的话，select 数据库，然后将数据插入redis。update或者delete数据前，查询redis是否存在该数据，存在的话先删除redis中数据，然后再update或者delete数据库中的数据。
2、排行榜
很多网站都有排行榜应用的，如京东的月度销量榜单、商品按时间的上新排行榜等。Redis提供的有序集合数据类构能实现各种复杂的排行榜应用。
3、计数器
什么是计数器，如电商网站商品的浏览量、视频网站视频的播放数等。为了保证数据实时效，每次浏览都得给+1，并发量高时如果每次都请求数据库操作无疑是种挑战和压力。Redis提供的incr命令来实现计数器功能，内存操作，性能非常好，非常适用于这些计数场景。
4、消息系统
消息队列是大型网站必用中间件，如ActiveMQ、RabbitMQ、Kafka等流行的消息队列中间件，主要用于业务解耦、流量削峰及异步处理实时性低的业务。Redis提供了发布/订阅及阻塞队列功能，能实现一个简单的消息队列系统。另外，这个不能和专业的消息中间件相比。
四、Redis部署方案
1、Redis单机模式
Redis单机模式，采用单个Redis节点部署架构，没有备用节点实时同步数据，不提供数据持久化和备份策略，适用于数据可靠性要求不高的纯缓存业务场景。
优点：
- 架构简单，部署方便；
- 高性价比：缓存使用时无需备用节点（单实例可用性可以用supervisor或crontab保证），当然为了满足业务的高可用性，也可以牺牲一个备用节点，但同时刻只有一个实例对外提供服务；
缺点：
- 不保证数据的可靠性；
- 在缓存使用，进程重启后，数据丢失，即使有备用的节点解决高可用性，但是仍然不能解决缓存预热问题，因此不适用于数据可靠性要求高的业务；
- 高性能受限于单核CPU的处理能力（Redis是单线程机制），CPU为主要瓶颈，所以适合操作命令简单，排序、计算较少的场景。也可以考虑用Memcached替代。
2、Redis多副本（主从）
Redis多副本，采用主从（replication）部署结构，相较于单副本而言最大的特点就是主从实例间数据实时同步，并且提供数据持久化和备份策略。主从实例部署在不同的物理服务器上，根据公司的基础环境配置，可以实现同时对外提供服务和读写分离策略。
3、Redis sentinel（哨兵模式）
背景：当用Redis做Master-slave的高可用方案时，假如master宕机了，Redis本身(包括它的很多客户端)没有实现自动进行主备切换，需要手动把一台从服务器切换为主服务器，这就需要人工干预，费事费力，还会造成一段时间内服务不可用。这不是一种推荐的方式，更多时候，我们优先考虑哨兵模式。
Redis-sentinel本身也是一个独立运行的进程，它能监控多个master-slave集群，发现master宕机后能进行切换。redis-Sentinel(哨兵模式)是Redis官方推荐的高可用性(HA)解决方案。
sentinel可以让redis实现主从复制，当一个集群中的master失效之后，sentinel可以选举出一个新的master用于自动接替master的工作，集群中的其他redis服务器自动指向新的master同步数据。一般建议sentinel采取奇数台（Redis Sentinel的节点数量要满足2n+1（n>=1）的奇数个，官方建议至少3个），防止某一台sentinel无法连接到master导致误切换。其结构如下:
在Server1 掉线后：
升级Server2 为新的主服务器：
选出新的master节点，redis sentinel会选一个合适的slave来升级为master，那么，如何选择一个合适的slave呢？顺序如下：
- 选择slave-priority最高的slave节点（默认是相同）。
- 选择复制偏移量最大的节点。
- 如果以上两个条件都不满足，选runId最小的（启动最早的）。
sentinel哨兵通过如下功能实现故障切换
描述一下故障切换（failover）的过程。假设主服务器宕机，哨兵1先检测到这个结果，系统并不会马上进行failover过程，仅仅是哨兵1主观的认为主服务器不可用，这个现象称为主观下线。当后面的哨兵也检测到主服务器不可用，并且数量达到一定值时（大于等于配置文件指定的值），那么哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行failover操作。切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为客观下线。这样对于客户端而言，一切都是透明的。当客户端试图连接失效的主服务器时，sentine集群也会向客户端返回新主服务器的地址，使得集群可以使用新主服务器代替失效服务器。
4、redis-cluster(集群模式)
Redis Sentinel集群模式中，随着业务量和数据量增到性能达到redis单节点瓶颈，垂直扩容受机器限制，水平扩容涉及对应用的影响以及数据迁移中数据丢失风险。针对这些痛点,Redis3.0推出cluster分布式集群方案，当遇到单节点内存，并发，流量瓶颈时，采用cluster方案实现负载均衡。
Redis Cluster有效地解决了 Redis 分布式方面的需求。分布式数据存储方案中最为重要的一点就是数据分片，也就是所谓的 Sharding。
为了使得集群能够水平扩展，首要解决的问题就是如何将整个数据集按照一定的规则分配到多个节点上，常用的数据分片的方法有：范围分片，哈希分片，一致性哈希算法，哈希槽等。
Redis Cluster 采用虚拟哈希槽分区，所有的键根据哈希函数映射到 0 ~ 16383 整数槽内，计算公式：slot = CRC16(key) & 16383。每一个节点负责维护一部分槽以及槽所映射的键值数据。
下图展现一个五个节点构成的集群，每个节点平均大约负责3276个槽，以及通过计算公式映射到对应节点的对应槽的过程。
Redis Cluster 一般由多个节点组成，节点数量至少为 6 个才能保证组成完整高可用的集群，其中三个为主节点，三个为从节点。三个主节点会分配槽，处理客户端的命令请求，而从节点可用在主节点故障后，顶替主节点。
一般来说，主 Redis 节点会处理 Clients 的读写操作，而从节点只处理读操作。
