共计 5480 个字符，预计需要花费 14 分钟才能阅读完成。
这篇文章给大家分享的是有关 Redis 瞬时高并发秒杀的示例分析的内容。丸趣 TV 小编觉得挺实用的，因此分享给大家做个参考，一起跟随丸趣 TV 小编过来看看吧。
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 能通过接口其他 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 数据到数据库，秒杀正式结束。
感谢各位的阅读！关于“Redis 瞬时高并发秒杀的示例分析”这篇文章就分享到这里了，希望以上内容可以对大家有一定的帮助，让大家可以学到更多知识，如果觉得文章不错，可以把它分享出去让更多的人看到吧！
