从0到1千万级直播项目

直播发展历程1.0时代在那个时候，大众接触得最多的平台是YY的语音直播，大概是在08年的时候上线的，那个年代是PC直播平台开始了，而后的几年各大公司也纷纷入局，一时间PC直播大战彻底打响，前期的商业模式主要是走在线音乐/喊麦、秀场方向，靠用户打赏实现营收。2.0时代时间来到2016年，这是不平凡的一年，4G网络开始普及，移动互联网时代正式宣布到来，越来越多人在手机上观看直播，同时这一年所谓的 "千播大战" 正式打响 wangyi yingke、huajiao、momo等众多直播平台入局，掀起了惨烈的移动直播大战，与此同时，某牙、某鱼、long珠等平台在游戏直播赛道展开激烈角...

业务场景需要维护用户的在线状态，在线状态类型：在线、离线、在直播间、在上麦等可以允许非实时更新状态，但误差需要在几分钟内需要考虑用户强杀App，或者强杀后又上线，用户弱网情况下用户状态的切换问题需要考虑大DAU下用户状态频繁切换与维护带来的性能开销,需要做性能优化为什么要用心跳实现？提高系统的可靠性：心跳机制可以检测系统是否正常运行，如果系统出现故障，可以及时发现并采取相应的措施，提高系统的可靠性。降低系统的维护成本：通过心跳机制，可以实时监控系统的运行情况，及时发现故障并解决问题，可以降低系统的维护成本。提高系统的可扩展性：心跳机制可以实现系统的动态扩展，当系统负载过高时，可以自动增加节点，...

说明首先，感谢您抽出宝贵的时间来读我的文章。我知道您的时间很宝贵，而且有很多其他有趣的事情可以做。但是您还是选择了点进来，这让我感到非常欣慰。在我前面的文章中有提到长连接选型，通过各种综合考虑后面我们选了gRpc,如今距离gRpc成功落地并上线已有几个月，在此期间也是遇到了一些坑，也翻遍了很多社区和文档，最终结合自己的一些思考，成功落地了一套gRpc服务端基于Java微服务、分布式、高可用的长连接服务。关于标题请允许我说为什么可能是全网最全实战篇，我并不是标题党，在许多关于gRpc的社区和文章中，多是偏基础使用入门的demo，比较难满足生产环境的使用需要，本文主要针对生产环境落地实践进行阐述，...

【从0-1 千万级直播项目实战】分布式数据库选型 | 你还在分库分表吗？放松时刻这里跟大家讲个段子，以前有个朋友，他在传统软件行业，他时常问我你们互联网就一个App项目，整天迭代来迭代去，还招那么多人去干，有那么多东西做吗？在他眼里可能我们这种互联网App就是上线即巅峰，只要App发布出去了，就没程序员啥事了，当然要是换以前的我，我可能会顿时暴怒并反驳他，但现在作为一个成熟程序员我并不会去反驳，因为我知道跟他讲太多也没有结果，我就笑笑，问题不大。业务背景在互联网项目中，分布式、高并发、大数据是绕不开的话题，尤其现在容器化，微服务，云原生的概念越来越火，由此诞生了很多 crud-boy sql-...

业务背景众所周知，在我们迭代业务需求和Fix Bug时往往需要重启我们的服务，在高并发场景下，如果还像N年前一样，通过上机操作敲Linux命令执行Kill操作，在分布式环境下显然会让你敲断手指，并且这种方式重启还会影响用户的操作，导致一些线上事故，所以，在微服务、分布式系统中，平滑滚动发布无疑是非常重要的(主打的就是一个丝滑)。SpringCloud微服务架构导致发布的一些弊端1.Nacos组件导致的一些弊端众所周知，Nacos利用心跳机制每隔一段时间(可配置,defalut:30s)服务端与客户端都会互相发送心跳包，当服务端接收到的客户端心跳包有异常情况时，Nacos服务端会剔除客户端在服务...

业务背景主要为IM私聊、直播间弹幕、公屏、大厅广播消息实现一个敏感词过滤和脱敏处理需求分析与拆解敏感词库定义与导入敏感词匹配DFA算法实现黑、白名单词库定义实现思路封装成无侵入式组件，方便组内人员复用使用时支持选择过滤或脱敏处理方式利用Spring EL表达式动态获取/改变bean属性值实现过程黑白名单词库导入每行一个敏感词，词库可网上寻找或者自定义词库工具类封装 public class SensitiveWordUtil { /** * 词库上下文环境 */ public static final WordContext CONTENT = new WordContext(); publi...

背景在每次的开发迭代中，每次的改动点可能都涉及到多个服务，每次改动发版都需要重新发布，在发布过程中有用户使用必然会出现一定的404,503,rpc调用timeOut问题，就在某一天修复线上问题一天发布了N次，用户向运营投诉了，说怎么我们App经常报网络异常，经过排查得知，发布不够丝滑造成，具体表现如下原因分析上面我为什么要放三张图，是有深意的，因为这三张图，代表着我们要分析的三个表现层面，分别是Gateway，RPC，MQ这里再补一张我们的系统调用链路图由图可知，系统调用链路要么是经过网关转发-业务服务-RPC调用，要么是长连接-RPC调用，RPC之间又分别有多个调用，这时有人可能会问了，你这...

背景主要用户群体所在地区有 香港、台湾、新加坡、马来西亚，那么对应使用的货币会有台币、港币、新币、马来币，针对此多种类型货币的支付对接，我们会找多种三方支付平台，寻找当地手续费最低化和用户使用最普遍化的方式，因此在技术设计上我们需要做支付方式、手续费、货币汇率、地区、支付挡位切换等配置。整体对接流程设计客户端内购使用场景一般使用对应商店内购支付，比如苹果支付、谷歌支付，这里提一嘴，手续费大概30%，这么高，那为什么我们还要接呢？ 因为你要在它们对应商店上架，算是潜规则，你不接它的东西，他不给你App过审，我理解为交保护费...支付对接流程H5第三方支付使用场景第三方支付主要就是为了手续费低这一...

业务背景产品类型：语聊社交类目标用户群体：海外华人服务器、数据中心地域：亚太、北美混合云服务商选择：Ali Cloud、GCP 、Tencent Cloud业务介绍多麦位语聊直播、房间内礼物打赏语音房间内小游戏IM互动、1V1视频通话营收、打榜等商业化活动用户社区互动、交流公会、主播入驻、主播薪资结算虚拟装扮、物品商城资产体系、充值、提现架构规划结语这是第一期架构的规划，基本能用云服务尽量采用云服务(成本也得控制下)，方便后期伸缩与扩展，对开发团队来说自动化、轻运维、重业务，适合早期产品的快速迭代。

背景运营反馈，有用户在直播间内发送公屏，A用户发送的公屏 结果直播间内所有人员都显示了B用户发送的，而实际却是A用户发的。原因分析日志排查询问运营要到问题截图定位公屏内容和出现问题的时间点3.查看log打印代码位置好家伙,发现服务端没有没错，实际发消息的用户ID和大家收到公屏的发送人不一样？ 又让客户端排查了下日志，发现客户端A发送的，实际到了服务端从Token中获取到的当前发送公屏用户竟然是B？代码分析gRpc请求拦截器代码 @Slf4j(topic = SLSTopicType.TOPIC_GRPC) public class CommonGrpcServerInterceptor imp...

背景使用了Gitlab CICD+Docker+K8s的方式来打包构建项目，由于组员反馈，项目打包构建速度过慢，再加上服务过多，导致影响了测试服的发布效率，考虑到测试服每天要进行几百上千个流水线操作，每个流水线平均耗时可能都要6min以上，大大的浪费了开发/测试的验证时间，故下达了一个优化打包的额外需求分配给组员完成，期限一周，一周将至，看着组员最终硬着头皮和我说没搞定，我有点懵，询问它这个地方有什么难度吗？组员：我搞了一个私服，但好像并不能提升打包构建的速度... 当然他是利用额外工作时间去搞的，我也不能责怪于他，只能亲自手把手教他优化。组员优化过程实际目标:优化打包效率，组员理解目标:优化...