登录
首页 >  数据库 >  MySQL

Redis应用实战 - 秒杀场景（Node.js版本）

来源：SegmentFault

时间：2023-01-13 11:16:55 155浏览 收藏

有志者，事竟成！如果你在学习数据库，那么本文《Redis应用实战 - 秒杀场景（Node.js版本）》，就很适合你！文章讲解的知识点主要包括MySQL、分布式、Redis、Node.js、秒杀，若是你对本文感兴趣，或者是想搞懂其中某个知识点，就请你继续往下看吧~

写在前面

公司随着业务量的增加，最近用时几个月时间在项目中全面接入

CREATE TABLE `seckill_goods` (
    `id` INTEGER NOT NULL auto_increment,
    `fk_good_id` INTEGER,
    `amount` INTEGER,
    `start_time` DATETIME,
    `end_time` DATETIME,
    `is_valid` TINYINT ( 1 ),
    `comment` VARCHAR ( 255 ),
    `created_at` DATETIME NOT NULL,
    `updated_at` DATETIME NOT NULL,
PRIMARY KEY ( `id` ) 
) ENGINE = INNODB DEFAULT CHARSET = utf8mb4;

CREATE TABLE `orders` (
    `id` INTEGER NOT NULL auto_increment,
    `order_no` VARCHAR ( 255 ),
    `good_id` INTEGER,
    `user_id` INTEGER,
    `status` ENUM ( '-1', '0', '1', '2' ),
    `order_type` ENUM ( '1', '2' ),
    `scekill_id` INTEGER,
    `comment` VARCHAR ( 255 ),
    `created_at` DATETIME NOT NULL,
    `updated_at` DATETIME NOT NULL,
PRIMARY KEY ( `id` ) 
) ENGINE = INNODB DEFAULT CHARSET = utf8mb4;

CREATE TABLE `goods` (
    `id` INTEGER NOT NULL auto_increment,
    `name` VARCHAR ( 255 ),
    `thumbnail` VARCHAR ( 255 ),
    `price` INTEGER,
    `status` TINYINT ( 1 ),
    `stock` INTEGER,
    `stock_left` INTEGER,
    `description` VARCHAR ( 255 ),
    `comment` VARCHAR ( 255 ),
    `created_at` DATETIME NOT NULL,
    `updated_at` DATETIME NOT NULL,
PRIMARY KEY ( `id` ) 
) ENGINE = INNODB DEFAULT CHARSET = utf8mb4;

产品表在此次业务中不是重点，以下逻辑都以

INSERT INTO `redis_app`.`seckill_goods` (
    `id`,
    `fk_good_id`,
    `amount`,
    `start_time`,
    `end_time`,
    `is_valid`,
    `comment`,
    `created_at`,
    `updated_at` 
)
VALUES
    (
        1,
        1,
        200,
        '2020-06-20 00:00:00',
        '2023-06-20 00:00:00',
        1,
        '...',
        '2020-06-20 00:00:00',
        '2021-06-22 10:18:16' 
    );

秒杀接口开发

首先，说一下

// 引入moment库处理时间相关数据
const moment = require('moment');
// 引入数据库model文件
const seckillModel = require('../../dbs/mysql/models/seckill_goods');
const ordersModel = require('../../dbs/mysql/models/orders');
// 引入工具函数或工具类
const UserModule = require('../modules/user');
const { random_String } = require('../../utils/tools/funcs');

class Seckill {
  /**
   * 秒杀接口
   * 
   * @method post
   * @param good_id 产品id
   * @param accessToken 用户Token
   * @param path 秒杀完成后跳转路径
   */
  async doSeckill(ctx, next) {
    const body = ctx.request.body;
    const accessToken = ctx.query.accessToken;
    const path = body.path;

    // 基本参数校验
    if (!accessToken || !path) { return ctx.throwException(20001, '参数错误！'); };
    // 判断此产品是否加入了抢购
    const seckill = await seckillModel.findOne({
      where: {
        fk_good_id: ctx.params.good_id,
      }
    });
    if (!seckill) { return ctx.throwException(30002, '该产品并未有抢购活动！'); };
    // 判断是否有效
    if (!seckill.is_valid) { return ctx.throwException(30003, '该活动已结束！'); };
    // 判单是否开始、结束
    if(moment().isBefore(moment(seckill.start_time))) {
      return ctx.throwException(30004, '该抢购活动还未开始！');
    }
    if(moment().isAfter(moment(seckill.end_time))) {
      return ctx.throwException(30005, '该抢购活动已经结束！');
    }
    // 判断是否卖完
    if(seckill.amount

至此，秒杀接口用传统的关系型数据库就实现完成了，代码并不复杂，注释也很详细，不用特别的讲解大家也都能看懂，那它能不能正常工作呢，答案显然是否定的
通过

{
    amount: 200,
    start_time: '2020-06-20 00:00:00',
    end_time: '2023-06-20 00:00:00',
    is_valid: 1,
    comment: '...',
  }

其次，创建

if (redis.call('hexists', KEYS[1], KEYS[2]) == 1) then
  local stock = tonumber(redis.call('hget', KEYS[1], KEYS[2]));
  if (stock > 0) then
    redis.call('hincrby',  KEYS[1], KEYS[2], -1);
    return stock
  end;
  return 0
end;

最后，完成代码，完整代码如下：

// 引入相关库
const moment = require('moment');
const Op = require('sequelize').Op;
const { v4: uuidv4 } = require('uuid');
// 引入数据库model文件
const seckillModel = require('../../dbs/mysql/models/seckill_goods');
const ordersModel = require('../../dbs/mysql/models/orders');
// 引入Redis实例
const redis = require('../../dbs/redis');
// 引入工具函数或工具类
const UserModule = require('../modules/user');
const { randomString, checkObjNull } = require('../../utils/tools/funcs');
// 引入秒杀key前缀
const { SECKILL_GOOD, LOCK_KEY } = require('../../utils/constants/redis-prefixs');
// 引入避免超卖lua脚本
const { stock, lock, unlock } = require('../../utils/scripts');

class Seckill {
  async doSeckill(ctx, next) {
    const body = ctx.request.body;
    const goodId = ctx.params.good_id;
    const accessToken = ctx.query.accessToken;
    const path = body.path;

    // 基本参数校验
    if (!accessToken || !path) { return ctx.throwException(20001, '参数错误！'); };
    // 判断此产品是否加入了抢购
    const key = `${SECKILL_GOOD}${goodId}`;
    const seckill = await redis.hgetall(key);
    if (!checkObjNull(seckill)) { return ctx.throwException(30002, '该产品并未有抢购活动！'); };
    // 判断是否有效
    if (!seckill.is_valid) { return ctx.throwException(30003, '该活动已结束！'); };
    // 判单是否开始、结束
    if(moment().isBefore(moment(seckill.start_time))) {
      return ctx.throwException(30004, '该抢购活动还未开始！');
    }
    if(moment().isAfter(moment(seckill.end_time))) {
      return ctx.throwException(30005, '该抢购活动已经结束！');
    }
    // 判断是否卖完
    if(seckill.amount

这里代码主要做个四个修改：

  1. 步骤2，判断产品是否加入了抢购，改为去
    Redis
    中查询
  2. 步骤7，判断登录用户是否已抢到，因为不在维护抢购活动
    id
    ，所以改为使用用户
    id
    、产品
    id
    和状态
    status
    判断
  3. 步骤8，扣库存，改为使用
    lua
    脚本去
    Redis
    中扣库存
  4. 对扣库存和写入数据库操作进行加锁

订单的操作仍然在

Mysql
数据库中进行，因为大部分的请求都在步骤5被拦截了，剩余请求
Mysql
是完全有能力处理的。

再次通过

Jmeter
进行测试，发现订单表正常，库存量扣减正常，说明超卖问题和限购已经解决。

其他问题

  1. 秒杀场景的其他技术
    基于

    Redis
    支持高并发、键值对型数据库和支持原子操作等特点，案例中使用
    Redis
    来作为秒杀应对方案。在更复杂的秒杀场景下，除了使用
    Redis
    外，在必要的的情况下还需要用到其他一些技术：
    • 限流，用漏斗算法、令牌桶算法等进行限流
    • 缓存，把热点数据缓存到内存里，尽可能缓解数据库访问的压力
    • 削峰，使用消息队列和缓存技术使瞬间高流量转变成一段时间的平稳流量，比如客户抢购成功后，立即返回响应，然后通过消息队列异步处理后续步骤，发短信，写日志，更新一致性低的数据库等等
    • 异步，假设商家创建一个只针对粉丝的秒杀活动，如果商家的粉丝比较少（假设小于1000），那么秒杀活动直接推送给所有粉丝，如果用户粉丝比较多，程序立刻推送给排名前1000的用户，其余用户采用消息队列延迟推送。（1000这个数字需要根据具体情况决定，比如粉丝数2000以内的商家占99%，只有1%的用户粉丝超过2000，那么这个值就应该设置为2000）
    • 分流，单台服务器不行就上集群，通过负载均衡共同去处理请求，分散压力

    这些技术的应用会让整个秒杀系统更加完善，但是核心技术还是

    Redis
    ，可以说用好
    Redis
    实现的秒杀系统就足以应对大部分场景。

  2. Redis
    健壮性
    案例使用的是单机版
    Redis
    ，单节点在生产环境基本上不会使用，因为
    • 不能达到高可用
    • 即便有着
      AOF
      日志和
      RDB
      快照的解决方案以保证数据不丢失，但都只能放在
      master
      上，一旦机器故障，服务就无法运行，而且即便采取了相应措施仍不可避免的会造成数据丢失。

    因此，

    Redis
    的主从机制和集群机制在生产环境下是必须的。

  3. Redis
    分布式锁的问题
    • 单点分布式锁，案例提到的分布式锁，实际上更准确的说法是单点分布式锁，是为了方便演示，但是，单点
      Redis
      分布式锁是肯定不能用在生产环境的，理由跟第2点类似
    • 以主从机制（多机器）为基础的分布式锁，也是不够的，因为
      redis
      在进行主从复制时是异步完成的，比如在
      clientA
      获取锁后，主
      redis
      复制数据到从
      redis
      过程中崩溃了，导致锁没有复制到从
      redis
      中，然后从
      redis
      选举出一个升级为主
      redis
      ，造成新的主
      redis
      没有
      clientA
      设置的锁，这时
      clientB
      尝试获取锁，并且能够成功获取锁，导致互斥失效。

    针对以上问题，

    redis
    官方设计了
    Redlock
    ，在
    Node.js
    环境下对应的资源库为
    node-redlock
    ，可以用
    npm
    安装，至少需要3个独立的服务器或集群才能使用，提供了非常高的容错率，在生产环境中应该优先采用此方案部署。

总结

秒杀场景的特点可以总结为瞬时并发访问、读多写少、限时和限量，开发中还要考虑避免超卖现象以及类似黄牛抢票的限购问题，针对以上特点和问题，分析得到开发的原则是：数据写入内存而不是写入硬盘，异步处理而不是同步处理，扣库存操作原子执行以及对单用户购买进行加锁，而

Redis
正好是符合以上全部特点的工具，因此最终选择
Redis
来解决问题。

秒杀场景是一个在电商业务中相对复杂的场景，此篇文章只是介绍了其中最核心的逻辑，实际业务可能更加复杂，但只需要在此核心基础上进行扩展和优化即可。
秒杀场景的解决方案不仅仅适合秒杀，类似的还有抢红包、抢优惠券以及抢票等等，思路都是一致的。
解决方案的思路还可以应用在单独限购、第二件半价以及控制库存等等诸多场景，大家要灵活运用。

项目地址

https://github.com/threerocks/redis-seckill

参考资料

https://time.geekbang.org/column/article/307421
https://redis.io/topics/distlock

以上就是《Redis应用实战 - 秒杀场景（Node.js版本）》的详细内容，更多关于mysql的资料请关注golang学习网公众号！

mysql MySQL 分布式 Redis Node.js 秒杀
声明：本文转载于：SegmentFault 如有侵犯，请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>
评论列表