国际电商

一面

自我介绍

• 硕士毕业进入xxxx。负责xxxx。2020年，xxxx。开始负责xxx。今年，成为xxx业务负责人。xxxx。

jy这两年被打压，对你们有影响吗？

• 其实影响不大。这里需要我简单介绍一下我们的业务。xxxxxxx。

问问题

因为你在xx的工作时间比较长。你能画一下你们xx的架构图。

• 要偏业务的，还是技术的？

偏业务的。之后我可以根据你画的展开问。

• 好的。我们主要分为C端和B端生产和B端输出。
• 内容生产平台xxxxxxxx。线索、生产。内容处理。
• openapi，输出数据到C端和B端。
• B端。xxxxxx。

这里面有哪些核心服务。指标情况怎么样。包括QPS。

• B端QPS xxxxxxx。峰值xxxx。C端xxxxxx。
• 我们主要会关注稳定性SLA。是通过状态码来判断。还会监控服务耗时。

整个项目中，最大的技术难点是哪个

• 内容存储方面。需要保证数据的一致性。采用消息队列，版本号等措施。

用的是关系型数据库吗？

• 是的。厂内基于MySQL封装的一个分布式数据库。

它那块是怎么实现分布式，你了解吗？

• 了解。它在底层搭建多个MySQL实例，然后通过代理层承接请求。

分片键是怎么定的。

• 我们的内容会有唯一ID，使用唯一ID。对于生产者，会通过用户ID。

分片均匀吗，数据倾斜的情况怎么样？

• 我的数据是通过生产时间，自己做了一个ID生成器。然后我们把ID做了一个散列,再去存储。目前数据没有明显倾斜。

会不会有跨分片的查询操作。

• 代理层支持把数据从多个分片查询，聚合返回给我们。

分布式一致性是怎么解决的。比如某个节点宕机了，怎么处理？

• 我们的服务是部署在一个集群里的。它对外暴露服务的方式是通过BD名字服务BNS。假设一台实例宕机了，平台的monitor程序会立刻监控到服务异常，它会把把服务的IP从名字列表里摘除。上游就不会请求到它。

写代码

有两个单链表。每个单链表里存储了多位数字，现在要把两个单链表相加。高位在首节点。链表结构需要自己定义。
例如：4 -> 1 -> 6 和 1 -> 2 -> 3 -> 4 ，结果是 1650。
注意：

1. 单链表非常长，所以不能转化为整数相加。
2. 不能使用辅助的数据结构。
3. 时间复杂度是O(n)

（写之前先沟通了思路。沟通了3分钟，这题我写了14分钟，最后跑出来了）

这次看机会的原因。

• xxxx。离家近点。xxxx。

问MySQL

对MySQL也比较熟悉是吧。你说说，慢查询主要怎么优化。

• 发现慢查询是通过slow log。然后通过explain命令检测索引使用情况。
• 索引字段没加，或者没用上。这是第一种情况。
• 第二种情况是，索引也用了。但是发现数据量，条数特别多。我们就遇到过一次。xxxx。后来我们把数据拆分，只保留当月需要的数据量。
• 还有一种情况，是由于受到其他查询的影响。比如有大量的数据导入或者输出。此时就会慢查询。就会发现MySQL的CPU上来了。

你说的有索引，但是没用上。这种具体是什么情况。

• 可能是开发者没有正确评估。在数据量大的时候，就会有问题。
  我想问的是表里有索引，sql里也有，但是没有使用上。这种情况。
• 这种需要具体分析。
• 一种是表里索引很多，对于这种情况，数据库会去择优选择索引。数据库实际会根据预估的数据量去选择，选择数据量少的索引。它可能会评估不准。
• 第二种情况是，对于联合索引，没有遵循最左原则。要从左到右，按索引树的顺序来选择。

我这边就是这些问题。

反问

我们这边的工作内容。

• tiktok xxxxx。

团队规模多少人

• xxxx

二面

自我介绍

xxxx

问问题

你刚提到你带了几个同学负责B端的事情，实际上是几个人。

• 正式的xx，实习生xxx。

你能介绍一下你做的事情的规模吗？

• 我们做的是搜索的内容承接端。xxxx。资源量已经达到xxxxx。
• 目前产品的DAU是xxxx，峰值xxxx。PVxxxx。

你们这边B端，B端也有这么多流量吗。

• 一方面是内容引入，这块是不固定的。xxxx。清洗数据，会多一些。
• 另一方面，提供openapi给C端调用。这块的量和C端是一致的。

为什么会选择GDP和GIN框架呢。

• 和厂内环境有关系。升级维护都由GDP维护方负责。自己选择其他框架，就需要自己维护。
• 另一方面，GDP会把厂内的基础服务接入封装好。例如，BD的微服务使用BD名字服务做服务发现。GDP封装了BNS客户端，使用GDP之后，就可以很方面的和其他服务交互。还可以一键部署监控等。
  GORM呢？
• 没有特别考虑。
  你知道GORM的开发者在字节吗？
• 这个不是很了解。

你们的API到真正部署为RPC服务，这个是怎么做的。

• 首先是服务部署。所有的机器都会挂载到一个节点上面，然后绑定BNS，就会生成一个类似域名的东西。把名字给到使用端。使用端就可以通过名字发现服务的IP地址。
• 它们的请求打过来之后。我们使用go编写一些接口，接收请求，处理。

你们服务端用的是什么框架呢？

• rpc这块没用特别的框架，就是用GDP自带的ral服务，能够发送给BNS对应的服务。json是自己解包编码的。

你们提供微服务能力是怎么做的。这块好像没讲到。

• 我们提供了一个接口。它们把数据封装成json。（这块讲的有问题）

所以C端的服务只是简单的访问数据库，是吗？

• 有的时候是。有的时候会有其他处理。

没有一个服务提供标准能力的，是吗？比如一个rpc服务，给C端和B端。

• 我的接口从业务上来说是通用的。（这块我理解有问题）

你是B端的负责人，这块的总体架构设计是怎么考虑的？

• 总体分为离线处理和C端输出两大块。
• 刚开始搭建在一个集群里，后来由于处理量的增大，把很多离线处理放在物理机。对于OPENAPI，会放到一个单独的集群里，对外使用。做了一个分隔，防止线上线下影响。（这个回答其实也没有到点上）

你怎么保证内容输出的过程中，内容是合规的。

• 这块我们通过数据状态控制。
• 对外输出时，有两种。一种是spider推送。如果内容有问题，就会推送下架。还有一方面是站搜。

那你怎么检测内容是否合规。

• 一方面是正常的生产流程。待审核，审核通过之后上线。另一方面，是线上线，后机审。通过风控中台。

上下架是怎么做的。

• 主存储是在MySQL，然后会用到ES做检索。所以发送上下架请求之后。接口首先会在MySQL开事务，保证表数据一致性。然后通过消息队列发送给后续的处理端。比如，风控，ES。

有人依赖你的数据，那你怎么上下架呢。

• 把消息发送给消息队列。使用方会接收这个消息，处理。

讲讲系统瓶颈的优化怎么做的。

• 平台初期定位有关。初期业务数据量很少，所以使用单机的MySQL存储。但是后来，我们需要扩量，设计就无法满足。单机MySQL的容量和性能无法满足要求。后来调研使用DRDS。它就封装了多个MySQL实例。
• 这也带来了一致性的问题。比如如何保证多个分片数据的一致性。我们会把数据先存到临时kv表里，然后通过消息队列，把数据同步到分布式数据库。但是由于消息队列不保证顺序处理任务，所以加了一个版本号，服务只会把高版本号的数据更新到数据库。
• 还有一个点，有点记不清了。
• 还有问题，如果保证数据成功发送给消息队列。因为厂内的消息队列发送容易失败。所以用MySQL表存储了待发送数据。流程是这样的。xxxxx。（这里讲的不够到位）

除了发送的时候丢消息，还有其他地方会丢消息。

• 有可能消息丢了，没处理。可以用兜底脚本处理数据。

消息队列内部会不会丢消息

• 是有可能的。但是具体的原理这块没有细看。

DRDS的分片键是什么

• 数据唯一ID，通过hash，分到分片。

资源ID是怎么生成的

• 最初想做不依赖MySQL的方式。因为MySQL有局限。我们是通过时间戳加上随机数。但是这样可能导致重复。后来用redis做了去重。使用incr，如果发现key返回2，说明有人用过了。
• 我后来也想了一下，如果重新设计，我可以把随机数换成机器号+进程号就可以解决这个问题，不需要Redis。
  还有别的方案吗。有参考业界的吗？
• 这个想法就是参考了雪花算法。
• 业内的话，还可以通过多个表主键自增，加上不同的前缀。这样就可以解决单点问题。

如果我们现在的确发现DRDS数据不均匀了，怎么解决。

• 我们之前也发现过不均匀。一个ID存储很多数据。说明ID分片不合适。

那你知道DRDS的hash是怎么做

• 具体用的hash函数没有公开。如果我们去做的话，可以用crc32，然后取模数据。
  你们初始化的分片是多大。
• 初始的时候只有2个分片。（这块说错了。两个分片，每个分片512个表。）

写代码

给定一个 m x n 二维字符网格 board 和一个字符串单词 word 。如果 word 存在于网格中，返回 true ；否则，返回 false 。
输入： board = [["A","B","C","E"],["S","F","C","S"],["A","D","E","E"]], word = "ABCCED"
输出： true

https://leetcode.cn/problems/word-search/description/

（我只想到递归遍历。没想到更好的解法。并且最后写出来的代码结果有问题。写了15分钟，最后没改对。）

问问题

你觉得工作期间的收获是什么

• 刚开始，更偏向技术点。后期，会偏向于项目，分工合作方面。以及作为研发，对业务的思考，去想能给业务带来什么收益，不仅仅是开发出来。衡量投入产出比。
• 另一方面，是自己学习能力，总结能力，各方面综合的提升。

反问

您觉得我还有哪些可以提高的点

• 这块目前不方便，很容易涉及对候选人的面试评价。

面试是三轮吗

• 技术是三轮。也可能会加面。

总结

字节的面试特点：

• 基本上都是围绕简历上的项目和自己负责的业务展开。其实很容易引导面试官。
• 很少八股文。这点非常赞。
• 但是强要求算法题，一定要写出来。

所以要提前挖掘好，熟悉好自己的项目。多刷题。

对于我这次面试来说。

• 一方面是自己准备不足，对自己的项目不够熟悉。
• 另一方面，算法不够。
• 还有一点，没有很好的把厂内的技术点和外界通用的点融合好，或者表达好，造成面试官认为项目经验不够匹配。

几点建议（研发大头兵岗位）：

• 一定要挖掘好项目的难点亮点。想好怎么说，最好能自己排练一遍。
• 算法题多刷，反复刷。这是日积月累的事情。
• 做好外界社区通用技术和内部技术的思维融合。能熟悉内部对应的开源组件更好。有通用性的东西，更容易匹配面试官的考察点。
• 一定要平时积累，多思考总结，最终效果是做好随时面试的准备，才有底气，才不怕失业。