互联网公司理想架构探讨，字节跳动算法工程师面试

DR模式（直接路由）

改写请求报文的MAC地址，将请求发送到真实服务器，而真实服务器将响应直接返回给客户。要求调度器与真实服务器都有一块网卡连在同一物理网段上，并且真实服务器需要配置VIP。

NAT模式 （网络地址转换）

调度器重写请求报文的目标地址，根据预设的调度算法，将请求分派给后端的真实服务器；真实服务器的响应报文通过调度器时，报文的源地址被重写，再返回给客户，完成整个负载调度过程。要求负载均衡需要以网关的形式存在于网络中。

TUNNEL模式

调度器把请求报文通过IP隧道转发至真实服务器，而真实服务器将响应直接返回给客户，所以调度器只处理请求报文。要求真实服务器支持隧道协议和配置VIP。

FULL NAT模式

在NAT模式的基础上做一次源地址转换（即SNAT），做SNAT的好处是可以让应答流量经过正常的三层路由回到负载均衡上，这样负载均衡就不需要以网关的形式存在于网络中了。性能要逊色于NAT模式，真实服务器会丢失客户端的真实IP地址。

调度算法

• 轮询

将外部请求按顺序轮流分配到集群中的真实服务器上，它均等地对待每一台服务器，而不管服务器上实际的连接数和系统负载。

• 加权轮询

权值越大分配到的访问概率越高，主要用于后端每台服务器性能不均衡的情况下，达到合理有效的地利用主机资源。

• 最少连接

将网络请求调度到已建立的链接数最少的服务器上。如果集群系统的真实服务器具有相近的系统性能，采用"最小连接"调度算法可以较好地均衡负载

• 哈希

将指定的Key的哈希值与服务器数目进行取模运算，获取要求的服务器的序号

• 一致性哈希

考虑到分布式系统每个节点都有可能失效，并且新的节点很可能动态的增加进来，一致性哈希可以保证当系统的节点数目发生变化时尽可能减少访问节点的移动。

API网关

---

API网关（API Gateway）是一个服务器集群，对外的唯一入口。从面向对象设计的角度看，它与外观模式类似。API网关封装了系统内部架构，对外提供REST/HTTP的访问API。同时还具有其它非业务相关的职责，如身份验证、监控、负载均衡、缓存、流量控制等。

API管理

API网关核心功能是 API 管理。提供 API 的完整生命周期管理，包括创建、维护、发布、运行、下线等基础功能；提供测试，预发布，发布等多种环境；提供版本管理，版本回滚。

API配置包括 前端配置 和 后端配置 。前端配置指的是Http相关的配置，如HTTP 方法、URL路径，请求参数等。后端配置指的是微服务的相关配置，如服务名称、服务参数等。这样通过API配置，就完成了前端Http到后端微服务的转换。

全异步

由于API网关主要处理的是网络I/O，那么通过非阻塞I/O以及I/O多路复用，就可以达到使用少量线程承载海量并发处理，避免线程上下文切换，大大增加系统吞吐量，减少机器成本。

常用解决方案有 Tomcat/Jetty+NIO+servlet3.1 和 Netty+NIO，这里推荐Netty+NIO，能实现更高的吞吐量。Spring 5.0 推出的WebFlux反应式编程模型，特点是异步的、事件驱动的、非阻塞，内部就是基于Netty+NIO 或者 Servlet 3.1 Non-Blocking IO容器 实现的。

链式处理

链式处理即通过责任链模式，基于 Filter 链的方式提供了网关基本的功能，例如：路由、协议转换、缓存、限流、监控、日志。也可以根据实际的业务需要进行扩展，但注意不要做耗时操作。

Spring cloud gateway （基于 Spring WebFlux）的工作机制大体如下：

1. Gateway 接收客户端请求。

2. 客户端请求与路由信息进行匹配，匹配成功的才能够被发往相应的下游服务。

3. 请求经过 Filter 过滤器链，执行 pre 处理逻辑，如修改请求头信息等。

4. 请求被转发至下游服务并返回响应。

5. 响应经过 Filter 过滤器链，执行 post 处理逻辑。

6. 向客户端响应应答。

请求限流

请求限流是在面对未知流量的情况下，防止系统被冲垮的最后一道有效的防线。可以针对集群、业务系统和具体API维度进行限流。

具体实现可以分为集群版和单机版，区别就是集群版是使用后端统一缓存如Redis存储数据，但有一定的性能损耗；单机版则在本机内存中进行存储（推荐）。

常用的限流算法：计数器、漏桶、令牌桶（推荐）

熔断降级

服务熔断

当下游的服务因为某种原因突然变得不可用或响应过慢，上游服务为了保证自己整体服务的可用性，不再继续调用目标服务，直接返回，快速释放资源。如果目标服务情况好转则恢复调用。

熔断是为了解决服务雪崩，特别是在微服务体系下，通常在框架层面进行处理。内部机制采用的是断路器模式，其内部状态转换图如下：

服务降级

当负荷超出系统整体负载承受能力时，为了保证核心服务的可用，通常可以对非核心服务进行降级，如果返回缓存内容或者直接返回。

服务降级的粒度可以是API维度、功能维度、甚至是系统维度，但是都需要事前进行服务级别的梳理和定义。

真实场景下，通常是在服务器负载超出阈值报警之后，管理员决定是扩容还是降级。

业务隔离

API网关统一了非业务层面的处理，但如果有业务处理的逻辑，不同业务之间就可能会相互影响。要进行业务系统的隔离，通常可以采用线程池隔离和集群隔离，但对于Java而言，线程是比较重的资源，推荐使用集群隔离。

PUSH推送

---

消息推送系统 针对不同的场景推出多种推送类型，满足用户的个性化推送需求，并集成了苹果、华为、小米、FCM 等厂商渠道的推送功能，在提供控制台快速推送能力的同时，也提供了服务端接入方案，方便用户快速集成移动终端推送功能，与用户保持互动，从而有效地提高用户留存率，提升用户体验。

设备建连、注册、绑定用户流程

消息推送过程

在非常多的业务场景中，当业务发生时用户未必在线，也未必有网络。因此，在 MPS 中所有消息均会被持久化。业务发生时，MPS 会尝试做一次推送（第三方渠道推送或自建的TCP 连接推送）。自建渠道中，会通过查询缓存来判断用户的终端是否有 TCP 连接，如果存在则推送，客户端收到推送消息后，会给服务端回执，服务端即可更新消息状态。如果推送失败，或者回执丢失，用户在下一次建立连接时，会重新接受消息通知，同时客户端会进行逻辑去重。

微服务体系

---

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新

如果你觉得这些内容对你有帮助，可以添加V获取：vip1024b （备注Java）

总目录展示

该笔记共八个节点（由浅入深），分为三大模块。

高性能。 秒杀涉及大量的并发读和并发写，因此支持高并发访问这点非常关键。该笔记将从设计数据的动静分离方案、热点的发现与隔离、请求的削峰与分层过滤、服务端的极致优化这4个方面重点介绍。

一致性。 秒杀中商品减库存的实现方式同样关键。可想而知，有限数量的商品在同一时刻被很多倍的请求同时来减库存，减库存又分为“拍下减库存”“付款减库存”以及预扣等几种，在大并发更新的过程中都要保证数据的准确性，其难度可想而知。因此，将用一个节点来专门讲解如何设计秒杀减库存方案。

高可用。 虽然介绍了很多极致的优化思路，但现实中总难免出现一些我们考虑不到的情况，所以要保证系统的高可用和正确性，还要设计一个PlanB来兜底，以便在最坏情况发生时仍然能够从容应对。笔记的最后，将带你思考可以从哪些环节来设计兜底方案。

---

篇幅有限，无法一个模块一个模块详细的展示（这些要点都收集在了这份《高并发秒杀顶级教程》里），麻烦各位转发一下（可以帮助更多的人看到哟！）

由于内容太多，这里只截取部分的内容。
设计秒杀减库存方案。

高可用。 虽然介绍了很多极致的优化思路，但现实中总难免出现一些我们考虑不到的情况，所以要保证系统的高可用和正确性，还要设计一个PlanB来兜底，以便在最坏情况发生时仍然能够从容应对。笔记的最后，将带你思考可以从哪些环节来设计兜底方案。

---

篇幅有限，无法一个模块一个模块详细的展示（这些要点都收集在了这份《高并发秒杀顶级教程》里），麻烦各位转发一下（可以帮助更多的人看到哟！）

[外链图片转存中…(img-VMJUu2lH-1712054144792)]

[外链图片转存中…(img-oSkYlWvd-1712054144792)]

由于内容太多，这里只截取部分的内容。