腾讯IEG 运营开发工程师一面

面试基本信息

公司: 腾讯IEG（互动娱乐事业群）
职位: 运营开发工程师（偏全栈）
面试轮次: 一面（技术面）
面试形式: 线上视频面试
面试时长: 约90分钟
面试官: 开发(似乎是全栈开发工程师)
面试日期: 2025年06月21日

面试问题与回答

问题1：自我介绍

面试官问题：

“咱们老规矩先自我介绍一下呗”

我的回答：

"面试官你好。我是王宇哲，目前是华东师范大学软件工程密码学方向在读研究生。我研究的方向主要是可搜索加密，然后比较偏数据检索这方面的。然后本科期间的话，我学习成绩比较优异，三年均为专业排名第一，获得过国家奖学金。也通过自己的编程能力获得过一些比如说蓝桥杯国奖，计算机设计大赛三等奖这些奖项。我自己的话是对分布式系统以及微服务架构这些微服务架构设计这些方面特别感兴趣。然后在过去的项目中，我主要是使用Go技术栈去构建一些分布式应用。

去年12月到今年2月期间，我参加抖音的青训营，然后组织团队完成了一个基于微服务架构的抖音商城系统。然后我在这里面是负责系统的总体架构设计，以及使用GitHub Actions去实现自动部署微服务上云这些操作。然后我也设计了微服务之间通信的机制，以及结合了OpenTelemetry去融合一些可观测性。也使用了Nacos实现服务注册，以及服务发现，以及动态配置热更新。除此之外我还设计了一些黑名单分级存储策略之类的来优化一些系统性能。然后同时使用Canal加消息队列来进行三个数据库的数据同步。

然后去年7月份的话，我也在学习Go期间，我是开发了一个AIGC NEXUS应用。它是一个分布式的用AI来进行微服务调用的一个框架。基本上就是我的自我介绍。"

标准/建议回答：

自我介绍可以更加结构化一些，建议按照以下逻辑：

"面试官你好，我是XXX。首先说一下教育背景，我现在是华东师范大学软件工程专业的研二学生，研究方向是密码学。

在技术能力方面，我主要专注于分布式系统和微服务架构的开发。最近的项目经验包括：去年12月到今年2月参加了抖音青训营，组织团队完成了一个基于微服务架构的电商系统，我负责系统架构设计、CI/CD流程搭建以及服务间通信机制的设计。

在学术成绩方面，本科三年专业排名第一，获得过国家奖学金。同时也有一些实践经验，比如参加计算机设计大赛获得三等奖等。

我对这个岗位很感兴趣，因为我了解到这个职位涉及到前后端开发，正好符合我希望在工作前几年进行技术广度学习的规划。"

总结反思：

回答比较全面，涵盖了教育背景、项目经验、技术能力
体现了对全栈开发的兴趣和学习规划
可以更简洁一些，重点突出与岗位相关的经验

问题2：学习成绩情况与实习经历

面试官问题：

“你有提到本科阶段成绩比较好，那研究生阶段的成绩怎么样？”

我的回答：

“研究生因为是研一，但是我绩点的话应该是3.8，应该也能排前面。然后因为我是考研考上来的，我考研的成绩的话是排专业第二，70个人里面。”

面试官问题：

“我先问一句，就是你现在是在实习中是吧？”

我的回答：

“我不在实习中，但是…看你的简历，你是已经结束了一段之前的项目是外部开发的实习。对对对。”

面试官问题：

“我看你现在应聘的岗位是后台开发方向，我想问一下你对未来的期望。我因为我这边的岗位是偏全栈的，他不单纯是后台开发，后端为主，但是会涉及到一些前端，小程序端的工作量。你这种岗位你未来会考虑吗？”

我的回答：

“我会考虑的。因为首先我自己是就是我本科期间，其实我做的东西都很杂，也是偏全栈这些东西就是我什么都会做一点，然后我基本上都会自己去开发一些应用，去类似于做一些小demo之类的，所以说基本上我都会涉及一些，然后我也比较关注的是知识的广度。然后目前的话就是近就是从我研究生研一开始，然后到未来工作的三年内，我都会我都计划是去进行广度的学习，而不是去深度的学习。这在工作的三年中，我可能会进行深度的学习。这段时间的话，我是主要是在广度的涉猎一些技术，了解各种各样的技术栈。所以说我感觉这个职位当时我看到这个职位描述的时候，我觉得我自己是比较希望能进来的。”

标准/建议回答：

"研究生阶段我也保持了比较好的学习状态。目前研一的绩点是3.8，在专业中排名靠前。考研时我的成绩在70人中排第二，说明基础还是比较扎实的。

不过研究生阶段我更注重实践能力的提升，所以在保证学业的基础上，我会更多地参与一些项目开发和技术学习，这样能更好地将理论知识转化为实际能力。"

总结反思：

数据具体，有说服力
体现了从理论向实践转化的思路
展现了学习能力和自我规划意识

问题3：抖音商城项目背景

面试官问题：

“你刚才也提到过那个抖音商城的项目是一个什么背景，抖音的什么比赛项目吗？”

我的回答：

“对他是一个青训营的项目，他就是组织一群人一起去，他会给我们一些教学视频，然后让我们自己去学完视频以后，自己去根据这个团队，按照他的需求文档来做一个系统出来。大概花了，初期的话是一个月就已经把基本的功能都给做完了。然后中间是春节，春节就是中间很长时间没有做。然后后面的话就是在春节期间也考虑一些其他的技术栈，比如说后来那个Canal什么的，都是后来考虑到的，然后去给它融合进去了，总共加起来的话是两个月。我们的话具体开发的话四个人，但是其实主要工作量还是我大概70%的工作量。”

标准/建议回答：

"是的，这是字节跳动青训营的一个实战项目。青训营是字节跳动面向大学生的技术成长计划，他们会提供系统的技术培训视频和实战项目。

整个流程是这样的：首先我们需要学习他们提供的微服务开发相关视频课程，然后根据他们给出的需求文档，自主组队完成一个完整的电商系统。

我选择担任队长，主要是因为我对微服务架构比较感兴趣，而且希望能在项目中承担更多的技术决策和架构设计工作。这个项目让我对分布式系统有了更深入的理解，也积累了团队协作的经验。"

总结反思：

说明了项目的权威性和含金量
体现了主动学习和领导能力
展现了对技术的热情

问题4：内存占用排查与分布式事务

面试官问题：

“先问一个内存问题，假如说现在有遇到一个问题，你这个服务上线了，但是有一天遇到服务器告警，内存不足，你去排查问题，你会用什么方法去去排查？”

我的回答：

"这个正好是我之前实习的时候遇到了一个问题。就是当时实习的话因为我们当时那个公司的系统版本比较低。然后后来不知道怎么的，就是好像去年十月份开始有一个漏洞，就有一个蠕虫病毒，然后悄无声息进入我们那个服务器里面去了。然后他就一直在挖矿，然后导致我们那个MySQL就一直在启动，然后过三天宕机了，再启动又过三天又宕机了。

然后我们先去用那个命令行去看top，就是用top去看进程的那些什么内存占用情况，CPU占用情况，发现都不太行。然后后来的话我们就下了一个第三方的那个工具，然后第三方的那个命令行管理工具，然后我们去运行，然后发现他那个我们一运行就会发现他前他就是最就是会有一个应用，会有一个进程，它占用特别多内存，还有那个CPU资源。然后我们就用那个which命令去去判断top指令它在哪个目录。然后我们发现top被那个蠕虫病毒给修改掉了。"

面试官问题：

“那换一个问题，如果不是被攻击的，就只是单纯的你的服务内存占用比较高，怎么解决？”

我的回答：

"首先一般来说服务占内存占用比较高的话，它有几个问题。我自己开发那个抖音商城的时候也遇到过相关的问题。就比如说我用Nacos的时候，他那个服务器动不动就OPS过高，然后整个服务器就停止了。后来排查原因发现是Nacos他那个日志级别的问题。因为给他设置了info日志，导致他日志特别多。然后不停的读写磁盘，导致它那个内存过高了。于是我们就把这个日志级别给改成那个error级别。

除此之外还有MySQL，MySQL经常会出现内存过高的情况，占用内存量过高的情况。那它一般来说就是它的一些缓冲池之类的，就是参数设置过高，我们会给它设置低一点。虽然说它查找速度性能会变低，但是它不至于让整个系统的内存在负载太高。"

面试官问题：

“那现在就有一个比较现实的问题，就是你上去就top去看一下，发现有某个服务的进程，它耗的内存就是比较高，越来越多。那你怎么去排查垃圾回收的问题？”

我的回答：

“垃圾回收的问题的话，这个我感觉是要从代码层面去考虑。可能就是在做单元测试的时候，去给每个进程去帮他们GC一下，然后去判断一下这个内存最后会占用多少，然后去一个个去找到对应哪个内存可能占用一直过高的那个。但是排查内存泄露的工具我没有用过。”

面试官问题：

“如果用分布式事务解决库存问题，具体是怎么操作的呢？”

我的回答：

“这个我不太了解，应该是如果说他出现了问题，他应该还要专门写一个恢复的函数。我估计是这样，因为我不太了解这个分布式事务，它应该是要专门写一个恢复库存的一个函数。然后就是分布式事务它会有个中心，应该会通知他去回滚，应该是这样的。”

标准/建议回答：

"分布式事务解决库存问题主要有几种方案：

第一种是2PC（两阶段提交）模式，有个事务协调器来管理。第一阶段先向各个服务发送准备请求，比如订单服务预创建订单，库存服务预扣减库存。第二阶段如果都准备成功就提交，否则就回滚。

第二种是TCC模式，就是Try-Confirm-Cancel。Try阶段先尝试执行，比如冻结库存；Confirm阶段确认提交；如果出现问题就Cancel回滚，释放冻结的库存。

第三种是SAGA模式，将一个分布式事务拆分为多个本地事务，每个事务都有对应的补偿操作。如果后面的事务失败，就逐步执行补偿操作来回滚。

实际项目中我们更多会选择最终一致性方案，比如使用消息队列来异步处理，配合重试和补偿机制来保证数据最终一致。"

总结反思：

当时回答过于简单，缺乏具体的技术方案
应该准备常见的分布式事务解决方案
需要加强分布式系统理论知识

问题5：MySQL索引设计

面试官问题：

“假如说有一张用户的数据表，字段有用户名、昵称、性别、年龄、注册时间，对这个表做索引的设计，你会做哪几加索引？”

我的回答：

"我首先肯定要考虑的考虑把用户名设或者ID设置为主键，这样的话查询起来比较快。因为用户名查找的肯定是最多的。然后其次的话昵称我一般是不会建索引的。因为像比如说我们现在QQ我们那个QQ里面很多人都他都会有很多稀奇古怪的符号。如果说我们建索引的话，他其实很少有人会对它进行精确的查询。所以说我们不会对他建索引，让他每次查询都全表扫描。

然后这个性别的话一般查的也比较少，性别年龄一般查的也比较少。注册时间的话我觉得内部他可能会统计一些用户信息，他可能会用，所以说可能要建个索引，而且他比较比较能比较良好的支持一些范围查询之类的。所以说这个可能要建一个索引，可能根据内部需求。"

标准/建议回答：

"对于这个用户表的索引设计，我会这样考虑：

首先肯定是主键索引，如果有user_id就用user_id，这是聚簇索引，查询效率最高。

然后我会根据业务场景来设计其他索引：

用户名（username）：这个肯定要建唯一索引，因为登录时会频繁按用户名查询，而且用户名不能重复。
注册时间（register_time）：这个建议建普通索引，因为运营经常需要按时间范围统计用户，比如查询某个时间段的新增用户。
性别、年龄：单独建索引意义不大，因为区分度太低。但如果经常需要按年龄段和性别组合查询，可以考虑建联合索引 (age, gender)。
昵称：一般不建索引，因为昵称查询不多，而且昵称可能包含特殊字符，索引效果不好。

总的原则是：高频查询的字段、区分度高的字段优先建索引，但也要考虑索引维护成本。"

总结反思：

基本思路正确，但分析不够深入
应该更多从业务场景角度考虑
需要掌握索引设计的基本原则

问题6：联合索引使用规则

面试官问题：

“如果有ABC3列的话，AB、AC、BC、CB、CA哪几个能用到索引？”

我的回答：

“AB应该是会用到的，因为它满足最左原则，其实我们联合索引可以把它看成几个字段给它拼起来，就从左向右拼起来，所以说AB肯定可以。AC可以查一部分，就是查的性能可能没有那么好吧，感觉会先查A。具体的字段忘了，具体字段忘了，它好像会显示用到哪些什么range之类的一些索引，但是具体的用的比较少，所以说我已经记不太清楚了。”

标准/建议回答：

"这是联合索引的最左前缀原则问题。如果建立了ABC的联合索引，那么：

能完全使用索引的组合：

A：可以使用，因为A是最左边的
AB：可以使用，符合最左前缀原则
ABC：可以使用，完全匹配

能部分使用索引的组合：

AC：只能使用A列的索引，C列用不到，因为缺少中间的B
BC：完全用不到索引，因为没有最左边的A

完全用不到索引的组合：

CB、CA：都用不到，因为没有从最左边开始

这是因为联合索引在B+树中是按照建立顺序进行排序的，必须从最左边开始才能有效利用索引的有序性。实际应用中，我们通常把查询频率最高、区分度最大的字段放在最左边。"

总结反思：

对最左前缀原则理解不够准确
需要深入理解联合索引的存储结构
应该能准确判断各种组合的索引使用情况

问题7：海量数据处理

面试官问题：

“统计海量IP数据中出现次数最多的前十个IP。数据量会比较大，假设是一个IP地址的文件，然后文件中有100亿个IP，文件大小大约是100G。”

我的回答：

"最简单的方式的话，应该是想到用一个map来存。但是100个G的文件，它没有办法直接加到内存中。首先它是100个G的文件，它不可能一次性读入内存。首先我们肯定是这个命令行的话，它肯定是要用一些指针去记录上一次读入内存的文件的地址。我记得C++里面，它应该是有一个指针的，就是文件的游标。

然后我们首先第一次初步统计前，就是初步我们分批次读取。比如说第一次读个一个G然后读完一个G以后，我们先用一些常规的算法去把它前10个IP统计出来。但分批次读的话，它会丢失前面那一个分块的信息。比如说可能统计出来前十个分块，前十个分块次数出现次数最多的是IP1，然后他出现了十次。但是其实出现次数第二高的它是出现了九次。但是后面这个IP1它再也没有被出现过。但IP2的话它一直又经常性的出现。但是IP2没有被计算进去，那就没有办法达到我们的需求。

可能得用归并排序吧。但哈希的话它会占用很多内存。但是这个海量IP，它不应该是乱序的吗？有重复的有重复的。"

标准/建议回答：

"这是一个典型的海量数据处理问题，100G的文件无法直接加载到内存，需要用分治的思想：

第一步：数据分片

将100G文件按IP进行哈希分片，比如分成1万个小文件
每个IP做hash(IP) % 10000，相同IP一定会分到同一个文件中
这样每个小文件大约10M，可以放入内存处理

第二步：单文件处理

对每个小文件，用HashMap统计IP出现次数
找出每个文件中出现次数最多的前10个IP

第三步：全局合并

将所有小文件的top10结果合并（最多10万个IP）
再次统计，找出全局的top10

时间复杂度：O(n)，空间复杂度：O(k)，其中k是单个分片的大小。

这种方法的核心思想是’分而治之’，确保相同IP在同一个分片中，这样就可以准确统计每个IP的总出现次数。"

总结反思：

刚开始思路不够清晰，被100G的数据量吓到了
经过面试官提示后理解了哈希分片的思路
需要加强大数据处理的算法思维

问题8：抽奖算法实现

面试官问题：

“实现一个抽奖程序，有一个概率表：一等奖0.1，二等奖0.1，三等奖0.2，四等奖0.4，概率和是1。要求实现这个抽奖的算法，并且执行1万次抽奖，然后计算每个奖项的总和。”

我的回答：

[现场编程实现了基于随机数和概率累加的抽奖算法]

标准/建议回答：

"这个抽奖算法我用概率区间的方式来实现：

func lottery() int {
    // 概率表：[0.1, 0.1, 0.2, 0.4, 0.2]
    probabilities := []float64{0.1, 0.1, 0.2, 0.4, 0.2}
    
    // 生成0-1之间的随机数
    rand := rand.Float64()
    
    // 累加概率，找到对应区间
    cumulative := 0.0
    for i, prob := range probabilities {
        cumulative += prob
        if rand <= cumulative {
            return i + 1  // 返回奖项编号
        }
    }
    return len(probabilities) // 兜底
}

这种方法的时间复杂度是O(n)，其中n是奖项数量。如果奖项很多，可以用二分查找优化到O(log n)。

执行1万次的结果应该接近理论期望：一等奖约1000次，二等奖约1000次，三等奖约2000次，四等奖约4000次，五等奖约2000次。"

总结反思：

现场编程基本实现正确
考虑了算法的时间复杂度
可以进一步优化，比如预处理累积概率数组

问题9：Redis与gRPC

面试官问题：

“Redis的持久化有什么方法？”

我的回答：

“持久化的话它有两种，一种叫AOF，一种叫RDB。然后AOF的话，它相当于是记录到一个日志文件里面。它因为它AOF它全名叫append only file，它实际上是把每次请求，每次操作都给它加到一个日志文件里面去。RDB的话它相当于是一个镜像，它会把整个数据库全量给它保存下来，但它不会保存每次操作记录。”

面试官问题：

“你项目里面有用到过gRPC对吧？说说gRPC和restful API的区别。”

我的回答：

“对，gRPC的话首先它restful API的话他用的是HTTP协议，gRPC好像是RPC协议，还是他自己研发的一套协议，不太记得。但它肯定是RPC。首先RPC它是去掉了HTTP里面的一些东西的，所以说它的性能会更高一点，它更适合去做内网的通信什么的。所以说我们一般来说就是微服务之间调用都使用RPC协议。除非有的时候就比如说有别的公司想让你来调用他的微服务，但是他的RPC肯定不可能向你开放。那这个时候还是要使用restful API去调用他微服务，主要是考虑这个。就是内网和外网的区别。”

面试官问题：

“你技术选型你是怎么怎么做的？就决定用这一套。以前做过类似的项目吗？”

我的回答：

“以前就下面那一个叫AIGC的，它也是一个微服务项目。但是我一开始接触微服务的时候就是接触gRPC的，所以说我都是这么选的。”

面试官问题：

“抖音商城的技术栈和前面那个AIGC的项目技术栈里面有什么差异吗？”

我的回答：

“抖音商城的技术栈的话它是比较丰富一点，但是AIGC的话它更多。因为现在AI它想要用户去响应的友好一点，他肯定是要用流式API去调用的。然后流式API在微服务中它可能就会有一些问题。然后就在AIGC微服务调用的时候，AIGC这个项目微服务调用的时候，它会使用server streaming去调用。就是他用流式去调用。主要是这一点区别，然后以及他他需要一个泛化调用，就是AIGC native它还有一个技术体现在泛化调用。”

问题10：MySQL数据引擎与库存问题

面试官问题：

“mysql常用的数据引擎有哪些？”

我的回答：

“首先是InnoDB，然后还有一个叫MyISAM，然后还有一个是好像是直接存到内存里面的一个引擎，具体名字我不太记得。”

面试官问题：

“Memory那个memory这个场景比较特殊，一般持久化的InnoDB和MyISAM它的特性有什么区别？”

我的回答：

“InnoDB的话它主要是支持ACID特性。然后MyISAM的话它是不支持事务的，然后他好像也没有很强的一些锁之类能力。他应该主要面向于查询这个场景的一个引擎。像InnoDB的话的功能就比较完善，增删改查它都比较有比较好的性能。”

面试官问题：

“抖音商城里面不可避免的会有商品库存问题，这个库存问题你怎么解决的？”

我的回答：

“首先我可以说一下，其实我们当时没有做库存这个东西，但是我有思路。库存的话它有好几种方式。一种就是在分布式系统里面，它有个叫分布式事务这个东西用分布式事务去给它扣减库存。然后还有一种方式是用Redis Lua脚本去扣减。这个的话是我的队员去实现，然后我看到他去这么实现，然后稍微看了一下。但是他最后因为我们当时分工的时候，就是他不知道没有库存这个东西，然后他实现了库存这个东西。然后的话我还有一些就是用Redis进行加锁。”

面试官问题：

“获取锁和释放锁分别是什么操作？”

我的回答：

“这个有一点不太记得了，因为都是在函数里面去调用lock unlock方法。就前端是Hertz，叫前端是用的Gin。”

问题11：Web安全漏洞与个人背景

面试官问题：

“常见的外部开发里面的安全漏洞，这个有了解吗？”

我的回答：

"常见的web开发安全漏洞，第一个SQL注入，这个漏洞的话基本上被现在因为用ORM框架用的比较多，所以基本上已经被基本上解决了。但是不排除一些公司他还在沿用那种字符串拼接的方式去对数据库进行操作。他我记得以前用PHP的时候，它有360的一个安全库，它可以做一个浅层的过滤，用一个正则表达式去做过滤。就是它会有各种各样的不安全的那些字符组合就用那种方式可以过滤。

然后XSS漏洞的话，XSS的漏洞主要就是其实他防范的就是防范主要是脚本。所以说现在的话我了解到最新的方式就是在HTTP请求的header头里面，它有一个header，你可以去给它开启。然后它就可以防范这个XSS的注入。它就可以即使你有XSS代码，但是它也会不允许你跳转到一些你不允许的网站里面去，这样就能一定程度上防范这个漏洞了。"

面试官问题：

“比较早是多早？”

我的回答：

“我初三的时候就接触，当时在接触PHP。对，自己做网站。因为当时的时候也是为了攒钱，买一些自己想要的东西。就是当时很火的一些授权之类的。就是你做一个好的产品，然后你可以授权卖给别人。那是很早，大概13、14年。PHP估计两三年。”

面试官问题：

“你的实习的时间是四月份开始，时长是多久？”

我的回答：

“能一年吗？一年，因为我论文我基本上写的差不多了，我其实更想在公司里面学到更多的东西。”

面试官问题：

“你玩游戏吗？”

我的回答：

“玩过。基本上就平常偶尔玩一玩王者荣耀。因为平常的话主要还是在写代码，然后学累了我会玩一玩王者荣耀。星耀段位。我上过王者，很早之前。”

标准/建议回答：

"Web开发中常见的安全漏洞主要有：

SQL注入：通过在输入中注入恶意SQL代码来操作数据库
- 防范：使用预编译语句、参数化查询
- 对特殊字符进行转义
XSS（跨站脚本攻击）：在页面中注入恶意脚本
- 防范：对用户输入进行HTML转义
- 设置CSP（内容安全策略）头
- 使用HttpOnly cookie
CSRF（跨站请求伪造）：利用用户登录状态进行恶意操作
- 防范：使用CSRF token
- 验证Referer头
- 设置SameSite cookie属性
文件上传漏洞：上传恶意文件执行代码
- 防范：限制文件类型和大小
- 文件内容检查
- 存储在非执行目录
权限控制漏洞：未正确验证用户权限
- 防范：严格的权限校验
- 最小权限原则

在实际开发中，我们通常使用安全框架来防范这些漏洞，比如Spring Security、OWASP的安全组件等。"

面试官问题：

“如果如果这是一个已经上线的业务，你去看一个slow query就有个慢查询的日志。你怎么分析这个表的索引有没有被用到。”

我的回答：

“我记得好像有一个叫explain命令。具体的字段忘了，具体字段忘了，它好像会显示用到哪些什么range之类的一些索引，但是具体的用的比较少，所以说我已经记不太清楚了。”

面试官问题：

“现在这个场景稍微变一下，如果是以QQ号就是别的账号体系生成的账号为例，我们要设计抖音商城的一个用户访问数据。比如说我们要记录用户浏览商品的所有的日志，接到数据库，然后后面可能供数据挖掘去做商品推荐使用，这个流量会比较大，每天500万的浏览量。这个数据存储你怎么设计？”

我的回答：

“这种一般是用数仓来存储的。首先我们所以引擎的话可能要改一下，改成那个MyISAM。因为它只有增和查这两个主要操作，所以说我们并不需要对它去改和删。所以说的话首先引擎这方面要变掉，然后其次的话表的设计。表的设计的话最好还是设计成一个表。就是用户相关信息，以及商品对应的关系，它都设计成一个表中，不要尽量不要进行多表关联，多表关联的话可能会比较消耗一些内存。考虑它的数据量级。怎么存？他这种数据量级的话，一般是要分库分表。根据浏览时间进行分表。比如说我们以一年为一个维度，我们可能会把它拆成12个月，然后每个月它有一个自己的表，或者说每一天他有一个单独的表。这样的话查询起来压力应该没有那么大了，就是存储起来压力应该就没有那么大了。”

总结反思：

基本概念了解，但深度不够
需要更系统地学习Web安全知识
应该结合实际项目经验来回答
对大数据量处理有一定思路，但缺乏更深入的分库分表方案

面试整体感受

难度评价: 适中偏难
面试官风格: 专业、耐心，会适当引导
题目类型: 偏重实际应用，考察项目经验、系统设计、编程基础
准备建议: 需要有实际的项目经验，对分布式系统、数据库优化要有深入理解

面试结果

当场反馈: 面试官对项目经验比较认可，指出了一些技术深度不足的地方
后续流程: 等待HR通知后续面试安排
个人感受: 整体表现中等，项目经验是亮点，但技术深度还需加强

经验总结

做得好的地方

项目经验丰富: 抖音青训营项目体现了完整的开发经验
学习能力强: 体现了持续学习和技术广度探索的意愿
沟通表达: 能够清晰表达技术思路，逻辑性较好

需要改进的地方

技术深度: 对分布式事务、数据库优化等深层技术理解不够
系统设计: 海量数据处理等算法思维需要加强
安全知识: Web安全漏洞的防范措施掌握不够全面

准备建议

深入学习分布式系统: 重点掌握分布式事务、一致性算法、服务治理
数据库优化: 深入理解MySQL索引原理、查询优化、分库分表
系统设计能力: 多练习大数据量处理、高并发系统设计
安全知识: 系统学习OWASP Top 10，了解常见安全防护措施
算法基础: 加强海量数据处理、分治算法等基础算法能力

知识点复习清单

[ ] 分布式事务（2PC、TCC、SAGA）
[ ] MySQL索引优化和联合索引原理
[ ] Redis持久化机制和分布式锁
[ ] 微服务架构设计模式
[ ] Web安全漏洞防护
[ ] 海量数据处理算法
[ ] 系统性能优化策略

对IEG运营开发岗位的理解

面试官介绍：

"我们部门比较大，部门整应该说我们部门负责的是腾讯互娱，互娱也就是我们那个互动娱乐运营。你别说他现在叫IEG，腾讯的工作室群划分，这个你知道对吧？腾讯云对微信，大概分这么几个BG。IEG就是可以统称腾讯互娱，所有的游戏相关的都在这个事业群。然后我们部门的话是在IEG之下做游戏核心玩法以外的一些周边的系统工具运营活动等等。相关的项目可能都在我们这儿。那游戏工作室的话就很好理解，他们做游戏本身，游戏玩法就是客户端。

然后除了你能玩到的那个游戏本身的东西，还会有一些做运营的相关的方向。比如说王者荣耀，你如果玩过就应该知道它里面经常会看到一些活动。比如说那个皮肤返场、投票、领奖，就你参与投票或者是投稿一些比赛赛事等等，这种活动都会有一些奖励。这种活动类的大多数是我们做的。王者的运营开发就在我们团队，对，运营开发就在我们团队。我们这负责是准确的说是天美的所有的游戏运营开发都在我们这。

项目的话比较杂，除了除了核心玩法以外，它的那些工具系统。比如说我们有可能会做一些运营活动，以运营活动为主，大头是这个。还有一部分是像比如说策划用的一些工具，系统都有可能是我们来做。

项目最多的是运营活动类的。运营活动类王者里面你能看到很多，他里面现在是用这种叫游戏内的一种仿原生的开发技术。王者本身它是unity开发客户端，用U引擎的。但我们可以往里面去往游戏里面去嵌H5的。就这种web的活动页面也可以用那个原生的仿原生的一种。我们自己我们部门自己做了一种引擎去做那个支持热更的这种原生活动，对比王者项目组自己做的话，这种就更新，还有开发效率方面会更高。然后他试验成本会相对低一些，因为他们自己做的话，用unity去做发版本这种会比较麻烦。这是我们叫我们自己叫他那个潘多拉的框架，这个是端内的原生项目。

然后还有一些是外部开发的项目，有一些是小程序的项目，大概是这样。但小程序我们倒不用自己做纯页面部分，一般的H5和小程序的页面的切图和重构会有专人来做。我们会负责去做后端的功能，以及把这个页面和功能整合起来。就写一部分JS，大概是这样。"

面试官详细介绍了岗位职责：主要负责腾讯游戏（特别是天美工作室群）的运营活动开发，包括：

游戏内活动页面开发（H5、小程序、原生）
运营工具系统开发
后端服务和数据处理
技术栈偏全栈，需要一定的前端能力
使用自研的潘多拉框架支持热更新

这个岗位很适合希望在技术广度上发展的同学，能接触到游戏行业的业务场景，技术挑战也比较丰富。特别是对于亿级用户量的游戏活动，在高并发和数据处理方面都有很高的技术要求。