创业公司-国际支付-1面

2024年4月22日 下午 6:49|37分钟 10秒

关键词:

订单、索引、数据库、数组、电商、商家、支付宝、磁盘、存储、跨境后台、报关主体、联合索引、跨境电商、排序算法、数据同步、操作日志、跨境报关、内存数据

文字记录:

喂，能听到我声音吗？

听到。你好。

准备好了吗？好了。行，那我们就正式开始，你先简单做一下自我介绍，好吧？好。

自我介绍

嗯嗯，OK。那我们找一个你参与过的那个项目，你觉得做得比较好，或者你自己比较熟悉的，我们重点聊一下，敞开聊一下，好吧？噢，好。

噢，我的，那我先讲一下我实际干了什么，然后再具体聊一下某个需求吧。嗯，好，我是国际电商部门的，然后我主要是跨境英语小组的，主要是有三大块内容，第一块的话就是我是专，就是我们负责去，我负责我们跨境电商后台系统的一些小需求的一些迭代。第二块的话就是我们跨境计划域有，因为我们刚从那个钉钉切到飞书，然后它的监控的话并不是很完善，所以的话第二块就是负责我们这个飞书监控机器人的一个编写。第三块的话就是参与我们小组内的一些技术改造的一些工作。

可以，那这里边的话我们就聊一个你做的那个东西，好吧？具体的那个项目的细节让你给我介绍一下。

好，那我说一下，就是我们最之前做的一个电商主体可配置切换吧。嗯，首先的话，我们跨境电商后台它主要是有三大部分的一个功能，第一块的话主要是负责我们就是跨境商品的一个三单报关，包括了我们订单报关、运单报关以及我们的支付报关。这里的话主要是服务于我们两个端，一个是我们的得物 APPC 端，一个是我们电跨境电商后台是 b 端的。 g 端的话主要是用户在支付完成之后，他会去就是调用，如果是全球购里面的商品，他就会去调我们的支付报关。

第二块的话就是我们pink，就是我们仓得物仓端它有个 pink 软件，在发货的时候他会去调用我们跨境服务的，这个就是跨境服务里边订运单报关的那个接口，去进行一个运单报关。还有就是我们订单报关，订单报关的话主要也是在我们发货之后，他会去调我们这个运单报关，然后这是我们三单报关的一个功能。

第二块的话就是我们需要，就是涉及到我们商品出海和我们入境，他需要去进行一个在我们海关那里面进行一个备案，然后这个部分的话也是我们跨境后台在做，主要是给运营人员去对我们这个跨境的一些商品进行一个备案的一些审批等等。嗯嗯，还有还有就是我们第三块的话，就是它就是我们全国有非常多的一些口岸，然后我们商品具体走哪个口岸？然后它具体的报关主体是什么？然后它会有一系列的规则，然后也是在我们的跨境后台进行一个配置的。然后之，然后我讲一下具体的一个需求，就是我们电跨境就是电商主体可配置，一开始的话就是我们的，就是我们跨境报关的主体的话主要有三个，一个是我们得物主体的，一个是我们三业主体的，还有就是我们第三方的。然后当时的话就是常背景的话，就是我们深圳那边出了一个政策，就是如果报关的一些主体的话，是深圳注册的一些企业，然后它可以去退税六七八百万嘛。然后当时的话就是我们平时之前在开发这个三单报关功能的时候，它报关的主体的话全部是写死在我们那个配置中心里边的。然后我们用的是Nicos，然后他自己自研了一个叫做 AR k 的，然后通过我们的那个 AR k 进行一个下发的，相当于直接写死在我们那个代码里边了。然后现在的话就是我们需要去能够支持我们不同那个海关的那个就是报关主体能够去动态进行一个配切换嘛。所以的话我们就是需要去将我们这个就是注册中心里面的东西重新迁移到我们这个数据库里边。

而关于在，还有就是关于我们如何去选择这个是跟我们我举个例子，就比如我们在得物上面，得物全球购里边买了一个鞋子，那么这个鞋子的话它会有一个它的是从哪里去进口的？然后它的价格是多少？然后我们在跨境后台里边，就是我之前说的它会有一系列规则，会去根据我们的金额，还有发货地址等一些其他的规则去进行一些判断，然后判断你到底是走哪个口岸，然后我们的报关主体的话，它其实是跟我们这个口岸进行一个关联的。所以我们的改动的核心的话，就是在我们原本那个判断到底走哪个口岸那个地方去给它绑定上我们报关的一个主体。

主要这里边的话，其实你说白了，你就是两三块一块，就是那个海外的，就是出口的那个报关，一个就是进口的报关，是吧？

嗯，主要是进口。

对，就然后第三块就是那个相当于是你走哪个，走，你是哪个公司，走哪个公司的主体，然后去报哪个官，然后这一块是你们做的一个配置化的管理，是吧？相当是一个路由，是吧？嗯，对，对，就这三块嘛。

对支付的话是这个逻辑。嗯，支付的话是调用我们支付宝第三方那个接口来实现的，支付宝管。然后运单报关的话它还需要去跟我们那个运营商去协商，然后到底走哪个报关主体？它有的运营商的话是可以支持我们下发的，然后有的是不支持的，它只能够去走我们运营商那个主体。

了解了解，行，想一下你报关这里边的话，就比如说你这个数据库是主要的表是怎么设计的？就我们就拿那个，你主要就是进口的那个报关嘛？这里边的话你给我介绍一下这一块的数据库的大概的那个实现的思路。

报关这一块的话我可能不记得，不太清楚了，它主要曝光的话就是进口报关，它主要就是通过一个字段去判断一下我们当前这个商品，就是当前订单一个状态，然后他需要一开始的话，那订单的话其实是得物那边的订单，然后它里边的话会有一部分涉及到上传到我们这个就是报跨境后台这边，然后它里边的话会涉及到就是它会去进自动发一个MQ，然后去进行一个报关。然后是如果报关不成功的话，会在我们跨境后台要求我们运营自己去手动进行一个重新的一个报关的，重新报关的一个申报。

OK，然后这里边的话我想一想你自动的一个申报。嗯，能明白啊。我举个我，我举一个具体的例子，就比如说现在有一个你这个曝光的这个表，比如说你曝光你可能叫订单或者是什么的之类的，是吧？然后现在这个表的话，可能每天的数据量可能有 100 万，然后我需要你给我第一个场景，就是说我拿了一个订单 ID 进来，我想查一下这个订单他的那个曝光的情况啊。这是第一个场景，然后第二个场景就是说我想统计一下昨天有多少个报关的订单，这两个的话你怎么去写这个SQL？

现在就是根据订单 ID 查一下那个报关的一个状态，然后还有就是查一下昨天那个报关什么东西。

嗯，你统计一下，就是昨天新增了多少个爆单的单子哦。

首先的话那直根据查询状态肯定就直接根据我们那个订单 i 订单 ID 进行查，然后直接把我们订单状态只查一个 select state，然后 from 那张表，然后 where 订单 ID 等于什么？这里的话我们肯定是做了那个分库分表的，然后他那个分辨 key 的话，肯定是用我们那个订单 ID 跟我们 user ID 做了一个组合。

嗯，怎么做组合的？那个分片你说一下。

就是用的基因法，我们这就是我讲一下架构，我们这边订单架构的话就是它我们会梳理查询场景最主要的核心场景的话就是根据订单号查，还有就是根据我们那个用户 ID 查嘛。所以的话我们就当时的话就是根据我们订单 ID 组合我们的那个用户 ID 做了基因法进行一个分片嘛。

还有就是我们商家端的话，查询的话他需要去根据订单号查，还要需要去根据他商户号查，还要需要去根据他一些其他一些复杂的查询条件进行一个查询。然后当时的话它其实的话就是它就是用数据同步，然后把我们 c 端的那部分数据，然后全部同步到了一个 b 端的一个数据库里边，然后根据我们那个商户ID，加上我们那个用订那个商户 ID 和订单 ID 进行一个组合，然后进行重新的分片。

这样的主要目的的话，其实就是做我们 b 端那个数据库跟我们 c 端数据库的一个隔离，然后后续的话可能会还会涉及到一些复杂查询的场景，这部分的话我们其实都是同步到我们那个 ES 里面去进行一个查询的。还有就是后面的话其实也是出现了一些大商家的问题，然后面的话导致了一些大量的一些慢SQL，也是产生了一些客诉。然后我们平时的话，其实解决大商家的问题就是可能会去给我们大商家去搞一个专库专表，但是我们这里的话其实并没有这样去进行一个解决。

我们这样这里的解决方案的话，它其实的话就是用我们那个TDB， TDB 就是我们那个 MySQL 的分布式数据库，之前在调研的时候其实经过了大量的压测，比如我们会用那个 33030 倍的那个 30 倍那个 circle 进行一个回放，流量进行一个回放，但是它的性能的话，它其实是比那个用比 MySQL 集群要好的，所以的话我们最终的采用那个方案的话，其实就是商端，商家端的话其实就是在把我们那个商家端的数据全部的就是我们把原同原本同步到商家。

就是 b 端的那个数据库里边的数据重新同步到我们的 TDB 里边去，然后我们以后商家端的一些核心的一些查询的话，全部去走我们的 TDB 进行了实现。然后这样的话就解决，主要是解决大商家的一个问题，还有就是我们后续的话，我们每天 100 万订单，然后增长的速度特别快，然后就会导致我们这个订单表这个膨胀的特别快嘛。然后我们现在线上环境的话，其实都是用那个阿里云的那个 SSD 高速硬盘，然后这样存储价值比较高，但是从我们这个统计的角度来讲，就是如果我们当前的订单如果超过了三个月，并且它已经到达中泰，那么它这个查询的量，查询的那些量的话是非常低的，如果我们把它全部存储在我们这个高，就是价值量比较高的这个硬盘上面的话，其实磁盘上面的话其实就是比较浪费，然后但是这个订单的话又属于我们这个企业的一些核心数据，然后我们又不能够去把它进行一个删除。所以的话后续的话其实我们也是做，就是做我们数据的一个冷热分离，然后我们现在全部冷热的分离的那个方案的话，其实也是用的那个TDB。

明白。然后这里边的话就我举个例子，就刚才的那个例子，我，我现在想去查那个就你刚才的那个单，你不是数据量也挺大的，然后比如说我想去统计某一天的那个新增的那个订单数量，你这个 SQL 应该怎么写？

这个的话一般来说我们就直接用那个，一般来说的话统计订单的话，其实我们并不会直接查那个数据库，一般来说都是用那个数仓写的。但是如果你说一定要用数据库，一般就是直接 select count 型，然后附上那张表，然后加个 VR 条件时间范围。

那所以怎么加索引哦？对。

一般来我们平时的话就是用那个，就比如可能会涉及到订单 ID 跟我们那个时间进行一个范围查询，一般来说就是建立一堆那个联合索引，用那个订单 ID 和我们时间。这要看具体查询条件了，其实。

那这个，所以我们就只说现在的这个就懂记的这个，你看 SQL 不是slack，然后 cache from，嗯， table name，然后是 where 那个时间嘛？是吧？嗯，那你这个怎么加呢？

那肯定根据，那肯定用那个，根据 create time 加索引。

根据 create time 加索引加一个什么样的索引呢？是联合索引？唯一索引还是组件索引？还是什么索引？

又是一个普通索引？在当前场景下是普通水印，但是我们可平时它肯定会涉及到一些大量的跟大量的一些其他查询条件，跟我们时间进行一个一起查，当做条件一起看嘛。在当前场景下如果只考虑这个时间的话，肯定是只建立一个时间的一个普通索引。

MySQL 里边搭的这个索引是怎么实现的？

索引就是用的那个 b 加速，底层用一个链表，然后是底层的话就是一个链表，然后上面的话就是用了一堆这个，是那个 b 加树那个结构吗？树的结构。

那这里边的话， b 加速这个浦东的这个索引的话，它跟那个我们的组件索引有什么不一样吗？

组件索引的话，它其实就是最大区别的话，就是关于我们最底层的那个一大串的那个链表，它到具体是存储我们这个ID，还是具体存储我们完整的一条行的一个数据嘛？如果是主键索引的话，那么它底层那个叶子列的就是存储的某完整数据。如果是因为我们主键索引它只有一个，所以然后的话非聚数索引的话就是非主键索引，然后它底层的话，如果它那个叶子，那个非叶子节点上面存储的都是我们对应的索引值，然后如果是叶子节点的话，就是存储我们的那个对应的一个ID，然后我们再去根据 ID 回表查我们那个组件索引，这个的话主要就是防止我们数据重复存储，这样的话这个冗余就过多了。然后他查询效率的话，查询我维护起来就比较麻烦。

那其实如果是我不回表，那不是更简单嘛？我所有的东西我都存在，那个什么冗余一分，是吧？我以时间换，我以攻坚换时间，这样不可以。

吗？可以是可以，但是这个成本太高了，相当于如果你有 100 万数据订单的话，有2000G，然后你每一个索引都存一遍，然后我们每个订单表里面可能会存创建四五个索引，那么直接数据量飙升 5 倍。

了，OK，在数据库里边的事物都有哪几个特性？

acid 吗？原子性、一致性、隔离性、持久性？

那他这几个是怎么去实现的呢？

噢，好，首先的话就是我们持久性。首先的话从我们 MySQL 的一个架构来讲的话，它其实分为我们的内存结构和我们的磁盘结构嘛。如果我们去对我们 MySQL 进行一个查询的话，那么他先会去我们的那个 buffer bool 里边去判断一下数据是否存在，如果不存在的话，那么再去磁盘进行一个磁盘IO。然后把我们 bug 里边的数据读到我们这个内存里面去，然后如果是我们的一些更新修改一些操作的话，它也会去优先去修改我们内存里的一些数据，如果内存里边数据不存在的话，那么它又会去把这个数据的变化暂存在我们那个 change buffer 里边。

等到下一次我们对这个修改数据进行一个读取的时候读取，把它读取到内存里面，然后再去将我们 change buffer 里和我们的 buffer pull 里面的数据进行一个合并，然后我们就会得到我们修改后的一个数据，叫做张叶。然后最后的话他在，他会在隔一段时间定，隔一段时间后去对我们张叶数据对他进行一个刷盘。

到我们磁盘吗？之所以不立刻进行刷盘的话，它其实就是因为我们它需要去搜旋转，然后它其实是属于这个随机的一个IO，随机 IO 的效率是比较低的。然后的话它其实会用一种叫做 w AR 的机制，就是先写日志，在每次提交事务的时候，它都会优先去把我们对应的操作日志，也就是我们那个 radio log 写到我们刷盘，到我们的磁盘，因为我们那个日志的话它其实是属于追加，它是属于我们这个顺序 IO 的，所以它效率是比较高的。然后后续在我们刷盘的时候，如果数据库突然宕机了，那我们内存数据的话，内存里面的数据可能就突然丢失了，这样的话我们就没有办法去买，保证我们那个 MySQL 持久性，所以它其实会去通过我们那个 undo log 来进行一个数据的一个恢复嘛。所以的话就是我们 on 那个 radio log 的话，主要就是通保证我们事物的这个持久性的嘛。

还有的话就是我们事物之间的隔离性，事物的话其实我们主要有三个并发事物，主要有三个场景，就是读读读写，以及我们的写写，读读读的话不会出现什么问题，然后主要，然后写写的话一般来说就是加锁实现，然后主要是我们这个读写，然后读写的话其实要考虑到我们这个不同的一些事物隔离级别嘛。

比如我们的四种隔离比别读未提交读语提交可重复读，已经有我们的串行化，它主要是通过我们这个 MVCC 机制加锁来去建的，如果我们没有是 MVC seed 话，它其实就是我们类似于就是如果我们每如果读写并发的话，那么它就是它就退化成我们的串行化了，这效率非常低嘛。所以的话就是它主要是利用我们的MVCC，也就是我们那个快照读和当前读来实现，就是来实现我们这个并发事物的一个高性能的一个读嘛。然后我们的 i v c seed 话来转，就是我们多版本分下控制，主要是依赖我们那个事务 ID 跟我们那个版本列来实现的，它会去，它会优先去拿到我们这是当前活跃事务 ID 最小值，最大值以当前 15 ID 的一个集合，然后去根据一系列的规则，然后去判断一下，去用我们那个 undo log 版本链上到底选到底，就选择到底选择哪个版本嘛。

还有就是我们，嗯，如果事物的隔离级别是读已提交的话，那么它就是它每次读的时候它都会生成一个快照，这样的话就能够去保证我们读到的是最新的一个提交的数据，如果是我们可重复的话，那么就要求我们在一次事务里边一次读和多次读到的数据是相同的，所以的话它其实就是在第一次读的时候去生成了这个数据的一个快照，然后我们后续的话就直接复用这个。

OK，假设有这么一个数组，然后，嗯，整形的数组，然后我想从这里边找那个第二大的数，你觉得怎么找。

一个数组？然后找第二大的数？对。这个的话可以就是直数组的，直接把数组变了一遍，然后每次找到，不对不对，让我想一下，这是找第一个，找最大的元素。那就直接把速度进行一个排序呗。

嗯，怎么排呢？

那排序算法有很多，快排、堆排序，还有什么？还有那个归并排序。

你比如说你，就你，你选一种。

选一种。

就这种。

规避。

归变。就这个我找第二大的，然后你就先排序，用归并去排，排完了之后。

那不就，那我们在数组里不要有序的，然后我们直接拿到数组里边索引是 2 的嘛。

那我这个比如说我这个数组最大的值得有那个总负的，比如说我这个数组，我就是叫什么122333333，我有很多个 3 最大， 3 是最大的，那你现在按照你这个逻辑取的岂不是最大的数返回了？

我有点没有理解。就是你有一串是一个数组，然后你要去找里边最大的第二个元素。

第二大的元素就比如说我这个数组，我再具体一点，我这个数组有 10 个元素，1HA，这都是各有一个，然后剩下 8 个都是3。按照你刚才的这个算法拿到了这个数，第二大的数是不是3？

能听到吗。

能听到，刚卡了好像。

其实刚才我说的这个场景你能 get 到了吧？嗯，明白了。

就是我们找重复元素的时候，如果它，如果是，如果是，如果它有重，如果找到第二大的话是重复元素会怎么样？

那你就不对了，就是我想找的是第二大的，你给我返回的是第一大的，是吧？

哦，是这个意思，明白。

先进一个排序，然后再统统遍历一遍。怎么便利你？就比如从头拿到第一个元素，然后再从头往后遍历，然后判断一下第二个元素跟第一个元素是否相等，为在这个过程去统计一下出现了几个不同的。

你觉得你这一整套操作下来，时间复杂度是多少？

n 加 n log 你知道吗？

n 减 n log，嗯，也就是 n log 呗，是吧？嗯，OK。那如果说我变一下，我比如说我现在我想找第5大的，你这个怎么弄？思考有思路吗？

最大这个的话，如果我再换一种算法的话，感觉是就是可以用那个叫什么，那个叫叫。哎呀，那个，那个叫啥？饭碗来着？我想一想，这个好像可以用那个卖爆发排序进行优化吧？我感觉就比如他不是每次要找到那个最大的那个，然后往右移到最后一个导航也不行，这个是不是可以用那个堆啊？我记得好像有个最大最小那个堆，是吧？

这样的话好像想不出来优化。

嗯，其实你刚才已经提到了，你就是用。

那个最大堆了，大根堆。对。

对对，大根堆或者小跟堆嘛，是吧？

好久没看这个了。

嗯嗯，行。OK，我这边问题基本上问完，你看有什么想问我的吗？

就是主要是做哪方面业务的，我还蛮好奇的。

我们是做那个国际支付的。

然后是做。你说国际支付就是像支付宝那样吗？对接银行那种。对对对对对。就是问个问题为，就是现在市面上有这么多支付，为什么您还想就是做支付呢？蛮好奇的。

我们不做国内的支付，我们是做国际的支付。

对，国际不知道也很多嘛？国际上面。

嗯，怎么说呢？其实多跟你好不好用这个是两个概念的，就是你，嗯，我不知道你有没有经常出国，或者是说你做得物的这个海外的，这个第三的话其实可能也会遇到。

一些，对，我们主要用的就是那个 pay 什么的。

因为你要是海外的这个支付的话，其实来讲怎么说呢？它的整个支付其实稳定性还是挺低的，针对不同的场景的，不同的国家的这个差异很大。你想当年在国内，在阿里支付宝，完全支付宝跟微信完全懂车之间其实也有很多的这种支付的这种公司，是吧？因为大家都是属于一个在这个赛道里面去竞争的一个情况，然后海外这一块确实现在相对来说的需求量很大，然后但是做的都不太好，实话讲都不太好，所以这里边是一个机会点吧。

但如果用我们一个中国人的这个视角去看这个东西，就觉得挺不能理解的，这个东西为什么你们还做了这么垃圾？但外国人来看我们也是觉得，哎呀你们中国人真他妈做的真好。是吧？那我们就去尝试一下呗。嗯，这个需求量很大。而且现在大的赛道上来讲的话，中国有大量的这种企业去做珠海的业务嘛。

像得物这边做国际的，他那个现在都是在亏钱的，像我们之现在最近做的一个那个需求是那个做商详的那个，他 QVS 只有几个。

这个东西跟支付这个东西跟别的业务还不大一样。就是怎么说呢？就是支付这个东西本身我们做这个首先它是一个 ToB 的一个业务，然后的话我们比如说不管你接的是是是是是哪个渠道，是吧？我们只要就是说只要你有流量过来了，那我们就理所应当的能抽一笔佣金。你跟别的业务不一样，你比如说做什么网、做什么电商，或者是做什么游戏，或者做什么社交，你第一步总得先把用户吸引过来，吸引过来之后你想方设法要让他在你的平台上去成交，不管是以低价做百本买卖去吸引他还是怎么样也好，是吧？总得要去想尽各种办法，但支付这个东西不一样，你来了就肯定是你只要用了我这个东西，我就立马能收钱，我不用去想那么多，能听到我的声音吗？对，所以的话这个可能支付的业务跟其他很多的业务不太一样的点就在这。

别的没有什么问题，就是好奇。

那我觉得这一块做海外的市场的话，我觉得大的思路肯定是，肯定也是没什么问题的。而且做支付这个东西，你的整体来讲我觉得思路是没什么大的问题的，就看能不能折腾起来了。就这个东西事在人为嘛？你现在是在外边实习还是在学校啊？

现在是。

在实习。那我看你是在那个还在得物实习，是吧？嗯，那你为什么不留在得物呢？他没。

法来，他没法留。

就是留不下来，是吧？嗯，就没有 head count。

对，我就是，我不是校招的，就没有实际转正这个事情啊。

明白，那就在那你想找一份什么样的工作？

其实我对支付还是挺感兴趣的。我但是就是我现在应聘来源感觉就是他们支付的全都要求硕士以上。

呵呵，现在稍微好点的公司都各种卷嘛。

对，全是做支付的，全都是硕士以上，他在做。

嗯，这一块支付确实挑战挺大的，你比如说你做电商，是吧？你可能给人家上架或者上面管理或者什么的，你弄错点什么东西，好像问题也不大。你支付的时候，你人家下单的时候慢点，其实也还好，遇到问题也还好，但是支付这个东西就是直接跟钱打交道嘛，你把商家的钱给算错了，人家是，人家肯定是跟你没完的，或者你自己算错账了，然后你自己就损失了，是吧？所以这个要求还确实是有点高，这个也能理解。然后那你想你现在得物是在上海吗？在的，在上海，是吧？OK，那你就想你未来工作也是想在上海呗？嗯，是，OK，嗯，没问题。然后你期望的薪资是多少？

希望15K。

可以。你在上海是住哪？

住浦东现在。那还好。

OK，那我这边就你是不是还得回学校去答辩呀？你这个答辩是什么？大概什么。

时候？对，我马上离职了，下个月得回去几个。

天气？okay，回去几个星期是吧？大概是什么时候回去？然后什么时候能完成。

五一？五一过了之后我得先休息一下预答辩，然后到5月二十几号开始中答辩。

OK，那就是 5 月份就是得在学校，至少得 6 月份才能回来，是吧？嗯，HMM。行，那我就基本上没什么其他问题了，你要是没有其他问题的话我觉，嗯，我们就今天的面试就先这样，好吧？好好，那就先这样。

嗯嗯，拜拜。嗯嗯，拜拜。