redis知识点

1.redis为什么是key，value的，为什么不是支持SQL的？

为什么是key，value
redis是基于内存的数据库，其应用场景是大量数据的快速读写；
大量的数据吞吐量，在同一时间，会并发的有成千上万的连接对数据库进行操作；在这种情况下，单台服务器或者几台服务器远远不能满足这些数据处理的；需要key-value可以满足快速读写；

为什么不是支持SQL
redis是基于内存的数据库，不是一般的关系型数据库；
应用场景是快速读写，复杂查询等操作不是redis的重点，所以不支持SQL；

2.redis是多线程还是单线程？

Redis在4.0之前的版本，是单线程；
原因如下：
1.使用单线程模式的Redis，其开发和维护更简单，因为单线程模式方便开发和调试。
2.即使使用单线程模型也能够并发地处理多客户端的请求，主要是因为Redis内部使用了基于epoll的多路复用；
3.对于Redis来说，主要的性能瓶颈是内存或网络带宽，而非CPU。

Redis在4.0版本中引入了多线程，但是该版本的多线程只能用于大数据量的异步删除，对于非删除操作的意义并不是很大。（意思就是可以使用异步的方式对Redis中的数据进行删除操作）
通常情况下使用del指令可以很快的删除数据，但是当被删除的key是一个非常大的对象时，例如：删除的时包含成千上万个元素的hash集合时，那么del指令就会造成Redis主线程卡顿，因此使用惰性删除可以有效避免Redis卡顿问题。
这样处理的好处是不会使Redis的主线程卡顿，会把这些操作交给后台线程来执行。

Redis为什么这么快？
1.基于内存操作：Redis的所有数据都存在内存中，因此所有的运算都是内存级别的，所以它的性能比较高。
2.数据结构简单：Redis的数据结构比较简单，是为Redis专门设计的，而这些简单的数据结构的查找和操作的时间复杂度都是O(1)。
3.多路复用和非阻塞IO：Redis使用IO多路复用功能来监听多个socket连接的客户端，这样就可以使用一个线程来处理多个情况，从而减少线程切换带来的开销，同时也避免了IO阻塞操作，从而大大提高了Redis的性能。
4.避免上下文切换：因为是单线程模型，因此就避免了不必要的上下文切换和多线程竞争，这就省去了多线程切换带来的时间和性能上的开销，而且单线程不会导致死锁的问题发生。

注意：官方使用的基准测试结果表明，单线程的Redis可以达到10W/S的吞吐量。

3.redis的持久化开启了RDB和AOF下重启服务是如何加载的？

1.AOF持久化开启且存在AOF文件时，优先加载AOF文件，
2.AOF关闭或者AOF文件不存在时，加载RDB文件，
3.加载AOF/RDB文件成功后，Redis启动成功。
4.AOF/RDB文件存在错误时，Redis启动失败并打印错误信息

RDB是一种快照存储持久化方式，具体就是将Redis某一时刻的内存数据保存到硬盘的文件当中，默认保存的文件名为dump.rdb，而在Redis服务器启动时，会重新加载dump.rdb文件的数据到内存当中恢复数据。
AOF持久化方式会记录客户端对服务器的每一次写操作命令，并将这些写操作以Redis协议追加保存到以后缀为aof文件末尾，在Redis服务器重启时，会加载并运行aof文件的命令，以达到恢复数据的目的。

4.redis如果做集群该如何规划？AKF/CAP如何实现和设计？

1.官方cluster方案
从redis 3.0版本开始支持redis-cluster集群，redis-cluster采用无中心结构，每个节点保存数据和整个集群状态，每个节点都和其他节点连接。redis-cluster是一种服务端分片技术。
特点：
每个节点都和n-1个节点通信，这被称为集群总线（cluster bus）。它们使用特殊的端口号，即对外服务端口号加10000。所以要维护好这个集群的每个节点信息，不然会导致整个集群不可用，其内部采用特殊的二进制协议优化传输速度和带宽。
redis-cluster把所有的物理节点映射到[0,16383]slot（槽）上，cluster负责维护node–slot–value。
集群预分好16384个桶，当需要在redis集群中插入数据时，根据CRC16(KEY) mod 16384的值，决定将一个key放到哪个桶中。
客户端与redis节点直连，不需要连接集群所有的节点，连接集群中任何一个可用节点即可。
redis-trib.rb脚本（rub语言）为集群的管理工具，比如自动添加节点，规划槽位，迁移数据等一系列操作。
节点的fail是通过集群中超过半数的节点检测失效时才生效。
整个cluster被看做是一个整体，客户端可连接任意一个节点进行操作，当客户端操作的key没有分配在该节点上时，redis会返回转向指令，指向正确的节点。
为了增加集群的可访问性，官方推荐的方案是将node配置成主从结构，即一个master主节点，挂n个slave从节点。如果主节点失效，redis cluster会根据选举算法从slave节点中选择一个上升为master节点，整个集群继续对外提供服务。

2.twemproxy代理方案
Redis代理中间件twemproxy是一种利用中间件做分片的技术。twemproxy处于客户端和服务器的中间，将客户端发来的请求，进行一定的处理后（sharding），再转发给后端真正的redis服务器。也就是说，客户端不直接访问redis服务器，而是通过twemproxy代理中间件间接访问。降低了客户端直连后端服务器的连接数量，并且支持服务器集群水平扩展。
twemproxy中间件的内部处理是无状态的，它本身可以很轻松地集群，这样可以避免单点压力或故障。
twemproxy又称nutcracker，起源于推特系统中redis、memcached集群的轻量级代理。

注意：twemproxy是一个单点，很容易对其造成很大的压力，所以通常会结合keepalived来实现twemproy的高可用。这时，通常只有一台twemproxy在工作，另外一台处于备机，当一台挂掉以后，vip自动漂移，备机接替工作。

3.哨兵模式方案
Sentinel（哨兵）是Redis的高可用性解决方案：由一个或多个Sentinel实例组成的Sentinel系统可以监视任意多个主服务器以及这些主服务器下的所有从服务器，并在被监视的主服务器进入下线状态时，自动将下线主服务器属下的某个从服务器升级为新的主服务器。

Sentinel的工作方式：
每个Sentinel以每秒钟一次的频率向它所知的Master、Slave以及其他Sentinel实例发送一个PING命令。
如果一个实例距离最后一次有效回复PING命令的时间超过down-after-milliseconds选项所指定的值，则这个实例会被Sentinel标记为主观下线。
如果一个Master被标记为主观下线，则正在监视这个Master的所有Sentinel要以每秒一次的频率确认Master的确进入了主观下线状态。
当有足够数量的Sentinel（大于等于配置文件指定的值）在指定的时间范围内确认Master的确进入了主观下线状态，则Master会被标记为客观下线。
在一般情况下，每个Sentinel会以每10秒一次的频率向它所知的所有Master、Slave发送INFO命令。
当Master被Sentinel标记为客观下线时，Sentinel向下线的Master的所有Slave发送INFO命令的频率会从10秒一次改为每秒一次。
若没有足够数量的Sentinel同意Master已经下线，Master的客观下线状态就会被移除。若Master重新向Sentinel的PING命令返回有效值，Master的主观下线状态就会被移除。

4.codis方案
codis是一个分布式的Redis解决方案，由豌豆荚开源，对于上层的应用来说，连接codis proxy和连接原生的redis server没什么明显的区别，上层应用可以像使用单机的redis一样使用，codis底层会处理请求的转发，不停机的数据迁移等工作，所有后边的事情，对于前面的客户端来说是透明的，可以简单的认为后边连接的是一个内存无限大的redis服务。

5.客户端分片方案
分区的逻辑在客户端实现，由客户端自己选择请求到哪个节点。方案可参考一致性哈希，这种方案通常适用于用户对客户端的行为有完全控制能力的场景。

总结
从各个集群方案的对比中我们也发现Codis是目前用的比较多的一种方案，Codis在高可用方面做的比较好，不需要重启节点和增加删除节点后自动Resharding，但是因为Codis是对redis-server做了改动，如果出现问题或者redis升级小团队可能应付不了，所以对于小规模应用最好还是使用官方的cluster方案。

当然具体方案，看具体场景：
如果希望快速部署，那么可以考虑单节点部署方式。
如果只需要考虑可靠性，那么可以考虑主从复制模式。
如果想要保证高可用，不需要考虑储存成本可以考虑哨兵模式。
如果想提高集群的扩展性和可用性，不要求保证数据的强一致性，且没有批量操作，那么可以考虑集群模式。

AKF
AKF扩展立方体（Scalability Cube），是《架构即未来》一书中提出的可扩展模型，这个立方体有三个轴线，每个轴线描述扩展性的一个维度，他们分别是产品、流程和团队：
X轴 —— 代表无差别的克隆服务和数据，工作可以很均匀的分散在不同的服务实例上；
Y轴 —— 关注应用中职责的划分，比如数据类型，交易执行类型的划分；
Z轴 —— 关注服务和数据的优先级划分，如分地域划分。

运行一个redis实例会有哪些问题：
单点故障
容量瓶颈
访问压力
AKF:
X：全量，镜像
Y：业务，功能
Z：优先级，逻辑再拆分

x轴：在x轴方向上，做N个主机的全量镜像数据的副本，主redis与这些副本的关系为主从。主机可以对外提供read / write ，从机可以对外提供read（读写分离）。结合高可用， 可以解决单点故障和容量瓶颈的问题，只是解决了 read 的压力，而没有解决 write 的压力。
y轴：在y轴方向上，可以把之前一台redis中的数据按照业务功能来拆分成不同的redis实例存储，并且每个redis实例都可以再次做x轴的镜像副本进行读写分离，当然，x轴和y轴之间不是必须要结合使用。y轴的拆分解决了容量瓶颈问题和数据访问压力的问题。
z轴：如果y轴的某个redis实例过于臃肿，还可以把这个redis实例进行z轴的拆分，也就是把这个redis实例里面的数据按照一定规则查分。比如：取模，优先级等规则再次查分成多个redis，使得不同的数据出现在固定的redis里。

CAP
CAP理论指的是一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。

分区：一个分布式系统，网络不通讯，导致连接不通，系统被分割成几个数据区域
原因：数据不连通了，产生数据分区
影响
查还好一点
数据修改时，必须要求数据一致–加锁，实现数据一致性【需求要求数据一致性】
数据修改时，可以数据不一致–不用加锁【需求不要求数据一致性】
分区容忍度
数据的一致性要求高，容忍度高，加锁
数据的一致性要求低，容忍度低，可以不加锁
预期结果，保持数据的一致
可用性
请求在一定时间段内都应该有响应
为了解决锁一直加着
CP理论：【一致性+分区】数据的一致性要求高-加锁
AP理论：【可用性+分区】数据的一致性要求低-不加锁
CAP总结
分区是常态，不可避免，三者不可共存
可用性和一致性是一对冤家
一致性高，可用性低
一致性低，可用性高

5.10万用户一年365天的登录情况如何用redis存储，并快速检索任意时间窗的活跃用户？

Bitmap是一串连续的2进制数字（0或1），每一位所在的位置为偏移(offset)，在bitmap上可执行AND,OR,XOR以及其它位操作。
占空间少
Redis的bitmap从基础到业务

6.redis的5中value类型？

Redis支持五种数据类型：
string（字符串）
hash（哈希）
list（列表）
set（集合）
zset(sorted set：有序集合)。

7.100万并发4G数据，10万并发400G数据，如何设计redis存储方式？

主从+哨兵进行高可用，加快读请求的速度，减轻单节点的压力；
用集群模式来均分这400G数据；