产品：直播送礼延迟这么大，你就不能快点吗

先赞后看，南哥助你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);}
}