🔥产品:直播送礼延迟这么大,你就不能快点吗

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介: 先赞后看,南哥助你Java进阶一大半其实抖音的实时音视频技术RTC,是来源于火山引擎RTC的支持,抖音、火山引擎、巨量引擎属于字节跳动公司旗下的不同业务板块。我是南哥,一个Java学习与进阶的领路人。相信对你通关面试、拿下Offer进入心心念念的公司有所帮助。

先赞后看,南哥助你Java进阶一大半

其实抖音的实时音视频技术RTC,是来源于火山引擎RTC的支持,抖音、火山引擎、巨量引擎都属于字节旗下不同的业务板块。

在这里插入图片描述

我是南哥,一个Java学习与进阶的领路人。

相信对你通关面试、拿下Offer进入心心念念的公司有所帮助。

⭐⭐⭐本文收录在《Java学习/进阶/面试指南》:https://github/JavaSouth

1. 直播礼物系统设计

1.1 表结构设计

视频直播领域的企业,比如抖音、快手、虎牙直播、B站直播,企业赚钱的源头往往靠的是粉丝在直播间刷礼物。你是不是像南哥一样只刷免费的小心心呢?我看了下抖音的直播间,现在小心心还要充钱才能送!

在这里插入图片描述

赚钱的业务必须要重视起来,这必然不是一个小小模块,而是一个礼物系统设计。

特别用户送礼有个必要的用户需求,用户送礼是为了和主播互动,送了个嘉年华,主播半小时才反应过来,那我们直播平台得被用户喷si。这就要求直播送礼的实时性了,虽然送礼内部包含了众多逻辑,看起来不可能快。

先看看下礼物系统的表设计。

(1)礼物表

CREATE TABLE `gifts` (
  `gift_id` INT AUTO_INCREMENT PRIMARY KEY,
  `gift_name` VARCHAR(255) NOT NULL,
  `cost` INT NOT NULL,
  `image_url` VARCHAR(255)
);

(2)用户礼物库存表

CREATE TABLE `user_gifts` (
  `user_gift_id` INT AUTO_INCREMENT PRIMARY KEY,
  `user_id` INT NOT NULL,
  `gift_id` INT NOT NULL,
  `quantity` INT DEFAULT 1,
  `acquired_date` TIMESTAMP DEFAULT CURRENT_TIMESTAMP COMMENT '获得礼物日期'
);

(3)礼物消费记录表

CREATE TABLE `gift_consumption_records` (
  `record_id` INT AUTO_INCREMENT PRIMARY KEY,
  `user_id` INT NOT NULL,
  `gift_id` INT NOT NULL,
  `anchor_id` INT NOT NULL COMMENT '主播id',
  `quantity` INT NOT NULL,
  `consumed_at` TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

1.2 送礼流程设计

简单来看,一次送礼请求需要经过的步骤可以简化为:

用户送礼 -> 礼物校验、资产校验 -> 用户扣费 -> 直播间礼物通知 -> 更新礼物排行榜、记录消费日志。

上文我有说了送礼要快/准/恨,这么长的业务链条,实时性要怎么保障?

(1)校验接口

用户点击送礼,App端先调用校验接口,校验用户的余额是否充足。这一点很重要,余额不够的则不走下面的流程,减少了大量无效的送礼请求。

// 校验接口
public boolean validateGiftAndBalance(int userId, int giftId, int quantity) {
   
    // 查询用户余额
    int userBalance = getUserBalance(userId);
    // 查询礼物价格
    int giftCost = getGiftCost(giftId);

    // 校验用户余额是否充足
    if (userBalance < giftCost * quantity) {
   
        return false;
    }
    return true;
}

(2)消息队列

如果余额校验成功,App端将送礼请求发送到后端服务,后端服务把所有送礼请求都统一转发到消息队列Kafka上,同时返回成功给客户端,但客户端仍然不进行礼物展示。

通过消息队列把送礼请求任务化,大大减少了送礼高峰对服务器资源的冲击。而用户送礼成功后的直播间礼物显示留在下一步中。

(3)异步处理

监听Kafka任务的后端服务会处理送礼请求,完成礼物校验、资产校验后,进行实际的用户扣费。

当扣费成功后,后续的流程还有:直播间礼物通知 -> 更新礼物排行榜、记录消费日志,甚至更多杂七杂八新增的业务逻辑。

但要保障实时性,扣费成功后的后续步骤完全可以异步化,异步进行直播间礼物通知、异步更新礼物排行榜、记录消费日志。

// 异步处理
public void processGiftAsync(int userId, int giftId, int quantity, int anchorId) {
   
    CompletableFuture.runAsync(() -> {
   
        // 直播间礼物通知
        notifyLiveRoom(userId, giftId, quantity, anchorId);
        // 更新礼物排行榜
        updateGiftRanking(userId, giftId, quantity);
        // 记录消费日志
        recordGiftConsumption(userId, giftId, quantity, anchorId);
    });
}

(4)多实例负载均衡

保证处理送礼请求的后端服务资源充足,根据实际送礼流量增加消费实例进行负载均衡。

1.3 直播间礼物通知

欸,用消息队列处理送礼请求,前面在送礼请求接口都返回成功给客户端了,直播间礼物还没有显示出来那什么时候才显示出来?

这里我们用到的技术是服务器主动推送技术,例如现如今很火的WebSocket实时推送。WebSocket的创始人叫Michael Carter,听说现在每天全球有超过 20 亿台设备在使用WebSocket。

Michael designed the initial WebSocket protocol for HTML5, a technology that is used on more than 2 billion devices across the world every day.

推送直播间礼物显示前,我们得先知道推送给谁,直播间所有用户、主播、送礼的粉丝都是推送的对象。

这些在直播间的用户和直播间是一对多的关系,不可能把这个关系存储到MySQL数据库,毕竟我们要快。业界一般把它存储在内存数据库:Redis。

# 用户、直播间是一对多关系的数据结构
live_room_users:room_id : [user_id, user_id]
# 例如
live_room_users:000 : [001, 002, 003]
live_room_users:111 : [004, 005, 005]

知道了推送对象,我们就可以异步进行推送通知。

// WebSocket通知房间里所有用户
public void notifyLiveRoom(int userId, int giftId, int quantity, int roomId) {
   
    // 获取房间中所有用户
    Set<Integer> users = getUsersInLiveRoom(roomId);
    String message = String.format("User %d sent %d of gift %d", userId, quantity, giftId);

    // 推送消息给所有用户
    for (Integer user : users) {
   
        webSocketService.sendMessageToUser(user, message);
    }
}

1.4 送礼连击功能

用户在直播间送礼往往有一个习惯,第一节提到的免费小心心礼物,用户会疯狂连击。一次送礼点击就作为一次送礼请求,很明显对我们的服务器资源很不友好

在客户端设置一个时间窗口,只要用户在时间段内连续点击送礼按钮,客户端统计出点击次数,作为一次送礼请求。

在这里插入图片描述

// 批量送礼接口
public void batchSendGift(int userId, int giftId, int totalQuantity, int roomId, int anchorId) {
   
    // 客户端统计点击次数,作为一次送礼请求
    processGiftAsync(userId, giftId, totalQuantity, anchorId);
}

1.5 事务控制

礼物校验、资产校验、用户扣费,这些涉及资金的业务最好加上严格的事务控制,只要有一丁点出错,所有的操作进行回滚。

// 事务控制
@Transactional
public boolean processGiftTransaction(int userId, int giftId, int quantity, int anchorId) {
   
    try {
   
        // 礼物校验、资产校验
        if (!validateGiftAndBalance(userId, giftId, quantity)) {
   
            return false;
        }
        // 扣费
        deductUserBalance(userId, giftId, quantity);

        // 其他异步业务逻辑
        processGiftAsync(userId, giftId, quantity, anchorId)
        return true;
    } catch (Exception e) {
   
        throw new RuntimeException("Gift processing failed, transaction rolled back", e);
    }
}

戳这,《JavaSouth》作为一份涵盖Java程序员所需掌握核心知识、面试重点的神秘文档。

我是南哥,南就南在Get到你的点赞点赞。

在这里插入图片描述

创作不易,不妨点赞、收藏、关注支持一下,各位的支持就是我创作的最大动力❤️

相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
相关文章
|
2月前
|
API
英雄联盟数据比分直播网定制开发源码
英雄联盟数据比分直播网/APP定制开发源码,需先处理实时与赛果数据。赛果数据通过API接口 `/api/result/lol` 获取,涵盖队伍经济、补刀、大小龙、水晶数及队员经济、经验、等级等详尽信息。支持WebSocket推送与变化信息接口拉取,确保数据完整无漏。
|
存储 前端开发 JavaScript
直播弹幕源码开发很难?一招教你解决
如果你在开发直播弹幕源码的途中碰到很多棘手问题,不要慌,本篇来逐步击破直播弹幕源码的难点。
直播弹幕源码开发很难?一招教你解决
|
7月前
电子厂测试题——难倒众多主播——大司马也才90分
电子厂测试题——难倒众多主播——大司马也才90分
57 0
|
7月前
|
消息中间件 缓存 双11
阿里巴巴如何对抗淘宝双11亿级流量?这本P9纯手打并发手册送给你
淘宝双11,京东618,滴滴打车高峰如何抗住亿级的并发量? 这一份阿里P9纯手打的高并发系统设计手册帮你解决!这份手册分为基础篇、数据库篇、缓存篇、消息队列篇、分布式服务篇、维护篇、实战篇
|
7月前
|
弹性计算 Serverless 程序员
大咖与小白的日常:教你用Serverless每天自动发土味情话
今天介绍如何用Python结合阿里云Serverless函数计算每天定时给男/女朋友发天气预报和情话,让他/她明白程序员也有浪漫。欢迎大家学习。
103 0
|
编解码 缓存 算法
语音陪玩源码如何做到不卡顿?
对于语音通话来说,当延时高于200ms时,就会影响到用户的体验,达到460ms时,就能让对方用户很明显的感知出来,1s以上的延迟在交互式的语音聊天中不被接受,所以在语音陪玩源码开发时,要注意语音连麦技术的延时优化。
语音陪玩源码如何做到不卡顿?
|
缓存 编解码 网络协议
开发直播相亲交友源码,高并发怎么做到不卡顿?
最近几年随着互联网技术的高速发展,人们的生活节奏以及生活方式也在跟着时代进行变化,越来越多人选择了线上交友的方式,通过交友软件把自己的生活圈进行扩大。相亲交友源码作为视频直播系统开发行业的小众源码,也成为社交类APP开发的新宠。 从线上红娘+直播相亲切入的伊对,据小编统计不到近几年的时间就积累了高达四千万用户,近五万名红娘,每月可以撮合近一千万场相亲。通过视频直播相亲方式,让用户更便捷,自由的选择相亲对象,直接观察相亲对象的外表言谈举止,有强烈的感官意识,可以长期持续的进行交流沟通,因此视频直播形态的相亲模式,是目前相亲交友系统开发的新趋势。
开发直播相亲交友源码,高并发怎么做到不卡顿?
|
网络协议 UED CDN
流媒体技术助力,相亲源码实现低延迟直播相亲
直播相亲的延迟和很多因素有关,其中最影响直播延迟的一点,就是音视频传输。相亲源码的音视频传输需要用到流媒体技术,想要优化传输延迟,可以从编码、流媒体协议等方面着手。
|
Web App开发 编解码 移动开发
淘宝超强“带货王”——直播低延迟的背后有何猫腻?
本次演讲来自阿里巴巴淘系技术部技术专家常高伟在 LiveVideoStack 2019深圳站上的演讲,主要面向直播行业从业者,以及对低延迟直播技术、 WebRTC 技术感兴趣的技术人员,介绍淘宝直播在低延迟直播技术上的探索,如何基于 WebRTC 实现一秒内的低延迟直播,以及低延迟直播对电商直播的业务价值。
2573 1
淘宝超强“带货王”——直播低延迟的背后有何猫腻?
|
人工智能 Cloud Native 物联网
不可错过!2020最热的100场技术直播来了
2020年最热门的100场技术直播我们都替你找出来了!
不可错过!2020最热的100场技术直播来了