缓存中间件-----Memcache和Redis的区别
Memcache:代码层类似Hash
++支持简单数据类型
++不支持数据持久化存储
++不支持主从
++不支持分片
Redis
++数据类型丰富
++支持数据磁盘持久化
++支持主从
++支持分片
为什么Redis能这么快 100000+QPS(QPS即query per second,每秒内查询次数）
++完全基于内存，绝大部分请求时纯碎的内存操作，执行效率高
++数据结构简单，对数据操作也简单
++采用单线程，单线程也能处理高并发请求，想多核也可以启动实例
++使用多路I/O复用模型，非阻塞IO
Redis的数据类型
供用户使用的数据类型
++String:最基本的数据类型，二进制安全
++Hash:String元素组成的字典，适合用于存储对象
++List:列表，按照String元素插入顺序排序
++Set:String元素组成的无序集合，通过哈希表实现，不允许重复
++Sorted Set:通过分数来为集合中的成员进行从小到大的排序
++用于计数的HyperLogLog,用于支持存储地理位置信息的Geo
从海量Key里查询出某一固定前缀的Key
留意细节
++摸清数据规模，即问清楚边界
KEYS pattern:查找所有符合给定模式patter的key
++KEYS指令一次性返回所有匹配的key
++键的数量过大会使服务卡顿
如何通过Redis实现分布式锁
分布式锁需要解决的问题
++互斥性
++安全性
++死锁
++容错
**
SETNX Key value:如果key不存在，则创建并赋值
++时间复杂度：O(1)
++返回值：设置成功，返回1；设置失败，返回0
**
大量的key同时过期的注意事项
集中过期，由于清除大量的key很耗时，会出现短暂的卡顿现象
++解决方案：在设置key的过期时间的时候，给每个key加上随机值
使用List作为队列，RPUSH生产消息，LPOP消费消息
++缺点：没有等待队列里有值就直接消费
++弥补：可以通过在应用层引入Sleep机制去调用LPOP重试
**BLPOP key [Key…] timeout :阻塞直到队列有消息或者超时
++缺点：只能提供一个消费者消费**
Pub/sub:主题订阅者模式
++发送者（pub)发送消息，订阅者（sub)接受消息
++订阅者可以订阅任意数量的频道
Redis如何做持久化
RDB(快照）持久化：保存某个时间点的全量数据快照
++SAVE:阻塞Redis的服务器进程，直到RDB文件被创建完毕
++BGSAVE:Fork出一个子进程来创建RDB文件，不阻塞服务器进程
自动化触发RDB持久化的方式
RDB持久化缺点：
++内存数据的全量同步，数据量大会由于I/O而严重影响性能
++可能会因为Redis挂掉而丢失从当前至最近一次快照期间的数据
