短视频APP相关推荐资源位的高扩展高可用工程实践

Posted 2023-03-31 百度Geek说

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了短视频APP相关推荐资源位的高扩展高可用工程实践相关的知识，希望对你有一定的参考价值。

导读：短视频在如今已经是非常重要的内容载体，在短视频播放时如给予用户进行如相关视频、商品、游戏、活动等优质内容的推荐，不仅能提升用户的使用粘性，也能极大的丰富内容的生态，本文会详细介绍在短视频APP相关页面做内容推荐入口位置的设计实践。

全文3608字，预计阅读时间10分钟

一、背景

1.1 推荐产品的流量精细化运营

搜索行为的用户通常较为明确自己的需求和问题，技术的重心是针对问题返回准确的答案。推荐产品则反之，用户消遣时间是主要的目的，技术的重心是帮助用户挖掘潜在需求，需要通过与用户的交互逐步了解用户的喜好，给予用户提供相应的内容、服务等。如果说用户观看完当前视频再次请求，我们给予推荐新的视频主要是基于用户纬度进行内容推荐，那在当前视频播放时我们在本页面及时推荐一些内容服务就是细化到用户+视频维度，这就是短视频相关资源推荐位的意义和价值。

1.2.资源位示例

1.3 这个位置要具备怎样的能力

通用性：由于短视频内容可能在多个APP或者产品中都会进行分发，并且主要分发形式都是视频列表页、视频落地页等，所以这个位置是共性需求。再此基础上如果每个产品独立去开发这个位置就是重复劳动，成本高昂，所以我们需要一个通用的能力来解决这个问题。

稳定性：短视频的分发的量级是非常大的，并且经常出现在APP首页这样关键的位置，那么服务的稳定性无疑是非常重要的一环，极端情况下服务彻底不可用也不能影响视频播放本身。

扩展性：如示例所示这个位置除了提供视频、文章等内容服务外，还会提供活动推广、游戏下载、商品挂载等服务，这些内容及服务可能来自于各个产品线，怎么快速、低成本的接入管理这些产品线的内容和服务是快速丰富这个位置能力的关键因素。

智能性：这个位置接入的内容和服务足够多后，更重要的就是给予用户推荐更合适的内容和服务，以及在一些服务的性能出现问题进行降级，让这个位置充分的发挥其价值。

二、设计与实践

2.1 抽象化、标准化解决通用性问题

资源位最核心的能力就是：

1. 给谁分发展示

2. 分发什么内容

由此可以抽象出以下位置分发能力和卡片内容定义两个部分。

产品侧只需要定义好卡片的样式内容和决定分发的位置和人群等就可以将自身内容、服务输出给指定用户，这就是第一个阶段，提供通用性内容服务->用户的通路。

2.2 高并发下保证可用性、降低平响

作为一个面向多个产品线的基础服务，应用场景如首页、活动页等，qps的量级将至少以10w为单位计数，设计上响应时间需要稳定控制在50ms内，从而避免对产品本身的性能造成影响。

2.2.1 降级策略保证整体可用性

1.降级的定义

因流量或服务器压力剧增，可能引发服务宕机或级联性崩溃。在有限资源的情况下，服务端不得不按优先级区分处理业务，即优先保证核心业务的正常运行，而对非核心业务用做简单折中处理，如快速失败，或返回缓存数据等等，避免占用更多资源，称之为服务降级。降级的目的是在服务自身性能达到瓶颈，或网络硬件应用等依赖的资源出现异常时，尽可能保证核心业务正常运行，进一步保证系统整体的可用性和稳定性。

2.降级的特点

降级是服务的自我保护机制，为了整体不被拉跨，放弃部分服务的可用性，丢车保帅。
因非核心任务被降级处理，从用户角度来看，现象就是可能服务变的不可访问，或者数据过期，因此一定上程度降低了用户体验。

3.常用策略

限流(拒绝, 缓存), 熔断(快速失败, 缓存)

限流：从一定程度上来说，大流量是增加服务器压力的万恶之源，短时间内的高并发，服务器会启用大量线程池，CPU切换压力增大，如果线程池达到上限，更多请求会阻塞在内存空间，各服务接口都会受影响。如果同步访问数据库，或远程服务，磁盘读写性能和网络延迟会成为性能瓶颈，影响TPS，加上高并发请求，服务器容易宕机。
熔断
降级开关

4.选取策略

资源卡片的内容和服务大多由内容服务团队提供，所以我们需要实时监测这些服务，避免由于某个服务的问题导致整体服务出现问题。

设置熔断开关，如调用服务可用性低于设定阈值，直接熔断断开调用，直至后续多时间片监测确认服务恢复。
制定性能分发权重，可用性较差、平均响应时长较长的服务降低其分发权重。

2.2.2 存储优化，提升平响、稳定性

1.业务需求和特征

业务数据特点：

物料和视频或者用户强相关

分发侧需求：

平响要低，不能影响自己的核心业务。
稳定性要高，可用性不能低于99.9%。

业务进行分类：

要求和某些视频绑定需要稳定下发的
要求高优下发的
需要实时请求下游服务进行计算的

用户使用特征：

用户都是就近请求服务，通常非机房级别故障，不会产生跨机房请求
绝大部分的内容是我们推荐给用户，用户对于大部分内容的一致性的要求没有那么高。

2. 基于以上需求特征确定存储方案如下

根据业务数据特点和分发侧需求我们可以选取key value型存储，变更性能好。
根据业务进行分类和用户使用特征，我们对不同地区之间的数据一致性要求不高，在不考虑降级策略以及抛却一些需要实时请求的下游业务情况下，如果想通过平台进行性能优化，那变动不是很频繁的业务我们只能尽可能的让他们把数据存到我们这里统一管理，增加一些本地缓存作为二级缓存来进一步提高可用性。

2.2.3 多路数据获取，性能优先

并发多路请求下游服务，设定超时时间，将最终未超时返回的数据进行后续策略处理确定最终分发数据。由于受限与机器连接数，核心要点是要平衡好并发的数量和超时时间，二则呈负相关。

我们的目的是尽可能的请求更多的服务来获取内容和服务以便给出用户最佳推荐，达成这个目的依赖于我们对于服务的精细化管理。

2.3 平台工具化保证快速业务接入

1. 设计背景：

条件繁杂：资源位已接入数以十计的业务且持续增加，每种业务都涉及业务数据的组装，分发端、版本、位置的控制，各种小流量实验的加入等需求，重复性工作较多，且质量把控成本高。
业务变更频繁：日常迭代中经常收到诸如某业务跳转地址更、物料信息、小流量实验号、业务优先级、下发版本的变更需求，经常面临开发五分钟，上线几小时。
业务逐渐复杂：随着业务的大量接入，每次上线的回归测试将变得成本越来越高，各种业务的监控维护也越来越复杂。
case咨询：pm或者用户咨询不符合其预期下发的原因，研发需要查看代码核对逻辑复现线上，成本高昂。

2. 设计目标：

业务规则抽象化：业务代码进行规则抽象，支持规则组合、插拔和热更新。
业务上线配置化：老业务变更和新业务接入通过已有规则和新增规则配置化完成上线。
业务回归测试监控自动化：通过建立自动化监控及回归测试机制来降低业务复杂带来的成本。
业务流程可见性：当业务遇到不清楚的问题时，可以非常清晰的发现是哪个环节导致。

2.3.1 资源模板化、下发规则插件化，应用规则引擎，灵活组装上线

1.业务方选取展现物料模板，填充物料，确定展示样式。

2.下图下发规则组件化由接入业务方自由选取组合，平台进行最终审核上线。

规则引擎运转步骤：

1. 创建规则引擎对象

2. 向引擎中加载规则集或更换规则集

3. 向引擎的前置过滤规则提交需要被规则集处理的数据对象获取处理结果

4. 根据处理结果获取需求的物料数据

5. 将物料数据提交给规则引擎的后置聚合规则

6. 输出引擎执行结果

规则引擎核心设计：

规则的核心为两个部分：

1. 判断资源在哪里出与不出，业务上由于已经沉淀出绝大部分的规则，且规则变化不大，核心在于规则中的条件变更，所以基于业务和成本考量不建设复杂的规则编辑和解析能力，规则将以组件化的形式存在，可以动态维护规则得变量参数，如app下发规则，规则变量参数为下发端的名称，应用规则时变量参数为端名称、条件、是否下发，如新业务需要新增规则再进行组件开发，主要核心能力在于组装管理规则组件。

2. 判断资源出什么，业务方选择物料模板填充物料，如跳转地址以及地址里的参数和用户、端、版本等因素都会有一定的关系，所以在输出的时候需要进行动态的转化，这个也需要通过规则得方式进行数据转化。

规则之间的关系：

且：规则定义为执行的一条执行链路，所有的规则都命中为下发则下发，一条命中不下发则不下发。

从属：规则存在从属关系，有配套父子关系，如规则a下有从属b、c，配置a时可以配置从属b、c规则，如版本和规则下发规则从属与端下发规则，只有端下发规则生效从属规则才有意义，完整规则链条是：a(分发端) b (>=xx版本) c(在端什么页面)进行下发。

2.3.2 资源下发录制回放

通过记录并模仿用户的行为完成case的复现、业务探活、上线回归。

流量行为录制，通过服务标准化日志打印输出，统一用户请求行为日志，将日志收集至录制平台，对日志进行清洗、分类、聚合，构建核心功能回归路径、用户请求路径，完成用户行为和核心功能的请求录制。
流量行为回放，通过录制的流量行为构建对服务进行请求，拿到请求的结果与录制时的结果对比，输出报表，完成报告分析报告。

2.4 智能调度分发策略保证用户体验

通过前后端打点，获取推荐卡片的点、展、观看时长等数据，结合实验进行统计分析，动态完成业务质量评估结合用户画像来实时调整下发策略。

2.4.1 接入业务质量评估及迭代处理

根据下发资源卡片的打点数据，定期进行业务自动化评估，根据评估数据，持续迭代淘汰质量较差的业务资源。

2.4.2 动态策略返回最优内容

根据用户画像及接入业务服务的性能及健康状态，实时计算资源下发的分配份额，基于份额进行资源下发调配。

三、总结

前期重通路及可用性完成基础能力构建，打通业务侧内容、服务供给，用户侧内容消费、服务使用的闭环，通过存储优化、性能优化保证了服务的可用性。后期重效率、质量通过平台建设，应用插件设计、规则引擎提升业务接入效率，通过流量回放来降低事故率、业务回归测试成本，最终通过智能调度策略保障平台生态质量，避免无序扩张而影响应用资源卡片的业务本身。

推荐阅读：

视觉Transformer中的输入可视化方法

深入理解 WKWebView (渲染篇) —— DOM 树的构建

深入理解 WKWebView（入门篇）—— WebKit 源码调试与分析

字节跳动在异构场景下的高可用建设实践

字节跳动有众多的 APP 和服务，如何用混沌工程的方式保证这些系统和服务的高可用？本文详细介绍了字节跳动混沌工程技术的演进和系统高可用建设实践。

本文主要为大家介绍字节跳动在高可用建设上的一些思考和落地经验。先给大家简单介绍一下系统治理团队是做什么的。系统治理团队在基础架构团队内部，主要负责字节跳动研发的闭环生态：从服务开发，到大规模微服务架构下的联调、开发以及对应的发布，再到上线以后的微服务治理、对应的流量调度、容量分析，以及到最后通过混沌工程的建设帮助业务提升高可用能力。

接下来就进入正题。首先介绍一下字节跳动混沌工程建设的背景。大家知道字节跳动有很多 APP，我们有非常多的服务，这些服务大致可以分成三个类型：

在线服务：大家可以理解成支持抖音、西瓜视频等的后端服务。这些服务的特点是它们跑在我们自建的大规模 K8s 上的 PaaS 集群上，这是一套非常大的微服务架构。
离线服务：包括一些推荐模型的 training，大数据的 report 计算等等，都属于离线服务。它们依赖大规模的存储和计算的能力。
基础架构：承载了字节中国的所有业务线，向上提供一套 PaaS 化的能力，包括计算和存储等，支撑各种业务不同的使用场景。

不同的服务体系对高可用的关注度并不一样。我们简单做一下分析：

在线服务：本身是无状态服务，运行在 K8s 容器上，其存储都在外部的 MySQL、Redis。这些无状态服务很方便做扩容，在发生故障时能尽可能容错，当然也可能会做一些降级。
离线服务：有状态服务，很关注计算的状态。大数据的计算服务特点是运行时间很长，Training、model 的时间都特别长。它能容忍一些错误（如果某次 job 挂了，可以进行 retry），其更多状态的一致性、数据的完整性是依赖底层存储系统的支持。所以我们在离线服务的高可用建设，很大规模依赖于整个基础架构提供的高可用能力。
基础架构：基础架构本身是有状态的，它是进行大规模存储、计算的平台，可能会遇到一些网络故障、磁盘故障等灰天鹅事件，这其中我们关注较多的是数据一致性。

应对不同的服务类型，系统治理团队负责高可用的同学提出了不同的解决方案。在这里先给大家介绍我们应对在线服务（无状态服务）时混沌工程的演进。

在线服务的混沌工程演进

混沌工程平台 1.0 架构

我们认为我们的混沌工程平台 1.0 版本还不是一个混沌工程系统，更多的是一个故障注入系统。

上图是我们这个平台 1.0 版本的架构。这个平台面向用户提供可视化界面，可进行故障注入和一些简单的配置。在底层物理机上我们装了 Agent。Agent 运行在宿主机上，可实现容器间网络相关的故障注入。

对于服务稳态，我们在做混沌演练的时候，在平台上可以注入一些 metrics，用户可以写一个 bosun 语句去查询 metrics，我们提供一个阈值，系统就会轮询这个 metrics 来判定服务是否达到稳定的状态。如果超出边界，我们就进行故障恢复。如果没有超出边界，就继续演练，看是否能达到预期。

为什么这个系统不能称之为一个混沌工程的系统？Netflix 的 Principle of Chaos 对混沌工程的定义（http://principlesofchaos.org/）有五大原则：

建立一个围绕稳定状态行为的假说
多样化真实世界的事件
在生产环境中运行实验
持续自动化运行实验
最小化爆炸半径控制

对比以上五个原则，我们来看一下为什么说这个平台只是个故障注入系统。

首先整体的稳态还相对比较简陋。
实际的微服务架构中会存在各种故障，这个平台中只做到了比较简单的故障注入，如故障延迟、断网等。
在生产环境进行演练是当时能做到的事情。
因为稳态比较简陋，所以很难真正评估这个系统是不是稳定，系统也无法自动化运行实验。
整个系统声明 scale 的 scope 做的不是特别好。另外当时技术实现的结构是在物理机的宿主机上做故障注入，本身有一定的隐患，爆炸半径控制做得也不是特别好。

混沌工程平台 2.0 架构

在 2019 年的时候，我们开始想把混沌工程平台 1.0 版本演进到下一代，希望能够做一个真正符合混沌工程标准的系统，因此有了平台的 2.0 版本，我们认为它是字节跳动真正意义上的第一个混沌工程系统。

混沌工程平台 2.0 版本的一些升级：

架构升级：引入了一个故障中心层，解耦了业务逻辑和底层故障注入。
故障注入：随着 Service Mesh 更大规模的应用，网络调用相关的故障更多基于 sidecar 实现。
稳定性模型：这个阶段我们也构建了一个稳态系统，基于服务的关键指标和机器学习等算法实现稳态计算。我们非常关注稳态系统，认为真正的自动化演练是不需要人工干预的，所以需要一个系统来识别被演练的系统是否稳定。如果系统只看到一堆 metrics，它很难直接去认知系统的稳定性。我们希望通过一些特定算法将这些 metrics 聚合成一个百分位指标，假设这个指标达到 90 分，我们就认为它是稳定的。后文还会再介绍我们怎么在这个稳态系统里面做算法的投入。

故障中心架构

我们的故障中心借鉴了 K8s 的架构。

混沌工程平台 1.0 系统有一个问题：假设通过 Agent 在 K8s 里成功注入了一个延迟故障。但 K8s 本身有弹性调度能力，如果很不幸在演练过程中这个服务 crash 了，K8s 会自动在另外一个机器上把这个 Pod 启起来。这种情况下，你以为故障演练是成功的，但其实没有成功，而是重新起了新的服务。故障中心可以在容器发生漂移的时候继续注入故障。

所以我们是一套声明式的 API，声明的不是要注入什么故障，而是描述服务器的一种状态，例如 A 跟 B 之间的网络是断开的，那么在任何状态下故障中心要保证 A 和 B 是断开状态。其次，整个系统借鉴 K8s 的架构，有丰富的 controller 支持底层不同的故障注入能力。在对业务的快速需求的支持过程中，我们在 controller 里能很快接入 Chaos Mesh、Chaos Blade 等开源项目。我们自己也原生做了一些 controller，比如 service mesh controller，agent controller，服务发现的 controller 等。

爆炸半径控制

前面提到故障中心是通过声明式 API 注入故障，我们就需要定义故障注入 model。

如上图所示：

Target：表示要注入故障的目标服务。
Scope Filter：对于爆炸半径控制，很重要的一点是我们希望能够让业务去帮助声明希望演练的 scope，我们称为 Scope Filter。通过 Scope Filter 能定义故障注入的目标，可以是一个机房，一个集群，一个可用区，甚至精确到实例级别乃至流量级别。
Dependency：它是所有可能影响服务本身的异常来源，包括中间件，某下游服务，也包括所依赖的 CPU、磁盘、网络等。
Action：故障事件，即发生了何种故障，比如下游服务返回拒绝、发生丢包；又比如磁盘写异常、CPU 被抢占等。

所以在故障中心声明故障时，需要描述上述内容，表明业务希望系统中是怎样的故障状态。

稳态系统

稳态系统会涉及一些算法的工作，这里主要介绍三个算法的场景：

时序序列的动态分析：我们叫稳态算法，可以尝试分析服务是否稳定。其中使用了阈值检测、3 Sigma 原则、稀疏规则等算法。
AB 对比稳态分析：借鉴了 Netflix 在用的曼-惠特尼 U 检验，大家可以看一些相关 paper 和文章介绍。
检测机制：使用指标波动一致性检测算法，用来分析强弱依赖。

通过以上这些算法（还有其他算法），稳态系统能够去很好地刻画系统稳定性。

自动化演练

我们将自动化演练定义为完全不需要人工干预，由系统进行故障注入，在注入过程、演变过程中分析服务的稳定性，随时止损或拿到结果。

我们现在进行自动化演练有这样一些前提：

能够明确演练的实际场景的目标；
通过稳态系统，对稳态假设具备自动化判断能力；
能够通过声明式 API、Scope Filter 控制混沌演练的影响范围，实验过程生产损失极小。

自动化演练目前主要的应用场景是强弱依赖分析，包括：

强弱依赖现状与业务标注是否一致；
弱依赖超时是否会拖垮整体链路。

总结

现在我们再来回顾一下，为什么我们认为混沌工程平台 2.0 版本是一个混沌工程系统。还是对比前文提到的五个原则：

建立一个围绕稳定状态的假说：通过稳态系统已经开启了稳态假说的演进。
多样化真实世界的事件：现在故障分层上更加合理，补充了大量中间件故障和底层故障。
在生产环境中运行试验：这一点在 1.0 时期就实现了，2.0 中进行了扩展，可支持生产环境、预发环境、本地测试环境的各种故障演习。
持续自动化运行试验：提供 csv、sdk、api 等能力，让业务线在自己希望的服务发布流程中持续跟功能做整合。我们也提供了 API 能力，帮助业务线在需要的环境做故障注入。
最小化爆炸半径：提供声明式 API 的能力，其中一个原因就是为了控制爆炸半径。

支撑底层系统演练的基础设施混沌平台

前面提到了离线服务很大程度上依赖底层状态的一致性，所以如果把基础架构中存储、计算做好，就能够很好地支撑业务。我们用一个新的基础设施混沌平台来做一些内部的实验性尝试。对于基础架构的混沌工程，我们要打破一下混沌工程的一些标准原则。

首先针对基础架构的混沌工程不太适合在生产环境演练，因为它依赖于底层的故障注入，影响面非常大，爆炸半径不好控制。
在自动化演练上，业务方需要更加灵活的能力，进一步跟他们的 CI/CD 打通，也需要更加复杂的编排需求。
对于稳态模型，除了稳定性之外，我们更关注一致性。

要支持离线环境的混沌工程，该基础设施混沌平台给了我们一个安全的环境，让我们能够在里面展开手脚做更多的故障注入，比如 CPU、Memory、File system 等系统资源故障；拒绝、丢包等网络故障；以及包括时钟跳变、进程被杀、代码级异常、文件系统级方法 error hook 在内的其他故障。

对于自动化演练的自动化编排，我们希望通过这个平台给用户更加灵活的编排能力，例如：

串并行任务执行
随时暂停 & 断点恢复
基础设施主从节点识别

我们也提供了一些插件能力，让一些组件团队能够更灵活地注入故障。有的业务团队可能在自己的系统里已经埋点了一些 hook，他们希望这个系统能够更直接地帮助注入故障，同时也希望复用我们的编排体系和平台体系。我们通过 hook 的方式，业务团队只需实现对应的 hook，就能够注入特定的故障，然后继续使用我们的整套编排体系和平台。

从混沌工程到系统高可用建设

我们最开始做 Chaos Engineering 的时候，对团队的使命定位是在字节跳动落地混沌工程。但是当我们做出一些能力找业务线使用的时候，会发现业务线对此并没有什么需求。后来我们努力思考之后调整了团队的使命：通过混沌工程或者其他一些手段帮助业务推进高可用建设。调整之后我们就从过去研究 Chaos Engineering 的业界发展，变成了要去贴着业务理解业务的高可用。我们如何帮助业务进行高可用建设呢？

什么是高可用

我们用下面这个公式来进行理解高可用。

MTTR（Mean Time To Repair）：平均修复时间
MTBF（Mean Time Between Failure）：平均失效间隔时间
N：事故发生次数
S：影响范围

这个公式的值明显小于 1，算出来应该是所谓的三个九、五个九。要让 A 的值足够大，需要：

MTTR*N*S 的值足够小。所以需要降低 MTTR，降低事故发生次数，缩小故障范围。
MTBF 的值变大。即尽可能拉开两次故障之间的间隔。

如何降低 MTTR、N、S 呢？

降低故障影响范围（S）

当面向生产架构的故障发生的时候，要降低故障影响范围，从架构侧可以采用一些设计手段：

单元化设计：用户请求隔离
多机房部署：系统资源隔离
核心业务独立部署：业务功能隔离
异步化处理

在这里，混沌工程可以做的事情是帮助 SRE 团队验证这些架构设计是否符合预期。

减少故障发生次数（N）

这里要重新定义一下故障。Failure 是不可避免的，我们要尽可能在软件系统的架构层避免 Failure 转换成 Error。

如何降低从 Failure 到 Error 的转换率？最重要的是加强系统的容错性，包括：

部署：异地多活，流量灵活调度，服务兜底，预案管理；
服务治理：超时配置，熔断 fail fast。

这其中混沌工程起到的作用帮助验证系统容错能力。

降低平均修复时间（MTTR）

上图展示了 MTTR 涉及的一些因素：Fail Notification、诊断、修复、测试、最终上线等所需的时间。要降低 MTTR 可以对每个涉及的因素加入一些设计手段：

充分的监控告警覆盖。需要推动业务进行告警的治理。
在告警充分覆盖的同时保证告警的准确性。
高效定位，加强排障能力。目前我们跟内部的 AIOps 团队合作，做进一步的智能化障碍分析，降低诊断时间。
快速止损预案。从修复到测试再到最终上线，需要有一个预案系统，根据诊断的故障特征备有预案库，做到点击按钮即可选择准确的预案做恢复。

这其中混沌工程可做的是进行应急响应演练。其实演练不只是针对系统，也是演练组织里每个人的应急能力。当面临事故时，团队可以有一套标准的 workflow 去发现问题、定位问题、解决问题，这也混沌工程系统希望演练达到的效果。

后续规划

最后介绍一下我们在高可用、混沌工程方面的后续规划，主要有三个方面：

故障精细化能力建设
面向不同体系故障分层建设
丰富各层故障能力
丰富混沌工程的使用场景
继续探索自动化场景
降低用户接入和使用成本，打造轻量级平台
扩展混沌工程内涵
回归可用性视角，持续探索混沌工程与高可用的关系
建立故障预算机制，通过量化故障损失进行预测和分析，从而协助决策在混沌工程的投入

一直想整理出一份完美的面试宝典，但是时间上一直腾不开，这套一千多道面试题宝典，结合今年金三银四各种大厂面试题，以及 GitHub 上 star 数超 30K+ 的文档整理出来的，我上传以后，毫无意外的短短半个小时点赞量就达到了 13k，说实话还是有点不可思议的。

一千道互联网 Java 工程师面试题

内容涵盖：Java、MyBatis、ZooKeeper、Dubbo、Elasticsearch、Memcached、Redis、MySQL、Spring、SpringBoot、SpringCloud、RabbitMQ、Kafka、Linux等技术栈（485页）

初级—中级—高级三个级别的大厂面试真题

阿里云——Java 实习生/初级

List 和 Set 的区别 HashSet 是如何保证不重复的

HashMap 是线程安全的吗，为什么不是线程安全的（最好画图说明多线程环境下不安全）?

HashMap 的扩容过程

HashMap 1.7 与 1.8 的区别，说明 1.8 做了哪些优化，如何优化的？

对象的四种引用

Java 获取反射的三种方法

Java 反射机制

Arrays.sort 和 Collections.sort 实现原理和区别

Cloneable 接口实现原理

异常分类以及处理机制

wait 和 sleep 的区别

数组在内存中如何分配

答案展示：

美团——Java 中级

BeanFactory 和 ApplicationContext 有什么区别

Spring Bean 的生命周期

Spring IOC 如何实现

说说 Spring AOP

Spring AOP 实现原理

动态代理（cglib 与 JDK）

Spring 事务实现方式

Spring 事务底层原理

如何自定义注解实现功能

Spring MVC 运行流程

Spring MVC 启动流程

Spring 的单例实现原理

Spring 框架中用到了哪些设计模式

为什么选择 Netty

说说业务中，Netty 的使用场景

原生的 NIO 在 JDK 1.7 版本存在 epoll bug

什么是 TCP 粘包/拆包

TCP 粘包/拆包的解决办法

Netty 线程模型

说说 Netty 的零拷贝

Netty 内部执行流程

答案展示：

蚂蚁金服——Java 高级

题 1：

jdk1.7 到 jdk1.8 Map 发生了什么变化(底层)?

ConcurrentHashMap

并行跟并发有什么区别？

jdk1.7 到 jdk1.8 java 虚拟机发生了什么变化?

如果叫你自己设计一个中间件,你会如何设计?

什么是中间件？

ThreadLock 用过没有,说说它的作用?

Hashcode（）和 equals（）和==区别?

mysql 数据库中,什么情况下设置了索引但无法使用?

mysql 优化会不会,mycat 分库,垂直分库,水平分库?

分布式事务解决方案?

sql 语句优化会不会,说出你知道的?

mysql 的存储引擎了解过没有?

红黑树原理？