项目没亮点?那就来学下pk功能设计吧

简介: 它的流程是这样,主播点击申请pk按钮,匹配其他同时申请pk的主播,粉丝通过送礼给心爱的主播提高pk进度条,pk结束后失败的一方主播接受惩罚。但进度条数据主要是提供给在pk开始后才进来直播间的观众,这类人进行直播间后,客户端调用pk进度的查询接口,获取最新的pk进度条。每场pk都有倒计时,这里我们在pk匹配成功时就在Redis里设置一个倒计时键值对,该键值对的初始值是本场pk的总pk时间。,我们给他设计为WebSocket数据实时推送,只要主播的进度有增加,把增加的数值推送到所有在pk直播间的用户。

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

麻省理工学院开源的Redis adapter适配器,可以将事件广播到多个单独的 socket.io 服务器节点。这一点和下文精彩的内容相关。

在这里插入图片描述

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

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

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

1. 直播pk功能设计

1.1 pk玩法

直播pk的功能,要设计出来看起来容易,实则一点都不简单。直播pk玩法在抖音、虎牙、斗鱼各大平台都有出现,能帮互联网公司、主播赚不少钱。

南哥先说说pk的玩法是如何如何?它的流程是这样,主播点击申请pk按钮,匹配其他同时申请pk的主播,粉丝通过送礼给心爱的主播提高pk进度条,pk结束后失败的一方主播接受惩罚。但惩罚又有何妨呢,失败的主播也赚到收益了。

看看直播pk的大概界面。

在这里插入图片描述

1.2 pk进度条

pk进度条数据我们打算存储到高性能内存数据库Redis,这里使用Redis的Map结构,存储两个pk主播的进度条数据。

# Map的k-v结构
pk:progress:pk_id = [{主播A : 100}, {主播B : 90}]

但进度条数据主要是提供给在pk开始后才进来直播间的观众,这类人进行直播间后,客户端调用pk进度的查询接口,获取最新的pk进度条。

// 查询pk进度条接口
public Map<Object, Object> getPKProgress(String pkId) {
   
    String pkProgressKey = "pk:progress:" + pkId;
    return redisTemplate.opsForHash().entries(pkProgressKey);
}

而处于直播间的用户的进度条增加,我们给他设计为WebSocket数据实时推送,只要主播的进度有增加,把增加的数值推送到所有在pk直播间的用户。

但有个问题,如果刚进来的观众第一次进来直播间后,他获取了最新的pk进度。此时刚好某个主播的pk进度增加,但由于是新进来的观众,WebSocket数据推送不到这个最新用户,怎么办

这涉及到数据一致性的问题!我们可以在用户进入直播间后,每隔一段时间调用以上的接口,获取pk最新进度条,进行数据纠正

同时,在pk结束后,仍然要调用一次查询接口,确保不会出现这个情况:欸,主播你的分数明明比她高,怎么输了呢?这个情况还是数据不一致的问题。

1.3 pk匹配

主播点击pk申请按钮,我们把主播id与直播间信息加入到pk匹配池。

这个pk池子我们依然利用Redis,采用Redis五大基本数据类型之一:Zset。Zset的元素存储主播id与直播间id,元素的score存储主播的pk积分。那Zset会根据主播的积分进行顺序排序。

后面就是匹配算法的设计了,通过匹配算法 + Zset主播的积分,挑选出积分相近的两个pk主播进行匹配。

# Zset结构:
pk:matching_pool = [{anchor_id_1_room_id_1 : 100}, {anchor_id_2_room_id_2 : 110}]

南哥上面这几个关键数据结构都存储在Redis,我们要保证Redis的高可用性。那用Redis集群可以吗?

如果采用这种Redis架构,因为Redis集群把键值分为16384个槽给到各个集群节点,建议给集群里每个节点配上从节点,即集群架构搭配主从模型。防止某个集群节点失效了导致数据全部丢失。

1.4 pk倒计时

每场pk都有倒计时,这里我们在pk匹配成功时就在Redis里设置一个倒计时键值对,该键值对的初始值是本场pk的总pk时间。

// 设置pk倒计时
public void setPKCountdown(String pkId, int totalTime) {
   
    String pkCountdownKey = "pk:countdown:" + pkId;

    // 在 Redis 中设置倒计时
    redisTemplate.opsForValue().set(pkCountdownKey, totalTime, totalTime, TimeUnit.SECONDS);
}

1.5 pk流程设计

总结上文,清晰地梳理下整个pk流程的设计。

主播发送pk申请 -> 匹配 -> 成功则WebSockett推送成功通知、倒计时信息 -> 创建监控线程 -> pk中 -> pk结算

首先两个主播在客户端点击pk申请按钮,申请请求到达后端,客户端告知主播:pk匹配中

主播申请后,后端服务把主播加入pk匹配池。而专门用于配对pk主播的微服务持续处理pk池子中请求,合适则把两个主播进行pk配对,同时把两个主播踢出pk匹配池。

当然匹配成功后还有后续流程需要处理,配对成功后使用WebSocket服务端主动推送技术,实时告知主播包括直播间用户:pk已配对成功。

同时,在Redis创建上文1.3节的pk倒计时,同步也推送给主播包括观众。

在后台,我们还需要创建一个监控线程,来去监控pk是否结束,当结束时进行pk结算,告知观众与主播究竟哪一方获胜。

监控线程取自监控线程池子,方便线程复用,线程池的最大好处就是减少了系统频繁创建、销毁线程带来的资源消耗。

// 从监控线程池获取一个线程
public void monitorPKProgress(String pkId) {
   
    ScheduledExecutorService scheduler = Executors.newScheduledThreadPool(10);

    scheduler.scheduleAtFixedRate(() -> {
   
        // 检查倒计时是否结束
        String countdownKey = "pk:countdown:" + pkId;
        Integer countdown = (Integer) redisTemplate.opsForValue().get(countdownKey);
        if (countdown != null && countdown <= 0) {
   
            System.out.println("PK结束,开始结算...");
            // 调用结算逻辑
        }
    }, 0, 1, TimeUnit.SECONDS);  // 每秒监控一次
}

1.6 WebSocket长连接问题

pk匹配成功通知、pk进度条增加等,都需要WebSocket技术去实时推送数据。

但一个直播间成千上万个观众,大多数观众的客户端都长连接着不同的WebSocket服务器。要推送数据时,怎么知道要从哪些WebSocket服务器进行推送??

(1)集中式连接状态管理

有一些公司WebSocket服务器只有固定一台,推送数据时绑定这台服务器的ip即可,也不需要处理我们讨论的问题。

我们把用户的连接信息,包括用户id、长连接的WebSocket服务器地址,都存储在Redis中进行集中式的状态管理。当要推送数据时,获取用户所在WebSocket服务器地址即可。

(2)广播推送

进行数据推送时,对所有WebSocket服务器进行消息广播。接收到广播消息后,服务器检查本地是否有该用户的连接信息,如果有则进行消息推送。

(3)WebSocket集群框架

如果WebSocket框架使用的是Socket.IO的话,以上的问题已经有很好的集群解决方案了。Socket.IO Redis adapter适配器可以将事件广播到多个单独的 socket.io 服务器节点,用于在多台WebSocket服务器共享连接状态。

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

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

在这里插入图片描述

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

相关文章
|
5月前
|
JavaScript Java 测试技术
基于SpringBoot+Vue+uniapp的成都奥科厨具厂产品在线销售系统的详细设计和实现(源码+lw+部署文档+讲解等)
基于SpringBoot+Vue+uniapp的成都奥科厨具厂产品在线销售系统的详细设计和实现(源码+lw+部署文档+讲解等)
50 6
|
5月前
|
开发框架 缓存 监控
美丽天天秒丨链动2+1模式系统开发规则流程/功能设计/需求方案/成熟案例/源码指南
开发美丽天天秒丨链动2+1系统的流程可以按照以下步骤进行:
|
5月前
|
算法 安全 数据安全/隐私保护
一对一语音视频交友系统开发详细指南丨案例设计丨功能需求丨方案逻辑丨项目流程丨源码教程
一对一语音视频交友系统开发指的是开发一种用于让用户通过语音和视频进行一对一交流的交友系统。该系统旨在提供一个平台,让用户可以通过语音和视频相互了解、交流和建立关系。以下是一对一语音视频交友系统开发的一些关键特点:
|
7月前
|
移动开发 供应链 前端开发
基于jeecgboot的ERP部分演示功能发布
基于jeecgboot的ERP部分演示功能发布
132 0
|
7月前
|
安全
短剧系统开发详细指南/步骤流程/功能需求/案例源码
Short film system development refers to the system developed for the production and display of short films. A short drama usually refers to a film completed in a relatively short period of time, usually between a few minutes and half an hour, and is an independent form of film and television work. I
|
7月前
|
设计模式 监控 架构师
如何在项目中考虑非功能需求
软件非功能需求包括性能、可靠性、安全性、易用性、可维护性、可移植性、兼容性、可重用性、可扩展性和可观察性。质量属性分为开发期和运行期,如易理解性、可扩展性、可测试性等是开发期质量,性能、安全性、易用性等是运行期质量。评估方法有ATAM(架构评估技术)、ADMEMS矩阵方法、SAAM(软件架构分析法)和CBAM(成本效益分析法)。ATAM包括建立评估小组、获取架构信息、风险承担者观点和形成最终报告四个阶段。
288 0
|
敏捷开发 测试技术
推三返一开发稳定版丨推三返一项目系统开发详细指南/方案需求/步骤逻辑/流程功能/案例设计/技术架构/源码程序
推三返一系统开发是一种软件开发模式,也被称为迭代增量开发模式。它是一种敏捷开发方法的一种,通过将整个开发过程分为多个迭代周期,每个周期都会增加新的功能和特性,并在每个迭代周期结束后进行测试、反馈和修改。推三返一系统开发的核心思想是“推进三步,反馈一步”。
|
运维 测试技术 区块链
链动2+1模式系统开发指南流程丨成熟案例丨功能设计丨测试部署丨方案项目丨逻辑需求丨源码出售
链动2+1模式系统开发方案是指一个较为复杂的系统开发模式,其中包含两个公链和一个私链的组合。
|
安全
交易所开发正式版丨交易所系统开发详细指南/案例开发/功能需求/方案逻辑/项目设计/源码程序
Business requirement analysis: A detailed understanding of the business requirements of the exchange, including supported transaction types, transaction pair settings, fee mechanisms, user management, etc., to ensure that the development is in line with actual needs.
|
新零售 人工智能 大数据
旅游系统开发(APP开发案例)/功能介绍/案例分析/项目方案/源码平台
新零售是指个人、企业以互联网为依托,通过运用大数据、人工智能等先进技术手段并运用心理学知识,A new retail model that upgrades and transforms the production,circulation,and sales processes of goods,reshapes the business structure and ecosystem,and deeply integrates online services,offline experiences,and modern logistics

热门文章

最新文章