瞬时高并发（秒杀/活动）Redis方案

1、Redis

丰富的数据结构（Data Structures）

字符串（String）

Redis字符串能包含任意类型的数据

一个字符串类型的值最多能存储512M字节的内容

利用INCR命令簇（INCR, DECR, INCRBY）来把字符串看成原子计数器使用

使用APPEND命令在字符串后添加内容

列表（List）

Redis列表是简单的字符串列表，按照插入顺序排序

你能够添加一个元素到列表的头部（左边：LPUSH）或者尾部（右边：RPUSH）

一个列表最多能够包含232-1个元素（4294967295，每一个表超过40亿个元素）

在社交网络中创建一个时间线模型，使用LPUSH去添加新的元素到用户时间线中，使用LRANGE去检索一些最近插入的条目

你能够同时使用LPUSH和LTRIM去建立一个永远不会超过指定元素数目的列表并同时记住最后的N个元素

列表能够用来看成消息传递的基元（primitive），例如，众所周知的用来建立后台任务的Resque Ruby库

集合（Set）

Redis集合是一个无序的，不容许相同成员存在的字符串合集（Uniq操做，获取某段时间全部数据排重值）

支持一些服务端的命令从现有的集合出发去进行集合运算，如合并（并集：union）,求交(交集：intersection)，差集, 找出不一样元素的操做（共同好友、二度好友）

用集合跟踪一个独特的事。想要知道全部访问某个博客文章的独立IP？只要每次都用SADD来处理一个页面访问。那么你能够确定重复的IP是不会插入的（ 利用惟一性，能够统计访问网站的全部独立IP）

Redis集合能很好的表示关系。你能够建立一个tagging系统，而后用集合来表明单个tag。接下来你能够用SADD命令把全部拥有tag的对象的全部ID添加进集合，这样来表示这个特定的tag。若是你想要同时有3个不一样tag的全部对象的全部ID，那么你须要使用SINTER

使用SPOP或者SRANDMEMBER命令随机地获取元素

哈希（Hashes）

Redis Hashes是字符串字段和字符串值之间的映射

尽管Hashes主要用来表示对象，但它们也可以存储许多元素

有序集合（Sorted Sets）

Redis有序集合和Redis集合相似，是不包含相同字符串的合集

每一个有序集合的成员都关联着一个评分，这个评分用于把有序集合中的成员按最低分到最高分排列（排行榜应用，取TOP N操做）

使用有序集合，你能够很是快地（O(log(N))）完成添加，删除和更新元素的操做

元素是在插入时就排好序的，因此很快地经过评分(score)或者位次(position)得到一个范围的元素（须要精准设定过时时间的应用）

轻易地访问任何你须要的东西: 有序的元素，快速的存在性测试，快速访问集合中间元素

在一个巨型在线游戏中创建一个排行榜，每当有新的记录产生时，使用ZADD 来更新它。你能够用ZRANGE轻松地获取排名靠前的用户， 你也能够提供一个用户名，而后用ZRANK获取他在排行榜中的名次。 同时使用ZRANK和ZRANGE你能够得到与指定用户有相同分数的用户名单。 全部这些操做都很是迅速

有序集合一般用来索引存储在Redis中的数据。 例如：若是你有不少的hash来表示用户，那么你可使用一个有序集合，这个集合的年龄字段用来看成评分，用户ID看成值。用ZRANGEBYSCORE能够简单快速地检索到给定年龄段的全部用户

复制（Replication, Redis复制很简单易用，它经过配置容许slave Redis Servers或者Master Servers的复制品）

一个Master能够有多个Slaves

Slaves能经过接口其余slave的连接，除了能够接受同一个master下面slaves的连接之外，还能够接受同一个结构图中的其余slaves的连接

redis复制是在master段是非阻塞的，这就意味着master在同一个或多个slave端执行同步的时候还能够接受查询

复制在slave端也是非阻塞的，假设你在redis.conf中配置redis这个功能，当slave在执行的新的同步时，它仍能够用旧的数据信息来提供查询，不然，你能够配置当redis slaves去master失去联系是，slave会给发送一个客户端错误

为了有多个slaves能够作只读查询，复制能够重复2次，甚至屡次，具备可扩展性（例如：slaves对话与重复的排序操做，有多份数据冗余就相对简单了）

他能够利用复制去避免在master端保存数据，只要对master端redis.conf进行配置，就能够避免保存（全部的保存操做），而后经过slave的连接，来实时的保存在slave端

LRU过时处理（Eviction）

EVAL 和 EVALSHA 命令是从 Redis 2.6.0 版本开始的，使用内置的 Lua 解释器，能够对 Lua 脚本进行求值

Redis 使用单个 Lua 解释器去运行全部脚本，而且， Redis 也保证脚本会以原子性(atomic)的方式执行： 当某个脚本正在运行的时候，不会有其余脚本或 Redis 命令被执行。 这和使用 MULTI / EXEC 包围的事务很相似。 在其余别的客户端看来，脚本的效果(effect)要么是不可见的(not visible)，要么就是已完成的(already completed)

LRU过时处理（Eviction）

Redis容许为每个key设置不一样的过时时间，当它们到期时将自动从服务器上删除（EXPIRE）

事务

MULTI 、 EXEC 、 DISCARD 和 WATCH 是 Redis 事务的基础

事务是一个单独的隔离操做：事务中的全部命令都会序列化、按顺序地执行。事务在执行的过程当中，不会被其余客户端发送来的命令请求所打断

事务中的命令要么所有被执行，要么所有都不执行，EXEC 命令负责触发并执行事务中的全部命令 

Redis 的 Transactions 提供的并非严格的 ACID 的事务

Transactions 仍是提供了基本的命令打包执行的功能： 能够保证一连串的命令是顺序在一块儿执行的，中间有会有其它客户端命令插进来执行

Redis 还提供了一个 Watch 功能，你能够对一个 key 进行 Watch，而后再执行 Transactions，在这过程当中，若是这个 Watched 的值进行了修改，那么这个 Transactions 会发现并拒绝执行

数据持久化

RDB

特色

RDB持久化方式可以在指定的时间间隔能对你的数据进行快照存储

优势

RDB是一个很是紧凑的文件,它保存了某个时间点得数据集,很是适用于数据集的备份

RDB是一个紧凑的单一文件, 很是适用于灾难恢复

RDB在保存RDB文件时父进程惟一须要作的就是fork出一个子进程,接下来的工做所有由子进程来作，父进程不须要再作其余IO操做，因此RDB持久化方式能够最大化redis的性能

与AOF相比,在恢复大的数据集的时候，RDB方式会更快一些

缺点

若是你但愿在redis意外中止工做（例如电源中断）的状况下丢失的数据最少的话，那么RDB不适合，Redis要完整的保存整个数据集是一个比较繁重的工做

RDB 须要常常fork子进程来保存数据集到硬盘上,当数据集比较大的时候,fork的过程是很是耗时的,可能会致使Redis在一些毫秒级内不能响应客户端的请求.若是数据集巨大而且CPU性能不是很好的状况下,这种状况会持续1秒,AOF也须要fork,可是你能够调节重写日志文件的频率来提升数据集的耐久度

AOF

特色

AOF持久化方式记录每次对服务器写的操做

redis重启的时候会优先载入AOF文件来恢复原始的数据,由于在一般状况下AOF文件保存的数据集要比RDB文件保存的数据集要完整

优势

使用AOF 会让你的Redis更加耐久: 你可使用不一样的fsync策略：无fsync,每秒fsync,每次写的时候fsync

AOF文件是一个只进行追加的日志文件,因此不须要写入seek

Redis 能够在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写

AOF 文件有序地保存了对数据库执行的全部写入操做， 这些写入操做以 Redis 协议的格式保存， 所以 AOF 文件的内容很是容易被人读懂， 对文件进行分析（parse）也很轻松。 导出（export） AOF 文件也很是简单

缺点

对于相同的数据集来讲，AOF 文件的体积一般要大于 RDB 文件的体积

根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB

选择

同时使用两种持久化功能

分布式

Redis Cluster （Redis 3版本）

Keepalived

当Master挂了后，VIP漂移到Slave；Slave 上keepalived 通知redis 执行：slaveof no one ,开始提供业务

当Master起来后，VIP 地址不变，Master的keepalived 通知redis 执行slaveof slave IP host ，开始做为从同步数据

依次类推

Twemproxy

快、轻量级、减小后端Cache Server链接数、易配置、支持ketama、modula、random、经常使用hash 分片算法

对于客户端而言，redis集群是透明的，客户端简单，遍于动态扩容

Proxy为单点、处理一致性hash时，集群节点可用性检测不存在脑裂问题

高性能，CPU密集型，而redis节点集群多CPU资源冗余，可部署在redis节点集群上，不须要额外设备

高可用（HA）

Redis Sentinel（redis自带的集群管理工具 ）

监控（Monitoring）： Redis Sentinel实时监控主服务器和从服务器运行状态

提醒（Notification）：当被监控的某个 Redis 服务器出现问题时， Redis Sentinel 能够向系统管理员发送通知， 也能够经过 API 向其余程序发送通知

自动故障转移（Automatic failover）： 当一个主服务器不能正常工做时，Redis Sentinel 能够将一个从服务器升级为主服务器， 并对其余从服务器进行配置，让它们使用新的主服务器。当应用程序链接到 Redis 服务器时， Redis Sentinel会告之新的主服务器地址和端口

单M-S结构

单M-S结构特色是在Master服务器中配置Master Redis（Redis-1M）和Master Sentinel（Sentinel-1M）

Slave服务器中配置Slave Redis（Redis-1S）和Slave Sentinel（Sentinel-1S）

其中 Master Redis能够提供读写服务，可是Slave Redis只能提供只读服务。所以，在业务压力比较大的状况下，能够选择将只读业务放在Slave Redis中进行

双M-S结构

双M-S结构的特色是在每台服务器上配置一个Master Redis，同时部署一个Slave Redis。由两个Redis Sentinel同时对4个Redis进行监控。两个Master Redis能够同时对应用程序提供读写服务，即使其中一个服务器出现故障，另外一个服务器也能够同时运行两个Master Redis提供读写服务

缺点是两个Master redis之间没法实现数据共享，不适合存在大量用户数据关联的应用使用

单M-S结构和双M-S结构比较

单M-S结构适用于不一样用户数据存在关联，但应用能够实现读写分离的业务模式。Master主要提供写操做，Slave主要提供读操做，充分利用硬件资源

双（多）M-S结构适用于用户间不存在或者存在较少的数据关联的业务模式，读写效率是单M-S的两（多）倍，但要求故障时单台服务器可以承担两个Mater Redis的资源需求

发布/订阅（Pub/Sub）

监控：Redis-Monitor

历史redis运行查询：CPU、内存、命中率、请求量、主从切换等

实时监控曲线

2、数据类型Redis使用场景

String

 计数器应用

List

取最新N个数据的操做

消息队列

删除与过滤

实时分析正在发生的状况，用于数据统计与防止垃圾邮件（结合Set）

Set

Uniqe操做，获取某段时间全部数据排重值

实时系统，反垃圾系统

共同好友、二度好友

利用惟一性，能够统计访问网站的全部独立 IP

好友推荐的时候，根据 tag 求交集，大于某个 threshold 就能够推荐

Hashes

存储、读取、修改用户属性

Sorted Set

排行榜应用，取TOP N操做

须要精准设定过时时间的应用（时间戳做为Score）

带有权重的元素，好比一个游戏的用户得分排行榜

过时项目处理，按照时间排序

3、Redis解决秒杀/抢红包等高并发事务活动

秒杀开始前30分钟把秒杀库存从数据库同步到Redis Sorted Set

用户秒杀库存放入秒杀限制数长度的Sorted Set

秒杀到指定秒杀数后，Sorted Set不在接受秒杀请求，并显示返回标识

秒杀活动彻底结束后，同步Redis数据到数据库，秒杀正式结束