一、 Memcache与Redis的区别
1)、存储方式
Memecache把数据全部存在内存之中，断电后会挂掉，数据不能超过内存大小。
Redis有部份存在硬盘上，这样能保证数据的持久性。
2)、数据支持类型
Memcache对数据类型支持相对简单。
Redis有复杂的数据类型：string（字符串），hash（哈希），list（列表），set（集合）及zset(sorted set：有序集合)
3)、使用底层模型不同
它们之间底层实现方式 以及与客户端之间通信的应用协议不一样。
Redis直接自己构建了VM 机制 ，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求。
4)、value大小
Redis: 一个key或是value大小最大是512M;
memcached的简单限制就是键（key）和item的限制。最大键长为250个字符。可以接受的储存数据不能超过1MB，因为这是典型slab 的最大值。
二、 数据类型
String：缓存、限流、计数器、分布式锁、分布式Session
Hash：存储用户信息、用户主页访问量、组合查询
List：微博关注人时间轴列表、简单队列
Set：赞、踩、标签、好友关系
Zset：排行榜
1. String数据
常用命令：set/get/decr/incr/mget 等；
应用场景：String 是最常用的一种数据类型，普通的 key/value 存储都可以归为此类；
实现方式：String 在 redis 内部存储默认就是一个字符串，被 redisObject 所引用，当遇到 incr、decr 等操作时会转成数值型进行计算，此时 redisObject 的 encoding 字段为 int。
2. Hash数据
常用命令：hget/hset/hgetall 等
应用场景：我们要存储一个用户信息对象数据，其中包括用户 ID、用户姓名、年龄和生日，通过用户 ID 我们希望获取该用户的姓名或者年龄或者生日；
实现方式：Redis Hash 对应 Value 内部实际就是一个 HashMap，实际这里会有 2 种不同实现，这个 Hash 的成员比较少时 Redis 为了节省内存会采用类似
一维数组的方式来紧凑存储，而不会采用真正的 HashMap 结构，对应的 value redisObject 的 encoding 为 zipmap, 当成员数量增大时会自动转成真正的 HashMap,
此时 encoding 为 ht
3. List
常用命令：lpush/rpush/lpop/rpop/lrange 等；
应用场景：Redis list 的应用场景非常多，也是 Redis 最重要的数据结构之一，比如 twitter 的关注列表，粉丝列表等都可以用 Redis 的 list 结构来实现；消息队列；
实现方式：Redis list 的实现为一个双向链表，即可以支持反向查找和遍历，更方便操作，不过带来了部分额外的内存开销，Redis 内部的很多实现，包括发送缓冲队列等也都是用的这个数据结构。
4. Set数据
常用命令：sadd/spop/smembers/sunion 等；
应用场景：Redis set 对外提供的功能与 list 类似是一个列表的功能，特殊之处在于 set 是可以自动排重的，当你需要存储一个列表数据，又不希望出现重复数据时，
set 是一个很好的选择，并且 set 提供了判断某个成员是否在一个 set 集合内的重要接口，这个也是 list 所不能提供的；
实现方式：set 的内部实现是一个 value 永远为 null 的 HashMap，实际就是通过计算 hash 的方式来快速排重的，这也是 set 能提供判断一个成员是否在集合内的原因
5. Sorted Set数据
常用命令：zadd/zrange/zrem/zcard 等；
应用场景：Redis sorted set 的使用场景与 set 类似，区别是 set 不是自动有序的，而 sorted set 可以通过用户额外提供一个优先级 (score) 的参数来为成员排序，
并且是插入有序的，即自动排序。当你需要一个有序的并且不重复的集合列表，那么可以选择 sorted set 数据结构，比如 twitter 的 public timeline 可以以发表时间作为 score 来存储，这样获取时就是自动按时间排好序的。
实现方式：Redis sorted set 的内部使用 HashMap 和跳跃表 (SkipList) 来保证数据的存储和有序，HashMap 里放的是成员到 score 的映射，而跳跃表里存放的
是所有的成员，排序依据是 HashMap 里存的 score, 使用跳跃表的结构可以获得比较高的查找效率，并且在实现上比较简单。
三、 Redis 持久化
Redis 可以以 master-slave 的方式配置服务器，Slave 节点对数据进行 replica 备份，Slave 节点也可以充当 Read only 的节点分担数据读取的工作。
Redis 虽然是基于内存的存储系统，但是它本身是支持内存数据的持久化的，而且提供两种主要的持久化策略：RDB 快照和 AOF 日志
Redis 内建支持两种持久化方案，snapshot 快照和 AOF 增量 Log 方式。快照顾名思义就是隔一段时间将完整的数据 Dump 下来存储在文件中。A
OF 增量 Log 则是记录对数据的修改操作（实际上记录的就是每个对数据产生修改的命令本身），两种方案可以并存，也各有优缺点
四、 Redis 的 7 个应用场景
1. 缓存 —— 热数据：
热点数据（经常会被查询，但是不经常被修改或者删除的数据）
2. 计数器： 统计点击数等应用
3. 队列： 相当于消息系统； 队列不仅可以把并发请求变成串行，并且还可以做队列或者栈使用
4. 位操作（大数据处理）：
用于数据量上亿的场景下，例如几亿用户系统的签到，去重登录次数统计，某用户是否在线状态等等。
想想一下腾讯 10 亿用户，要几个毫秒内查询到某个用户是否在线，你能怎么做？千万别说给每个用户建立一个 key，然后挨个记（你可以算一下需要的内存会很恐怖，而且这种类似的需求很多，腾讯光这个得多花多少钱。。）好吧。这里要用到位操作 —— 使用 setbit、getbit、bitcount 命令。
原理是：redis 内构建一个足够长的数组，每个数组元素只能是 0 和 1 两个值，然后这个数组的下标 index 用来表示我们上面例子里面的用户 id（必须是数字哈），那么很显然，这个几亿长的大数组就能通过下标和元素值（0 和 1）来构建一个记忆系统，上面我说的几个场景也就能够实现。用到的命令是：setbit、getbit、bitcount
5. 分布式锁与单线程机制：
验证前端的重复请求（可以自由扩展类似情况），可以通过 redis 进行过滤：每次请求将 request Ip、参数、接口等 hash 作为 key 存储 redis（幂等性请求），设置多长时间有效期，然后下次请求过来的时候先在 redis 中检索有没有这个 key，进而验证是不是一定时间内过来的重复提交
秒杀系统，基于 redis 是单线程特征，防止出现数据库 “爆破”
全局增量 ID 生成，类似 “秒杀”
6. 最新列表：
例如新闻列表页面最新的新闻列表，如果总数量很大的情况下，尽量不要使用 select a from A limit 10 这种 low 货，尝试 redis 的 LPUSH 命令构建 List，
一个个顺序都塞进去就可以啦。不过万一内存清掉了咋办？也简单，查询不到存储 key 的话，用 mysql 查询并且初始化一个 List 到 redis 中就好了。
7. 排行榜
谁得分高谁排名往上。命令：ZADD（有续集，sorted set）
五、 Redis集群的数据一致性（redis分布式）
Redis 集群没有使用一致性hash, 而是引入了哈希槽的概念。
Reds 集群有16384个哈希槽,每个key通过CRC16校验后对16384取模来决定放置哪个槽.集群的每个节点负责一部分hash槽。
这种结构很容易添加或者删除节点，并且无论是添加删除或者修改某一个节点，都不会造成集群不可用的状态。
使用哈希槽的好处就在于可以方便的添加或移除节点。
当需要增加节点时，只需要把其他节点的某些哈希槽挪到新节点就可以了；
当需要移除节点时，只需要把移除节点上的哈希槽挪到其他节点就行了；
在这一点上，我们以后新增或移除节点的时候不用先停掉所有的 redis 服务
通过key做一致性哈希，实现key对应redis结点的分布。
一致性哈希的实现：
l hash值计算：通过支持MD5与MurmurHash两种计算方式，默认是采用MurmurHash，高效的hash计算。
l 一致性的实现：通过java的TreeMap来模拟环状结构，实现均匀分布
六、 MySQL里有2000w数据，redis中只存20w的数据，如何保证redis中的数据都是热点数据
相关知识：redis 内存数据集大小上升到一定大小的时候，就会施行数据淘汰策略。
redis 提供 6种数据淘汰策略：
voltile-lru：从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰
volatile-ttl：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰
volatile-random：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰
allkeys-lru：从数据集（server.db[i].dict）中挑选最近最少使用的数据淘汰
allkeys-random：从数据集（server.db[i].dict）中任意选择数据淘汰
no-enviction（驱逐）：禁止驱逐数据
七、 Redis哨兵机制（Sentinel）
Redis的哨兵(sentinel) 系统用于管理多个 Redis 服务器：
监控(Monitoring): 哨兵(sentinel) 会不断地检查你的Master和Slave是否运作正常。
提醒(Notification):当被监控的某个 Redis出现问题时, 哨兵(sentinel) 可以通过 API 向管理员或者其他应用程序发送通知。
自动故障迁移(Automatic failover):当一个Master不能正常工作时，哨兵(sentinel) 会开始一次自动故障迁移操作,它会将失效Master的其中一个Slave升级为新的Master,
并让失效Master的其他Slave改为复制新的Master; 当客户端试图连接失效的Master时,集群也会向客户端返回新Master的地址,使得集群可以使用Master代替失效Master。
哨兵(sentinel) 是一个分布式系统,你可以在一个架构中运行多个哨兵(sentinel) 进程,这些进程使用流言协议(gossipprotocols)来接收关于Master是否下线的信息,
并使用投票协议(agreement protocols)来决定是否执行自动故障迁移,以及选择哪个Slave作为新的Master。
工作原理：
1.三个定时监控任务：
1.1 每隔10s，每个S节点（哨兵节点）会向主节点和从节点发送info命令获取最新的拓扑结构
1.2 每隔2s，每个S节点会向某频道上发送该S节点对于主节点的判断以及当前Sl节点的信息，
同时每个Sentinel节点也会订阅该频道，来了解其他S节点以及它们对主节点的判断（做客观下线依据）
1.3 每隔1s，每个S节点会向主节点、从节点、其余S节点发送一条ping命令做一次心跳检测(心跳检测机制)，来确认这些节点当前是否可达
2.主客观下线：
2.1主观下线：根据第三个定时任务对没有有效回复的节点做主观下线处理
2.2客观下线：若主观下线的是主节点，会咨询其他S节点对该主节点的判断，超过半数，对该主节点做客观下线
3.选举出某一哨兵节点作为领导者，来进行故障转移。选举方式：raft算法。每个S节点有一票同意权，哪个S节点做出主观下线的时候，
就会询问其他S节点是否同意其为领导者。获得半数选票的则成为领导者。基本谁先做出客观下线，谁成为领导者。
八、 顺序队列与循环队列
队列本身也是一种线性表，因而和线性表一样也有顺序和链式存储结构两种存储方式。
采用顺序存储结构实现的队列称为顺序队列；
采用链式存储结构实现的队列称为链队列。
1. 顺序队列中的溢出现象：
① "下溢"现象
当队列为空时，做出队运算产生的溢出现象。“下溢”是正常现象，常用作程序控制转移的条件。
② "真上溢"现象
当队列满时，做进栈运算产生空间溢出的现象。“真上溢”是一种出错状态，应设法避免。
③ "假上溢"现象
由于入队和出队操作中，头尾指针只增加不减小，致使被删元素的空间永远无法重新利用。当队列中实际的元素个数远远小于向量空间的规模时，
也可能由于尾指针已超越向量空间的上界而不能做入队操作。该现象称为"假上溢"现象。
2. 循环队列
为充分利用向量空间，克服"假上溢"现象的方法是：将向量空间想象为一个首尾相接的圆环，并称这种向量为循环向量。存储在其中的队列称为循环队列
网友评论