最近社招跳槽，和许多不同公司的大佬交流。有许多让人印象深刻的地方，想着记录一下。

先介绍一下自己大致的经历：之前在开水团，先后参与服务注册中心，七层负载均衡和分布式锁项目，和存储智能运维相关的事情。技术广度上参与的项目足够多，也导致技术深度上不够扎实。

下面选取一些面试时比较有意思的讨论。

阿里云rmq团队二面：

问：分布式锁业界一般是怎么做的？

答：一般分为三类去做分布式锁，基于kv存储，基于zk分布式一致性的组件还有基于数据库。主要是平衡好安全性和性能。比如金融这种一笔不能丢一笔不能错的场景还是得用数据库，使用分布式锁只能起到限流，减少数据库压力的作用。

面试官停顿思考了一下，问：我在想，数据库的话应该要怎么去实现，乐观锁还是悲观锁？是去维护某个锁信息？

答：乐观锁悲观锁不了解（裸面的，不喜欢背八股，刷题靠面头条）。但是数据库可以设置刷盘和acid的隔离级别。一般数据库默认每秒刷一次盘，节点宕机会导致丢一秒的数据。然后在锁信息获取上，主要避免不同的client都认为自己拿到了锁，隔离级别上需要调整一下。有了强一致性的保证，后面功能上问题就不大了。

阿里云中间件团队还是很执着于技术，探讨技术问题为主。后来的三面产品大佬，也是技术出身，问的也很硬核。

携程二面：

问：如果你时间比较多的话，你会怎么优化项目？

我当场懵逼……内心os，时间多是什么鬼？

答：性能上，其实还是从cpu，存储和网络三大方面考虑。比如之前项目的接口优化，我就是提升并发，增加每次传输的数据，减少网络交互次数。存储上接口服务一般没什么优化项。

业务抽象上，做好微服务的划分。项目模块考虑设计模式。代码细节上多用些重构的技巧，提升可理解性。

问：刚刚聊的是技术的角度看的，从用户角度，你会怎么优化平台项目用户体验

答：主要还是方便接入方式上，更多样化。当时按不同的场景，提供不同的接入形式。……

这里用户体验上扯了很久，最后实在不会，缴械投降。基础架构的经历让我很少考虑用户体验，tob的场景用户体验的优先级也是最低的，解决了需求，但是用户体验上不一定好。算是我的盲区。万万没想到的是，会有如果时间多这种假设……

b站三面：

之前对b站不太了解，面试官说他是毛剑。网上一搜好家伙，是个大佬。难怪问题和一些观点鞭辟入里。

B站最近在做网关，感觉碰到了挺大的困难，所以更多感觉是在交流经验。网关的坑深不见底……

问：反爬和wal这些是在nginx上做的嘛？

答：一些基本的配置是的，但是风控的很多规则其实没有放到nginx上。

问：为什么没有放到网关前，要放到后面业务那去？

答：这一部分风控是让业务接入sdk，然后再远处拉规则。后面有一整套的规则体系，数据体系等等。风控和网关也是不同的部门，这里不是特别了解，感觉还是有部门内闭环效率更高的考量。（感觉还是因为公司业务类型多，不同领域的 风控规则都不一致，实际上是比较难放在网关上的）

问：为什么这些功能不放在api网关上做呢？而是放七层负载均衡上。b站这边思路是，七层上只做转发，业务逻辑都放在api网关上。然后配置都动态化。然后使用开源的形式去定标准和规范，避免业务驱动技术，导致许多风险发生。

答：这里有历史原因，以前没有api网关，导致许多功能放在了七层负载均衡上。后续的话，会逐渐做减法，将七层负载均衡上的业务逻辑逐渐下沉到api网关上。这里还是出现了很多问题。

问：nginx变更还是有很高的风险，这里是怎么处理的？

答：这个安全性问题是很严峻的问题。其实如果有测试集群可以先测试，是不错的方式。目前我们只做了配置语法的检测。在用户操作平台上，做了很多限制，安全第一，效率第二。我们整理了往年很多的case和需求，去整理出一些常用的功能。让用户只能使用封装好的功能，不接触nginx方面的配置。相关的配置都是平台生成。然后针对于少数的自定义配置，人工介入干预。

问：注册中心你们有缓存的话，那用户是怎么变更的？

答：代理层收敛了读写接口，用户发起的调用都会到代理层。然后由代理层去对存储层去进行读写操作。

问：那有代理层，有存储层，数据同步是怎么做的？

答：初始化的时候代理层节点缓存全量数据。之后再提供服务。数据一致性由周期从存储层获取，还有gossip流言在代理层节点之间传递最新版本。

问：代理层节点启动注册是怎么做的？有外部的什么管理组建嘛？节点怎么加入membership的？

答：其实是节点自己往zk上写元数据。然后有agent节点去通过域名参数和标签这些，去识别获取分区分片的代理层集群节点。

问：噢，原来你们是做了两层路由。那你们的分区配置这些怎么处理？未来规划是怎么样的？

答：分区集群配置这些不是什么大问题。集群都是在我们手里，不在业务侧。而且集群数量有限一般也就几十个。管理难度并不大。核心还是在节点的管理上，几十万上百万的容器而且业务机器，下一步还是通过mesh，富容器的形式去解决节点管理的问题。

b站的面试官问的，都是网关领域我们曾面临很痛苦的问题。而且解决思路也是之前团队摸索和业界交流了好多才有的思路，都是业界最新的解决方案。在技术和业务的关系上，也点出了我感同身受，经历很痛苦的事情。就是业务驱赶着基础技术，虽然能孵化出很多牛逼的技术来，但也有可能搞出非常诡异不合理的技术方案来。

头条：

做题，做题还是做题…

每一次反问，基本上我都会问团队目标规划还有人力投入。看看靠谱不靠谱。今年社招跳槽行情确实不太行，很多团队都是薛定谔的hc，面着面着就没了。

回答体现候选人的水平，而提问展现团队的情况。