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

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

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

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

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

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

To CRUD Boys你的身边是不是总有人吐槽你只会CRUD编程？你是不是整天都在做一些CRUD的编程操作，比如普通业务的CRUD、后台管理的CRUD、高并发应用的CRUD，如果是，那恭喜你，确实没说错，你就是个CRUD编程仔。前言其实不管大厂、小厂，做业务开发的同学都知道，写一个功能，有中台，有架构，有API，有SDK，很多可复用的代码直接调一下RPC接口或者一个注解就搞定了复杂的操作，所以很多螺丝钉们都没法真正接触底层核心组件、功能的设计和编写，更别谈在项目中会有什么技术选型、做决策、落地的操作，长此以往，技术广度、深度、落地能力 一个都没锻炼出来，所以为什么说大厂中P7是个分水岭，这句...

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

前言面试时面试官一问到MQ你了解吗？能讲下你们项目中MQ用来干什么吗？大多数人的第一回答是："异步消息处理,削峰填谷",今天教你们一招能瞬间让面试官打起精神的回答，下次面试时你们可以这样说：MQ就像是一个神奇的邮递员，它可以将消息快速、可靠地传递到各个系统中，它的作用就像是一个桥梁，连接了不同的系统，使得它们能够顺畅地交流和协作。 顿时格局就上来了，这时面试官的心理活动：这小子理解总结得蛮透彻的，今天我得在MQ上多盘他几下....业务场景MQ使用场景介绍直播间内送礼、特效、公屏、弹幕等需要用到MQ异步处理分布式环境下本地缓存的刷新需要用到MQ通知刷缓存耗时长/并发高的业务需...

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

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

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