Redis常用数据类型，及如何实现分布式锁，持久化，集群主从同步

缓存中间件-----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挂掉而丢失从当前至最近一次快照期间的数据