Redis 概念Redis 是一个开源（BSD许可）的，内存中的数据结构存储系统，它可以用作数据库、缓存和消息中间件。 它支持多种类型的数据结构，如 字符串（strings）， 散列（hashes）， 列表（lists）， 集合（sets）， 有序集合（sorted sets） 与范围查询， bitmaps， hyperloglogs 和 地理空间（geospatial） 索引半径查询。 Redis 内置了 复制（replication），LUA脚本（Lua scripting）， LRU驱动事件（LRU eviction），事务（transactions） 和不同级别的 磁盘持久化（persistence）， 并通过 Redis哨兵（Sentinel）和自动 分区（Cluster）提供高可用性（high availability）。
Redis 优势1.速度快
官方数据读写性能10万/s，原因：数据库存放在memory中，redis利用c语言编写，单线程架构预防了多线程竞争问题，
2.基于键值对的数据结构服务器
几乎所有的编程语言都提供了类似字典的功能，类似于这种组织数据的方式叫作基于键值的方式，与很多键值对数据库不同的是，Redis中的值不仅可以是字符串，而且还可以是具体的数据结构，这样不仅能便于在许多应用场景的开发，同时也能够提高开发效率。Redis的全称是REmote Dictionary Server，它主要提供了5种数据结构：字符串、哈希、列表、集合、有序集合，同时在字符串的基础之上演变出了位图（Bitmaps）和HyperLogLog两种神奇的“数据结构”，并且随着LBS（Location Based Service，基于位置服务）的不断发展。
3.丰富的功能
除了5种数据结构，Redis还提供了许多额外的功能：
·提供了键过期功能，可以用来实现缓存。
·提供了发布订阅功能，可以用来实现消息系统。
·支持Lua脚本功能，可以利用Lua创造出新的Redis命令。
·提供了简单的事务功能，能在一定程度上保证事务特性。
·提供了流水线（Pipeline）功能，这样客户端能将一批命令一次性传到
Redis，减少了网络的开销。
4.简单稳定
Redis的简单主要表现在三个方面。首先，Redis的源码很少，其次，Redis使用单线程模型，最后，Redis不需要依赖于操作系统中的类库（例如Memcache需要依赖libevent这样的系统类库），Redis自己实现了事件处理的相关功能。
5.客户端语言多
Redis提供了简单的TCP通信协议，很多编程语言可以很方便地接入到Redis
6.持久化
通常看，将数据放在内存中是不安全的，一旦发生断电或者机器故障，重要的数据可能就会丢失，因此Redis提供了两种持久化方式：RDB和AOF，即可以用两种策略将内存的数据保存到硬盘中（如图1-1所示），这样就保证了数据的可持久性。
7.主从复制
Redis提供了复制功能，实现了多个相同数据的Redis副本（如图1-2所示），复制功能是分布式Redis的基础。
8.高可用和分布式
Redis从2.8版本正式提供了高可用实现Redis Sentinel，它能够保证Redis节点的故障发现和故障自动转移。Redis从3.0版本正式提供了分布式实现Redis Cluster，它是Redis真正的分布式实现，提供了高可用、读写和容量的扩展性。
Redis集群介绍Redis 集群是一个提供在多个Redis间节点间共享数据的程序集。Redis集群并不支持处理多个keys的命令,因为这需要在不同的节点间移动数据,从而达不到像Redis那样的性能,在高负载的情况下可能会导致不可预料的错误.
Redis 集群通过分区来提供一定程度的可用性,在实际环境中当某个节点宕机或者不可达的情况下继续处理命令. Redis 集群的优势:自动分割数据到不同的节点上。整个集群的部分节点失败或者不可达的情况下能够继续处理命令。
Redis 集群的数据分片
Redis 集群没有使用一致性hash, 而是引入了 哈希槽的概念.Redis 集群有16384个哈希槽,每个key通过CRC16校验后对16384取模来决定放置哪个槽.集群的每个节点负责一部分hash槽,举个例子,比如当前集群有3个节点,那么:
节点 A 包含 0 到 5500号哈希槽.
节点 B 包含5501 到 11000 号哈希槽.
节点 C 包含11001 到 16384号哈希槽.
这种结构很容易添加或者删除节点. 比如如果我想新添加个节点D, 我需要从节点 A, B, C中得部分槽到D上. 如果我想移除节点A,需要将A中的槽移到B和C节点上,然后将没有任何槽的A节点从集群中移除即可. 由于从一个节点将哈希槽移动到另一个节点并不会停止服务,所以无论添加删除或者改变某个节点的哈希槽的数量都不会造成集群不可用的状态.
Redis 集群的主从复制模型为了使在部分节点失败或者大部分节点无法通信的情况下集群仍然可用，所以集群使用了主从复制模型,每个节点都会有N-1个复制品.
在我们例子中具有A，B，C三个节点的集群,在没有复制模型的情况下,如果节点B失败了，那么整个集群就会以为缺少5501-11000这个范围的槽而不可用.
然而如果在集群创建的时候（或者过一段时间）我们为每个节点添加一个从节点A1，B1，C1,那么整个集群便有三个master节点和三个slave节点组成，这样在节点B失败后，集群便会选举B1为新的主节点继续服务，整个集群便不会因为槽找不到而不可用了
不过当B和B1 都失败后，集群是不可用的.
Redis 一致性保证Redis 并不能保证数据的强一致性. 这意味这在实际中集群在特定的条件下可能会丢失写操作.第一个原因是因为集群是用了异步复制. 写操作过程:客户端向主节点B写入一条命令.主节点B向客户端回复命令状态.主节点将写操作复制给他得从节点 B1, B2 和 B3.主节点对命令的复制工作发生在返回命令回复之后， 因为如果每次处理命令请求都需要等待复制操作完成的话， 那么主节点处理命令请求的速度将极大地降低 —— 我们必须在性能和一致性之间做出权衡。 注意：Redis 集群可能会在将来提供同步写的方法。 Redis 集群另外一种可能会丢失命令的情况是集群出现了网络分区， 并且一个客户端与至少包括一个主节点在内的少数实例被孤立。
举个例子 假设集群包含 A 、 B 、 C 、 A1 、 B1 、 C1 六个节点， 其中 A 、B 、C 为主节点， A1 、B1 、C1 为A，B，C的从节点， 还有一个客户端 Z1 假设集群中发生网络分区，那么集群可能会分为两方，大部分的一方包含节点 A 、C 、A1 、B1 和 C1 ，小部分的一方则包含节点 B 和客户端 Z1 .Z1仍然能够向主节点B中写入, 如果网络分区发生时间较短,那么集群将会继续正常运作,如果分区的时间足够让大部分的一方将B1选举为新的master，那么Z1写入B中得数据便丢失了.
注意， 在网络分裂出现期间， 客户端 Z1 可以向主节点 B 发送写命令的最大时间是有限制的， 这一时间限制称为节点超时时间（node timeout）， 是 Redis 集群的一个重要的配置选项。
Redis 高并发1.redis是基于内存的，内存的读写速度非常快；
2.redis是单线程的，省去了很多上下文切换线程的时间；
3.redis使用多路复用技术，可以处理并发的连接。非阻塞IO 内部实现采用epoll，采用了epoll+自己实现的简单的事件框架。epoll中的读、写、关闭、连接都转化成了事件，然后利用epoll的多路复用特性，绝不在io上浪费一点时间。
下面重点介绍单线程设计和IO多路复用核心设计快的原因
为什么Redis是单线程的1.官方答案
因为Redis是基于内存的操作，CPU不是Redis的瓶颈，Redis的瓶颈最有可能是机器内存的大小或者网络带宽。既然单线程容易实现，而且CPU不会成为瓶颈，那就顺理成章地采用单线程的方案了。
2.性能指标
关于redis的性能，官方数据处理每秒几十万的请求。
3.详细原因
1）不需要各种锁的性能消耗
Redis的数据结构并不全是简单的Key-Value，还有list，hash等复杂的结构，这些结构有可能会进行很细粒度的操作，比如在很长的列表后面添加一个元素，在hash当中添加或者删除一个对象。这些操作可能就需要加非常多的锁，导致的结果是同步开销大大增加。
总之，在单线程的情况下，就不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗。
2）单线程多进程集群方案
单线程的威力实际上非常强大，每核心效率也非常高，多线程自然是可以比单线程有更高的性能上限，但是在今天的计算环境中，即使是单机多线程的上限也往往不能满足需要了，需要进一步摸索的是多服务器集群化的方案，这些方案中多线程的技术照样是用不上的。所以单线程、多进程的集群不失为一个时髦的解决方案。
3）CPU消耗
采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗 CPU。
但是如果CPU成为Redis瓶颈，或者不想让服务器其他CUP核闲置，那怎么办？
可以考虑多起几个Redis进程，Redis是key-value数据库，不是关系数据库，数据之间没有约束。只要客户端分清哪些key放在哪个Redis进程上就可以了。
Redis单线程的优劣势1、代码更清晰，处理逻辑更简单不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗不存在多进程或者多线程导致的切换而消耗CPU
单进程单线程弊端无法发挥多核CPU性能，不过可以通过在单机开多个Redis实例来完善；
2、IO多路复用技术 redis 采用网络IO多路复用技术来保证在多连接的时候， 系统的高吞吐量。
多路-指的是多个socket连接，复用-指的是复用一个线程。多路复用主要有三种技术：select，poll，epoll。epoll是最新的也是目前最好的多路复用技术。
这里“多路”指的是多个网络连接，“复用”指的是复用同一个线程。采用多路 I/O 复用技术可以让单个线程高效的处理多个连接请求（尽量减少网络IO的时间消耗），且Redis在内存中操作数据的速度非常快（内存内的操作不会成为这里的性能瓶颈），主要以上两点造就了Redis具有很高的吞吐量。
Redis cluster迁移redis集群迁移分为两种方法：
1、迁移方案利用cluster 自身集群管理工具 redis-trib.rb 进行无损迁移方案。
2、迁移方案利用Redis cluster 自身管理工具，停机老集群节点，通过rdb 文件进行归档
第一种方式介绍：
部署新节点redis 实例。（注意部署以后是单实例，不用创建成集群）
将新节点redis 添加到老集群中。(添加master 节点)
将新节点redis 添加到老集群中。(添加slave 节点)
集群进行迁移
将槽位均匀分片给新的剩余master 节点
优势：保证数据完整性
缺陷：迁移后源redis集群不可用。
第二种方式介绍：
老集群节点生成RDB 文件（操作前提: 应用断开Redis 连接）
获取老集群节点槽位信息，并记录
部署新Redis cluster 迁移环境
为新Redis 集群分配槽位(对应老集群节点的槽位)
将老集群的rdb 文件分别拷贝相同的槽位节点下。
优势：保证源redis的可用性，应用可随时切换。
缺陷：在迁移过程中槽位必须一直对应。
keepalived什么是Keepalived呢，keepalived观其名可知，保持存活，在网络里面就是保持在线了，也就是所谓的高可用或热备，用来防止单点故障(单点故障是指一旦某一点出现故障就会导致整个系统架构的不可用)的发生。
Redis Master-Slave + Keepalive + VIP。
这是很经典的db架构，也可以用与mysql的主从切换。基本原理是：Keepalive通过脚本检测master的存活，然后通过漂移VIP（Virtual IP）完成主从切换。
基础架构图
基本构建与原理1）Keepalive + VIP : 在redis master-slave上部署keepalived、redis instance存活检测脚本、以及告警通知脚本。
2）当redis master失效的时候，VIP从master上漂移到slave上，完成m-s角色和配置更改。
3）客户端连接redis的参数中host设置的是VIP，整个切换过程对客户端透明。
优缺点与适用场景优点：实现简单，成本低。
缺点：整个集群的最大吞吐量受限于redis单实例的处理能力，除非一个应用使用多套这种Keepalive+VIP方案。
因而扩展能力较差，而且不适合目前单机部署多个redis实例的部署场景，而我们的一个物理机上至少部署8个redis实例。
适合场景：并发请求不是很高的应用。