【总结】瞬时高并发（秒杀/活动）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数据到数据库，秒杀正式结束