天道酬勤,学无止境

10年阿里开发架构师经验分享:kafka消息丢失情况

常见的分布式事务场景

分布式事务其实就在我们身边,你一直在用,但是你却一直不注意它。

转账

扣你账户的余额,增加别人账户余额,如果只扣了你的,别人没增加这是失败;如果没扣你的钱别人也增加了那银行的赔钱。

下订单/扣库存

电商系统中这是很常见的一个场景,用户下单成功了,店家没收到单,不发货;用户取消了订单,但是店家却看到了订单,发了货。

分库分表场景

当我们的数据量大了之后,我们可能会部署很多独立的数据库,但是你的一个逻辑可能会同时操作很多个数据库的表,这时候该如何保证所有的操作要么成功,要么失败。

分布式系统调用问题

微服务的拆分让各个系统各司其职,但是带来的也有很多痛苦,一个操作可能会伴随很多的外部请求,如果某一个外部系统挂掉了,之前操作已完成的这些是否需要回滚。

针对上面这些问题,我们前面学过的数据库4大特性:ACID 似乎在这里想要达到就变得很困难,单机情况下你还可以通过锁和日志机制来控制数据,在分布式场景又该如何实现呢?在不同的分布式应用架构下,实现一个分布式事务要考虑的问题并不完全一样,比如对多资源的协调、事务的跨服务传播等,实现机制也是复杂多变。尽管有这么多工程细节需要考虑,但分布式事务最核心的还是其 ACID 特性,只是这种 ACID 变换了场景。

分布式理论

CAP 定理

传统的 ACID 模型肯定无法解决分布式环境下的挑战,基于此加州大学伯克利分校 Eric Brewer教授提出 CAP 定理,他指出 现代 WEB 服务无法同时满足以下 3 个属性:

  • 一致性(Consistency) : 所有的客户端都能返回最新的操作。
  • 可用性(Availability) : 非故障的节点在合理的时间内返回合理的响应(不是错误和超时的响应)。
  • 分区容错性(Partition tolerance) : 即使出现单个组件无法可用,操作依然可以完成。

关于一致性的理解后面分出来三个方向:

  • 强一致:任何一次读都能读到某个数据的最近一次写的数据。系统中的所有进程,看到的操作顺序,都和全局时钟下的顺序一致。简言之,在任意时刻,所有节点中的数据是一样的。
  • 弱一致:数据更新后,如果能容忍后续的访问只能访问到部分或者全部访问不到,则是弱一致性。
  • 最终一致:不保证在任意时刻任意节点上的同一份数据都是相同的,但是随着时间的迁移,不同节点上的同一份数据总是在向趋同的方向变化。简单说,就是在一段时间后,节点间的数据会最终达到一致状态。

关于一致性的理解不同,后面对于 CAP 理论的实现就有所不同。

另外 Eric Brewer教授指出现代 WEB 服务无法同时满足这 3 个属性,说的是无法同时满足,那这是为什么呢?

如果在某个分布式系统中无副本,那么必然满足强一致性,同时也满足可用性,但是如果这个数据宕机了,那么可用性就得不到保证。

如果一个系统满足 AP,那么一致性又得不到保证。所以 CAP 原则的精髓就是要么 AP,要么 CP,要么 AC,但是不存在 CAP。

BASE 定理

基于前面提到的 CAP,反正我们都无法同时满足CAP,设计系统的最高目的就是让他跑下去不出错,那么是不是可以不要求强一致性,最终让他一致即可。所以后面又提出来了 BASE 定理:

  • Basically Available(基本可用)
  • Soft state(软状态)
  • Eventually consistent(最终一致性)

基于现在大型分布式系统的复杂性,我们无法保证服务永远达到999,那么是否可以取舍,核心服务达到999,非核心服务允许挂为了保全核心服务。另外在非核心服务 down 机过程中允许系统暂时出现不一致但是这个不一致并不影响系统的核心功能使用。

最终系统恢复,所有服务一起修复数据,最终达到一致的状态。

业内通常把严格遵循 ACID 的事务称为刚性事务,而基于 BASE 思想实现的事务称为柔性事务。柔性事务并不是完全放弃了 ACID,仅仅是放宽了一致性要求:事务完成后的一致性严格遵循,事务中的一致性可适当放宽。

常见的分布式事务实现方案

分布式事务实现方案从类型上去分刚性事务、柔型事务。刚性事务:通常无业务改造,强一致性,原生支持回滚/隔离性,低并发,适合短事务。柔性事务:有业务改造,最终一致性,实现补偿接口,实现资源锁定接口,高并发,适合长事务。

  • 刚性事务:XA 协议(2PC、JTA、JTS)、3PC
  • 柔型事务:TCC/FMT、Saga(状态机模式、Aop模式)、本地事务消息、消息事务(半消息)、最多努力通知型事务
两阶段提交(XA)

与本地事务一样,分布式事务场景下也可以采用两阶段提交的方案来实现。XA 的全称是 eXtended Architecture,它是一个分布式事务协议,通过二阶段提交协议保证强一致性。

XA 规范中定义了分布式事务处理模型,这个模型中包含四个核心角色:

  • RM (Resource Managers):资源管理器,提供数据资源的操作、管理接口,保证数据的一致性和完整性。最有代表性的就是数据库管理系统,当然有的文件系统、MQ 系统也可以看作 RM。
  • TM (Transaction Managers):事务管理器,是一个协调者的角色,协调跨库事务关联的所有 RM 的行为。
  • AP (Application Program):应用程序,按照业务规则调用 RM 接口来完成对业务模型数据的变更,当数据的变更涉及多个 RM 且要保证事务时,AP 就会通过 TM 来定义事务的边界,TM 负责协调参与事务的各个 RM 一同完成一个全局事务。
  • CRMs (Communication Resource Managers):主要用来进行跨服务的事务的传播。

XA 协议大概的两个流程为:

  1. 第一阶段(prepare):事务管理器向所有本地资源管理器发起请求,询问是否是 ready 状态,所有参与者都将本事务能否成功的信息反馈发给协调者;
  2. 第二阶段 (commit/rollback):事务管理器根据所有本地资源管理器的反馈,通知所有本地资源管理器,步调一致地在所有分支上提交或者回滚。

XA 协议是如何满足 ACID 的呢?

原子性和持久性我们就不用说,我们看看隔离性和一致性。

隔离性

XA 协议中没有描述如何实现分布式事务的隔离性,但是 XA 协议要求每个资源管理器都要实现本地事务,也就是说基于 XA 协议实现的分布式事务的隔离性是由每个资源管理器本地事务的隔离性来保证的,当一个分布式事务的所有子事务都是隔离的,那么这个分布式事务天然的就实现了隔离性。

一致性

在单机环境下的一致性就是保证当前服务器数据一致即可。事务执行完毕数据最终一致,不同的隔离级别下事务执行过程的中间状态不能被别的事务观察到。

事务执行完毕最终一致这个好保证,但是在RR 隔离级别下不可见一个未提交事务的中间态在分布式情况该如何做到呢?单机上 MySQL 提供了MVCC机制,采用多版本控制来处理,那分布式事务场景也是否也可以提供这样的机制呢?XA 协议并没有定义怎么实现全局的快照,一个基本思路是用一个集中式或者逻辑上单调递增的东西来控制生成全局 Snapshot,每个事务或者每条 SQL 执行时都去获取一次,从而实现不同隔离级别下的一致性。当然开发的难度还是挺大。

存在的问题:

  • 同步阻塞:当参与事务者存在占用公共资源的情况,其中一个占用了资源,其他事务参与者就只能阻塞等待资源释放,处于阻塞状态。

  • 单点故障:一旦事务管理器出现故障,整个系统不可用。

  • 数据不一致:在阶段二,如果事务管理器只发送了部分 commit 消息,此时网络发生异常,那么只有部分参与者接收到 commit 消息,也就是说只有部分参与者提交了事务,使得系统数据不一致。

  • 不确定性:当事务管理器发送 commit 之后,并且此时只有一个参与者收到了 commit,那么当该参与者与事务管理器同时宕机之后,重新选举的事务管理器无法确定该条消息是否提交成功。

总体来说 XA 方案实现简单,但是带来的问题如果放在数据一致性要求严格的场景是无法保证数据正确性的。另外事务管理器单点会带来隐患,同步阻塞模型也致使并发能力弱。

TCC

关于 TCC(Try-Confirm-Cancel)的概念,最早是由 Pat Helland 于 2007 年发表的一篇名为《Life beyond Distributed Transactions:an Apostate’s Opinion》的论文提出。 TCC 事务机制相比于上面介绍的 XA,解决了其几个缺点:

  1. 解决了协调者单点,由主业务方发起并完成这个业务活动。业务活动管理器也变成多点,引入集群。
  2. 同步阻塞:引入超时,超时后进行补偿,并且不会锁定整个资源,将资源转换为业务逻辑形式,粒度变小。
  3. 数据一致性,有了补偿机制之后,由业务活动管理器控制一致性。

TCC 其实就是采用的补偿机制,其核心思想是:针对每个操作,都要注册一个与其对应的确认和补偿(撤销)操作。TCC 模型完全交由业务实现,每个子业务都需要实现 Try-Confirm-Cancel 三个接口,对业务侵入大,资源锁定交由业务方。

  • Try 阶段:尝试执行,完成所有业务检查(一致性), 预留必须业务资源(准隔离性)。
  • Confirm 阶段:确认执行真正执行业务,不作任何业务检查,只使用 Try 阶段预留的业务资源,Confirm 操作满足幂等性。要求具备幂等设计,Confirm 失败后需要进行重试。
  • Cancel 阶段:取消执行,释放 Try 阶段预留的业务资源 Cancel 操作满足幂等性 Cancel 阶段的异常和 Confirm 阶段异常处理方案基本上一致。

一个完整的业务活动由一个主业务服务与若干子业务服务组成:

  1. 主业务服务负责发起并完成整个业务活动;
  2. 业务服务提供 TCC 型业务操作;
  3. 业务活动管理器控制业务活动的一致性,它登记业务活动中的操作,并在业务活动提交时确认所有的TCC 型操作的 Confirm 操作,在业务活动取消时调用所有 TCC 型操作的 Cancel 操作。

比如一个转账操作:

  1. 首先在 Try 阶段先把转账者的钱包冻结起来。
  2. 在 Confirm 阶段,调用转账接口操作转账,转账成功后解冻。
  3. 如果 Confirm 阶段成功那么就转账成功,否则执行转账失败确认逻辑。

基于 TCC 实现分布式事务,会将原来只需要一个接口就可以实现的逻辑拆分为 Try、Confirm、Cancel 三个接口,所以代码实现复杂度相对较高,需要在业务中写很多的补偿机制代码。

TCC将事务提交划分成两个阶段,Try即为一阶段,Confirm 和 Cancel 是二阶段并行的两个分支,二选一。从阶段划分上非常像2PC,我们是否可以说TCC是一种2PC或者2PC变种呢?

对比一下 XA 事务模型,TCC 的两阶段提交与 XA 还是有一些区别:

  1. 2PC 的操作对象在于资源层,对于开发人员无感知;而 TCC 的操作在于业务层,具有较高开发成本。
  2. 2PC 是一个整体的长事务,也是刚性事务;而 TCC 是一组的本地短事务,是柔性事务。
  3. 2PC 的 Prepare (表决阶段)进行了操作表决;而 TCC 的 Try 并没有表决准备,直接兼备资源操作与准备能力。
  4. 2PC 是全局锁定资源,所有参与者阻塞 交互等待 TM 通知;而 TCC 的资源锁定在于 Try 操作,业务方可以灵活选择业务资源的锁定粒度。

本地消息表#

方案通过在事务主动发起方额外新建事务消息表,事务发起方处理业务和记录事务消息在本地事务中完成,轮询事务消息表的数据发送事务消息,事务被动方基于消息中间件消费事务消息表中的事务。

基于本地消息表的方案,每个事务发起方都需要额外新建事务消息记录表,用于记录分布式事务的消息的发生、处理状态。

事务发起方在处理完业务逻辑之后需要将当前事务保存在消息表中,之后将消息发送到消息中间件中,并将消息的状态设置为 “发送中”。

如果消息在投递过程中丢失怎么办呢?事务发起方可以设置一个定时任务主动扫描状态为 “发送中” 的消息重新投送。只有消息被业务方消费完毕返回消费成功的结果才确认成功并将消息状态改为“已发送”。

这里因为网络异常或者发送异常导致一个消息可能会被重复发送,所以要求接收方要做到幂等性,允许重复消费。

这种方案的好处就是方案简单,成本较低,实现也不复杂。

但是坏处也有很多,比如通过消息的方式延迟不好控制;本地消息表与业务耦合在一起没有做到通用性;本地消息表基于数据库来实现,有一定的瓶颈。

事务消息

上面说的本地消息表的模式无法支持本地事务执行和消息发送一致性的问题,如果能在本地事务执行和发消息这两个操作上加上事务,那岂不是完美。

基于这个思路, 在 MQ 中存储消息的状态才是真理,消息生产者先把消息发送给MQ,此时消息状态为“待确认”,接着生产者去执行本地事务,如果执行成功就给MQ发送消息让他更改消息状态为 “待发送”并发送消息,如果执行失败则删除消息。

这样就保证了本地事务和消息发送一致性问题。

  1. 首先事务发起方先往 MQ 发送一条预读消息,这条消息与普通消息的区别在于他只对 MQ 可见不会向下传播。
  2. MQ接受到消息后,先进行持久化,则存储中会新增一条状态为待发送的消息,接着给事务发起方返回处理完成的 ACK;事务发起方收到处理完成的 ACK 之后开始执行本地事务。
  3. 发起方会根据本地事务的执行状态来决定这个预读消息是应该继续往前还是回滚。另外 MQ 也应该支持自己反查来解决异常情况,如果发起方本地事务已经执行完毕发送消息到MQ,但是消息因为网络原因丢失,那么怎么解决。所以这个反查机制很重要。
  4. 本地事务执行成功以后,MQ 也接收到成功通知,接着将消息状态更新为可发送,然后将消息推送给下游的消费者,这个时候消费者就可以去处理自己的本地事务 。

注意点:由于MQ通常都会保证消息能够投递成功,因此,如果业务没有及时返回ACK结果,那么就有可能造成MQ的重复消息投递问题。因此,对于消息最终一致性的方案,消息的消费者必须要对消息的消费支持幂等,不能造成同一条消息的重复消费的情况。

SAGA 事务模型

Saga是什么?Saga的定义是 “长时间活动的事务 ”(Long Lived Transaction,后文简称为LLT)。他是普林斯顿大学 HECTOR GARCIA-MOLINA 教授在1987年的一篇关于分布式数据库的论文中提出来的概念。

Long Lived 从字面意义上不清晰,Long 到底意味着多长?事务持续时间是一个小时、一天甚至一周吗?其实都不是,时间跨度并不重要。重要的是什么?关键的是跨系统的多次“事务”,Saga 往往由多个外部子事务构成,需要通过多次外部系统的消息交互,才能将整体事务从开始迁移到结束状态,这和我们原来常见的在一个数据库的短事务不一样。比如一个旅行的订单,是由机票、旅馆、租车三个子订单构成,都需要外部的确认,缺任何一个步骤,不能成行,这就是一个典型的 LLT。

看起来 Sage 的定义与别的分布式事务没有什么不同。分布式事务不就是多个不同的子事务构成一个整体吗?再来看看 补偿机制:

每个本地事务有相应的执行模块和补偿模块,当 Sage 事务中的任意一个本地事务出错, 可以通过调用相关事务对应的补偿方法恢复,达到事务的最终一致性。

Saga 模型是把一个分布式事务拆分为多个本地事务,每个本地事务都有相应的执行模块和补偿模块(对应TCC 中的 Confirm 和 Cancel),当 Saga 事务中任意一个本地事务出错时,可以通过调用相关的补偿方法恢复之前的事务,达到事务最终一致性。

由于 Saga 模型中没有 Prepare 阶段,因此事务间不能保证隔离性,当多个 Saga 事务操作同一资源时,就会产生更新丢失、脏数据读取等问题,这时需要在业务层控制并发,例如:

  • 在应用层面加锁;
  • 应用层面预先冻结资源。

Saga 恢复方式

Saga 支持向前和向后恢复:

  • 向后恢复:补偿所有已完成的事务,如果任一子事务失败;
  • 向前恢复:重试失败的事务,假设每个子事务最终都会成功。

虽然 Saga 和 TCC 都是补偿事务,但是由于提交阶段不同,所以两者也是有不同的:

  • Saga 没有 Try 行为直接 Commit,所以会留下原始事务操作的痕迹,Cancel 属于不完美补偿,需要考虑对业务上的影响。TCC Cancel 是完美补偿的 Rollback,补偿操作会彻底清理之前的原始事务操作,用户是感知不到事务取消之前的状态信息的。
  • Saga 的补偿操作通常可以异步执行,TCC 的 Cancel 和 Confirm 可以跟进需要是否异步化。
  • Saga 对业务侵入较小,只需要提供一个逆向操作的 Cancel 即可;而 TCC 需要对业务进行全局性的流程改造。
  • TCC 最少通信次数为 2n,而 Saga 为 n(n=子事务的数量)。

因为也是采用补偿机制,那么必然要求服务保持幂等性,如果服务调用超时需要通过幂等性来避免多次请求带来的问题。

事务特性的满足:

原子性:Saga 协调器保证整体事务要么全部执行成功,要么全部回滚。

一致性:Sage 保证最终一致性。

持久性:Saga 将整体事务拆分成独立的本地事务,所以持久性在本地事务中很好实现。

但是隔离性 Saga 无法实现,因为大事务被拆分为多个小事务,每个事务提交的时机不同很难保证已提交的小事务不被别人可见。

目前业界提供两类 Saga 的实现方式:

  • 一种是集中式协调的实现方式。

    集中式协调方式就是通过一个 Saga 对象来追踪所有的 Saga 子任务的调用,由它来管理,追踪整个事务是否应该提交或补偿。

    这种方式带来的缺点就是这种协调方式必然要与第一个Saga 事务耦合,即与业务耦合在一起。

  • 一种是分布式实现方式。

    分布式协调方式肯定就能避免耦合的问题。分布式实现的方案也很多,比如通过事件机制来实现,一条 Saga 事务链上的所有事务都订阅同一个事件,如果失败则通过失败对应的事件消息来回滚即可。

    这种方式带来的好处肯定是显而易见的,但是也会有另一个问题,多个事件带来的肯定是高并发的处理,那么会不会因为多个事件处理相关的问题带来一些循环依赖的问题。

开源分布式事务框架简介

Seata

Seata(Simple Extensible Autonomous Transaction Architecture,简单可扩展自治事务框架)是 2019 年 1 月份蚂蚁金服和阿里巴巴共同开源的分布式事务解决方案。

Seata 会有 4 种分布式事务解决方案,分别是 AT 模式、TCC 模式、Saga 模式和 XA 模式。

XA 模式

XA 模式是 Seata 将会开源的另一种无侵入的分布式事务解决方案,任何实现了 XA 协议的数据库都可以作为资源参与到分布式事务中,目前主流数据库,例如 MySql、Oracle、DB2、Oceanbase 等均支持 XA 协议。

XA 协议有一系列的指令,分别对应一阶段和二阶段操作。“xa start” 和 “xa end” 用于开启和结束XA 事务;“xa prepare” 用于预提交 XA 事务,对应一阶段准备;“xa commit”和“xa rollback”用于提交、回滚 XA 事务,对应二阶段提交和回滚。

在 XA 模式下,每一个 XA 事务都是一个事务参与者。分布式事务开启之后,首先在一阶段执行“xa start”、“业务 SQL”、“xa end”和 “xa prepare” 完成 XA 事务的执行和预提交;二阶段如果提交的话就执行 “xa commit”,如果是回滚则执行“xa rollback”。这样便能保证所有 XA 事务都提交或者都回滚。

XA 模式下,用户只需关注自己的“业务 SQL”,Seata 框架会自动生成一阶段、二阶段操作;XA 模式的实现如下:

  • 一阶段:

在 XA 模式的一阶段,Seata 会拦截“业务 SQL”,在“业务 SQL”之前开启 XA 事务(“xa start”),然后执行“业务 SQL”,结束 XA 事务“xa end”,最后预提交 XA 事务(“xa prepare”),这样便完成 “业务 SQL”的准备操作。

  • 二阶段提交:

执行“xa commit”指令,提交 XA 事务,此时“业务 SQL”才算真正的提交至数据库。

  • 二阶段回滚:

执行“xa rollback”指令,回滚 XA 事务,完成“业务 SQL”回滚,释放数据库锁资源。

XA 模式下,用户只需关注“业务 SQL”,Seata 会自动生成一阶段、二阶段提交和二阶段回滚操作。XA 模式和 AT 模式一样是一种对业务无侵入性的解决方案;但与 AT 模式不同的是,XA 模式将快照数据和行锁等通过 XA 指令委托给了数据库来完成,这样 XA 模式实现更加轻量化。

AT 模式

AT 模式是一种无侵入的分布式事务解决方案。在 AT 模式下,用户只需关注自己的“业务 SQL”,用户的 “业务 SQL” 作为一阶段,Seata 框架会自动生成事务的二阶段提交和回滚操作。

AT 模式的一阶段、二阶段提交和回滚

均由 Seata 框架自动生成,用户只需编写“业务 SQL”,便能轻松接入分布式事务,AT 模式是一种对业务无任何侵入的分布式事务解决方案。

TCC 模式

2019 年 3 月份,Seata 开源了 TCC 模式,该模式由蚂蚁金服贡献。TCC 模式需要用户根据自己的业务场景实现 Try、Confirm 和 Cancel 三个操作;事务发起方在一阶段 执行 Try 方式,在二阶段提交执行 Confirm 方法,二阶段回滚执行 Cancel 方法。

TCC 三个方法描述:

  • Try:资源的检测和预留;
  • Confirm:执行的业务操作提交;要求 Try 成功 Confirm 一定要能成功;
  • Cancel:预留资源释放。

用户接入 TCC 模式,最重要的事情就是考虑如何将业务模型拆成 2 阶段,实现成 TCC 的 3 个方法,并且保证 Try 成功 Confirm 一定能成功。相对于 AT 模式,TCC 模式对业务代码有一定的侵入性,但是 TCC 模式无 AT 模式的全局行锁,TCC 性能会比 AT 模式高很多。

Saga 模式

Saga 模式是 Seata 即将开源的长事务解决方案,将由蚂蚁金服主要贡献。在 Saga 模式下,分布式事务内有多个参与者,每一个参与者都是一个冲正补偿服务,需要用户根据业务场景实现其正向操作和逆向回滚操作。

分布式事务执行过程中,依次执行各参与者的正向操作,如果所有正向操作均执行成功,那么分布式事务提交。如果任何一个正向操作执行失败,那么分布式事务会去退回去执行前面各参与者的逆向回滚操作,回滚已提交的参与者,使分布式事务回到初始状态。

最后

我还为大家准备了一套体系化的架构师学习资料包以及BAT面试资料,供大家参考及学习,戳这里免费领取

已经将知识体系整理好(源码,笔记,PPT,学习视频)免费领取。

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

去执行前面各参与者的逆向回滚操作,回滚已提交的参与者,使分布式事务回到初始状态。

最后

我还为大家准备了一套体系化的架构师学习资料包以及BAT面试资料,供大家参考及学习,戳这里免费领取

已经将知识体系整理好(源码,笔记,PPT,学习视频)免费领取。

[外链图片转存中…(img-CtxwUzVD-1625398125946)]

[外链图片转存中…(img-DjIDM8yf-1625398125947)]

[外链图片转存中…(img-PzH2Mr6j-1625398125948)]

受限制的 HTML

  • 允许的HTML标签:<a href hreflang> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd> <h2 id> <h3 id> <h4 id> <h5 id> <h6 id>
  • 自动断行和分段。
  • 网页和电子邮件地址自动转换为链接。

相关推荐
  • 看到网上疯传的《阿里Java架构师成长之路》,网友瞬间沸腾了
    工作1-5年开发经验,当你们提出涨工资的时候,或者要offer的时候底气怎么样,是不是底气十足,不给涨工资就辞职,是不是有自信提出来主管、或者是项目经理都能同意,他们相当设法把你留住。如果这样你才是成功。什么技术都没有何谈工资! 给你分析一下这些技术,给大家罗列一些技术,看你有没有学到这些技术。 一、架构师筑基必备技能 1.1 并发编程进阶 线程共享和协作并发工具类实战站在巨人肩上操作CAS阿里面试常问的显示锁和AQS并发容器源码解析及应用实战仅会用线程池是不够的架构师应该知道的并发安全解决方案性能优化实战并发编程面试题目汇集 1.2 JVM性能深度调优 15种方式编写高效优雅Java程序实战Java内村区域深入解析垃圾回收器和内存分配策略你必须知道的JVM执行子系统JVM类加载机制及执行引擎原理JVM性能优化实战JVM面试锦囊妙计 1.3 网络编程与高效IO http/tcp/udp网络协议原理透析原生JDK网络编程Netty应用快速入门Netty粘包/半包问题解决实战Netty进阶和实战Netty源码深入分析Netty常被问到那些面试题汇集 1.4 深入Tomcat底层 10分钟熟悉你常用却又不知道的Tomcat体系架构你必须得知道的Tomcat容器及运行机制Tomcat类加载机制分析Tomcat核心组件源码解读Tomcat高级进阶Tomcat面试题整理 1.5
  • 2021最新Java面经分享,进阶学习
    前言 Spring框架自2002年诞生以来一直备受开发者青睐,它包括SpringMVC、SpringBoot、Spring Cloud、Spring Cloud Dataflow等解决方案。有人亲切的称之为:Spring 全家桶。 很多研发人员把spring看作心目中最好的java项目,没有之一。所以这是重点也是难点,工作中必须会,面试时肯定考。那么,花费10分钟,由阿里一线架构师,带你梳理Spring框架相关知识。 微服务架构(Microservice Architecture)是一种架构概念,旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。你可以将其看作是在架构层次而非获取服务的类上应用很多SOLID原则。微服务架构是个很有趣的概念,它的主要作用是将功能分解到离散的各个服务当中,从而降低系统的耦合性,并提供更加灵活的服务支持。 今天,就由某大厂一线架构师来手撕微服务架构,带你大战Spring Boot、Spring Cloud、Nginx和Docker,这些内容不信你看完还搞不懂! 注意:以下所有面试题(含答案)的文档,以及笔记整理、实战pdf,均可以免费分享给大家哦。 第一阶段:架构师筑基必备技能 我觉得,但凡是个成年人应该都清楚扎实的基本功对自己的工作帮助有多重要。从各大招聘网站的招聘要求来看,第一条都明确说明需要扎实的Java基础。因此
  • 十几年Java开发经验,在阿里、百度、华为等任职过,一路走来就剩下这份大家都在膜拜的成长笔记了
    前言 本文内容分为六部分,文章较长建议收藏再对照学习: 第一阶段:架构师筑基必备技能第二阶段:设计模式+开源框架解读第三阶段:架构技术性能提升?第四阶段:高效存储让项目起飞第五阶段:分布式扩展到微服务架构第六阶段:独家面经总结,超级精彩 以上所有文档已经打包好,只需要动动手指点击【转发+关注】并扫描小编二维码即可! 第一阶段:架构师筑基必备技能 我觉得,但凡是个成年人应该都清楚扎实的基本功对自己的工作帮助有多重要。从各大招聘网站的招聘要求来看,第一条都明确说明需要扎实的Java基础。因此,一般笔试以及面试的第一轮,对基础的考察是比较多的。 其实我发现有很多开发几年了,基础知识都不扎实,比如说,简单地介绍一下Java8有哪些新特性吗,或者你比较擅长的新特性有哪些?要么回答的不完整,要么就是回答的牛头不对马嘴。 配套学习文档 大厂必问并发编程: JVM深入拆解: 网络编程与高效IO: MySQL进阶: 面试必问数据结构与算法: 这份笔记里面涵盖的知识非常多,应该是必备的一份笔记,可以时不时的翻阅一下,查漏补缺。 第二阶段:设计模式+开源框架解读 设计模式是前辈们用毕生心血专业填坑换来的经验,把这些经验加工精简,就成了设计模式,也就是套路。有了套路,就把类型的业务类型套上去就OK了,不会出太大的问题,也利于软件的开发速度和扩展性。 目前企业主流的开源框架就是SSM框架
  • 10年阿里开发架构师经验分享:超过500人面试阿里,深度解析,值得收藏
    前言 说起来开始进行面试是年前倒数第二周,上午9点,我还在去公司的公交上,突然收到蚂蚁的面试电话,其实算不上真正的面试。面试官只是和我聊了下他们在做的事情(主要是做双十一这里大促的稳定性保障,偏中间件吧),说的很详细,然后和我沟通了下是否有兴趣,我表示有兴趣,后面就收到正式面试的通知,最后没选择去蚂蚁表示抱歉。 当时我自己也准备出去看看机会,顺便看看自己的实力。当时我其实挺纠结的,一方面现在部门也正需要我,还是可以有一番作为的,另一方面觉得近一年来进步缓慢,没有以前飞速进步的成就感了,而且业务和技术偏于稳定,加上自己也属于那种比较懒散的人,骨子里还是希望能够突破现状,持续在技术上有所精进。 饿了么一面(Java) hashmap源码问题 HashMap底层结构 put操作讲一下 HashMap、HashMap如何保证线程安全、ConcurrentHashMap JVM有哪些回收算法,对应的收集器有哪些? jvm g1的内存模型讲一下,G1和CMS收集器的区别?以及G1收集器对CMS的改进? java线程同步都有哪几种方式,synchonized和reteenlock的区别。 cas的原理,变量要用哪个关键字修饰,volatile实现的原理。 如果让你实现一个线程安全的队列,你会怎么实现。 mysql数据库优化会涉及到哪些? 手撕代码:按层次遍历二叉树? spring中用到了什么
  • 如何突破java程序员瓶颈?十年Java架构师分享自己的辛酸成长历程
    不知不觉,金九银十已经过去一半了,小编最近也是收到了蛮多读者的私信与简历, 发现了一个比较值得我注意的点,就是很多读者的简历千篇一律: 工作五年经验的简历竟然和工作一年的简历并无二致!!! 所以小编今天根据阿里的一位“十年Java架构师工作经验 ”和大家分享下程序员的成长历程, 并在文章末尾为大家分享架构师的完整学习资料。 一、工程师 阶段描述 成为一个合格的工程师需要 1~3 年时间,其典型特征是“在别人的指导下完成开发”,这里的“别人”主要是“高级工程师”或者“技术专家”,通常情况下,高级工程师或者技术专家负责需求分析和讨论、方案设计,工程师负责编码实现,高级工程师或者技术专家会指导工程师进行编码实现。 成长指导 工程师阶段是最原始的“基础技能积累阶段”,主要积累基础知识,包括编程语言、编程工具、各类系统的基本使用。以 Java 后端工程师为例,工程师阶段需要积累的经验和技能有: Java 的语法、基本数据结构的使用。 Eclipse、IDEA、Maven、Linux 命令行等各种工具。 数据库 CRUD 操作、缓存的基本使用等。 业务系统的基本流程。 工程师阶段最好的学习方法就是 找经典的书籍系统地学习,而不要遇到一个问题到网上搜搜然后就解决了事。以 Java 为例,《Java 编程思想》《Java 核心技术》《TCP/IP 协议》这类大部头,一定要完整地看一遍
  • 10年阿里开发架构师经验分享,分享面经
    最近技术群的一个问题,引起了我的思考: 今年,还存在金三银四吗? 大家都知道程序员涨薪主要还是要靠跳槽来完成!但是我们都知道,无论是考试,还是求职,这个难度,参加人数是影响难度的一个很大因数(当然特别牛逼的大佬可以忽略这句话)。 每年高考、考研人数都在增加,这求职人数也必然是每年都会增加的,因此,就算完全不出新技术,求职的难度也会越来越大。 最近和不少出去面试的朋友闲聊,都发现,两年前面试高级开发,会JUC、JVM相关的知识点都是加分项,现在反而成了基本要求,不会这些,面试都是被吊起来打! 两年前,JVM会一些理论知识,比如垃圾回收算法的概念,优缺点,适用场景等都已经能达到及格水平。现在人多了,这个筛选难度也大了,现在都开始问,你有没有做过哪些JVM调优? 大家都知道,公司开发的人数比较多,就算有JVM问题,那么参与调优的人数也是有限的。公司不可能像大学一样,让每个人都能在实验室,然后每个同学都能在亲自做实验,然后老师再打分之类。 现实是,很多同学的公司,根本没有JVM调优场景,就算有,你也没有机会参与解决,现在的面试情况就是,你不会,很可能就被“误杀”。 一、架构筑基:深入内核、直击故障、拒绝蒙圈 大家都知道,性能一直是让程序员比较头疼的问题。当系统架构变得复杂而庞大之后,性能方面就会下降,如果想成为一名优秀的架构师,性能优化就是你必须思考的问题。
  • 四面阿里巴巴如愿拿到offer定级P7,为此我筹备了半年
    每个程序员都有一个大厂的梦,而互联网大厂首当其冲自然是阿里巴巴最吃香,今天小编就来分享一个小伙进阿里巴巴的面经! “不想进大厂的程序员不是好程序员”哈哈哈 春节过后,本是金三银四之际,大部分人也都准备好了这在两个月里谋得一份自己心仪的工作,奈何今年的2020有些特殊,肺炎肆虐,对我们的工作和生活都造成了极大的影响。那么,是不是这样,我们就不工作,不学习了呢?实际上,正是因为现在正值传染病毒传播期间,所以我们宅在家里好好学习是再好不过的。对于Java程序员来说,利用这两三个月的时间,好好学习,着手准备起来,等到疫情好转,开始面试时,也不至于胆怯。 本人也是准备了大半年,最终如愿以偿拿到阿里offer! 个人情况 我是一个普通的双非本科生,开发三年多(Java后端),平时学习也比较勤学好问,对待工作也极度认真负责,对自己进入大厂工作还是很有信心的,我的方向是Java,也知道现在Java的竞争比较激烈,大厂比较难进,但我丝毫不胆怯。为此也在半年前就开始筹备了,今年初在一位大佬的内推下加上自己对知识点的复习和努力也如愿以偿的成功拿到阿里的offer! 在此特别感谢这位大佬给我提供的帮助及内推! Java中间件一面 1.技术一面考察范围: 重点问了Java线程锁:synchronized 和ReentrantLock相关的底层实现 线程池的底层实现以及常见的参数 数据结构基本都问了一遍:链表
  • 四面阿里巴巴如愿拿到 offer 定级 P7,为此我筹备了半年
    每个程序员都有一个大厂的梦,而互联网大厂首当其冲自然是阿里巴巴最吃香,今天小编就来分享一个小伙进阿里巴巴的面经! “不想进大厂的程序员不是好程序员”哈哈哈 春节过后,本是金三银四之际,大部分人也都准备好了这在两个月里谋得一份自己心仪的工作,奈何今年的 2020 有些特殊,肺炎肆虐,对我们的工作和生活都造成了极大的影响。那么,是不是这样,我们就不工作,不学习了呢?实际上,正是因为现在正值传染病毒传播期间,所以我们宅在家里好好学习是再好不过的。对于 Java 程序员来说,利用这两三个月的时间,好好学习,着手准备起来,等到疫情好转,开始面试时,也不至于胆怯。 本人也是准备了大半年,最终如愿以偿拿到阿里 offer! 个人情况 我是一个普通的双非本科生,开发三年多(Java 后端),平时学习也比较勤学好问,对待工作也极度认真负责,对自己进入大厂工作还是很有信心的,我的方向是 Java,也知道现在 Java 的竞争比较激烈,大厂比较难进,但我丝毫不胆怯。为此也在半年前就开始筹备了,今年初在一位大佬的内推下加上自己对知识点的复习和努力也如愿以偿的成功拿到阿里的 offer! 在此特别感谢这位大佬给我提供的帮助及内推! Java 中间件一面 1.技术一面考察范围: 重点问了 Java 线程锁:synchronized 和 ReentrantLock 相关的底层实现 线程池的底层实现以及常见的参数
  • 十年开发经验Java架构师,已获万赞
    一面 介绍项目java 线程池的实现原理,threadpoolexecutor关键参数解释hashmap的原理,容量为什么是2的幂次为什么要同时重写hashcode和equalsConcurrentHashMap如何实现线程安全?介绍Java多线程的5大状态,以及状态图流转过程介绍下Synchronized、Volatile、CAS、AQS,以及各自的使用场景B+树和红黑树时间复杂度如果频繁老年代回收怎么分析解决JVM内存模型,新生代和老年的回收机制mysql limit分页如何保证可靠性 二面 了解哪些排序算法,讲讲复杂度手撕归并排序Redis有哪些数据结构?底层的编码有哪些?有序链表采用了哪些不同的编码?redis的hash数据结构最多能存储多少个元素自己如何实现RPC?mysql默认存储引擎?MyISAM、InnoDB、MEMORY的区别什么是幻读,如何解决事务隔离级别有什么?通过什么来实现的?分别解决了什么问题?乐观锁与悲观锁的使用场景 三面: 自我介绍参与的并发项目,从设计到部署,按照流程讲一遍。项目相关你用过redis,用在什么场景,怎么使用的?mysql同步机制原理,有哪几种同步方法数据库主从同步如何实现,事务如何实现谈谈你对SOA和微服务的理解,以及分布式架构从应用层面涉及到的调整和挑战
  • 文章合集
    Hi 大家好,我是陈睿|mikechen,这是优知学院的所有文章集合,专门整理这个页面,希望会对大家在浏览感兴趣文章的时候,能有更好的帮助! 这些文章的呈现,并不是按照时间轴来排序,无论是新旧文章,我认为都会对大家有所帮助。 今天在整理这些文章的时候,忽然发现,原来这么久了,我居然写了这么多的文章,甚是感慨 。 感谢你们,陪伴了我这么久!~ 历史文章分类导航 mikechen谈 java程序员的发展之路和职业规划 mikechen详谈架构师成长之3大步骤 成长为月薪50K的阿里Java技术专家,必须掌握的7大技能! 最全阿里架构师P系列解读:P5-P8的技能要求和薪资结构 一篇文章搞懂高级Java程序员、架构师、技术总监、CTO从薪资到技能的区别 【深度揭秘】百度、阿里、腾讯内部岗位级别和薪资结构,附带求职建议! 程序员真的只能干到35岁?——我的35岁危机度过之道! 互联网寒冬,程序员如何突破重围?我的3个建议 关于优知和陈睿 关于我们 Java多线程与并发系列 Java多线程系列(一):最全面的Java多线程学习概述 Java多线程系列(二):线程的五大状态,以及线程之间的通信与协作 Java多线程系列(三):Java线程池的使用方式,及核心运行原理 Java多线程系列(四):4种常用Java线程锁的特点,性能比较、使用场景 Java多线程系列(五):线程池的实现原理
  • 架构师的初级技能,选组件!(2020更新版)
    原创:小姐姐味道(微信公众号ID:xjjdog),欢迎分享,转载请保留出处。2020年新版,对部分组件的描述进行了更新。19年文章参见 这里 。如果你在做选型方面的工作,或者想了解一些现在正在流行的技术,那么这篇文章正好适合你。本篇内容涵盖14个方面,涉及上百个框架和工具。会有你喜欢的,大概也会有你所讨厌的家伙。这是我平常工作中打交道最多的工具,大小公司都适用。如果你有更好的,欢迎留言补充。一、消息队列 二、缓存 三、分库分表 四、数据同步 五、通讯 六、微服务 七、分布式工具 八、监控系统 九、调度 十、入口工具 十一、OLT(A)P 十二、CI/CD 十三、问题排查 十四、本地工具复制代码一、消息队列√ 推荐:(1) 吞吐量优先选择kafka(2) 稳定性优先选择RocketMQ(3) 物联网:VerneMQ一个大型的分布式系统,通常都会异步化,走消息总线。 消息队列作为最主要的基础组件,在整个体系架构中,有着及其重要的作用。异步通常意味着编程模型的改变,时效性会降低。kafka是目前最常用的消息队列,尤其是在大数据方面,有着极高的吞吐量。而rocketmq和rabbitmq,都是电信级别的消息队列,在业务上用的比较多。相比较而言,ActiveMQ使用的最少,属于较老一代的消息框架。pulsar是为了解决一些kafka上的问题而诞生的消息系统,比较年轻,工具链有限
  • Java开发者:想去BATJ大厂?那得先学会系统学习提升自己!
    本文转载自:Java开发者:想去BATJ大厂?那得先学会系统学习提升自己! 不知不觉自己已经做了几年开发了,由记得刚出来工作的时候感觉自己能牛逼,现在回想起来感觉好无知。懂的越多的时候你才会发现懂的越少。 如果你的知识是一个圆,当你的圆越大时,圆外面的世界也就越大。 最近看到很多Java新手问Java学习路线,学习方法啊,如何入门啊,所以我从网上找了一些资料,然后以我的工作经验给大家总结一下,让你们少走弯路,提取一些工作中经常用到的技术。 那么拿到BATJ大厂的offer究竟有多难? 从我身边听说的情况来看,只要技术扎实,很多人都能通过一、二面,却很容易死在三四面,原因就在于: 这些年轻的程序员们只重视技术,却忽视了其他方面的学习成长。 刚好最近也有读者问,能不能给一些工作经验比较浅的年轻程序员,推荐几个职业发展方面的成长方法。 去问了几位在腾讯和阿里的朋友,他们都提到了一个关键词:系统性成长。 仔细一问才知道,想要获得系统性成长,有2个方法: 1.要么进入腾讯阿里这样的大公司,有专门的资深同事带领成长; 2.要么就找到一个系统性的课程和导师,从思维、工具和方法论层面帮助自己搭建成体系的职场成长路径。 那么,有没有这样的方法论,能够让职场人通过自学,逐渐学会系统性成长? 今天给大家分享一下如何系统化学习 Java技术?(Java知识体系),以及对 Java学习和提升的一些建议。
  • 阿里P8Java架构师谈:首发10万字Java开发实战文档
    前言: 有人说世界上有三个伟大的发明:火,轮子,以及 Kafka。 发展到现在,Apache Kafka 无疑是很成功的,Confluent 公司曾表示世界五百强中有三分之一的企业在使用 Kafka。在流式计算中,Kafka 一般用来缓存数据,例如 Flink 通过消费 Kafka 的数据进行计算。 而要谈对Kafka有多熟悉,我相信还是阿里的大佬们最有发言权,所以今天分享的内容,就是Alibaba内部首发的“限量笔记”,关于Kafka的精髓全部写在这里面了,真是不得不得不感叹:不愧是Alibaba的技术官啊,真的服了! 1、背景 首先,让我们简要地讨论下每个系统,以了解它们的高级设计和架构,看下每个系统所做的权衡。 Kafka 是一个开源的分布式事件流处理平台,也是 Apache 软件基金会下五个最活跃的项目之一。在其核心,Kafka 被设计成一个多副本的分布式持久化提交日志,用于支撑事件驱动的微服务或大规模流处理应用程序。客户端向代理集群提供事件或使用代理集群的事件,而代理会向底层文件系统写入或从底层文件系统读取事件,并自动在集群中同步或异步地复制事件,以实现容错性和高可用性。 Pulsar 是一个开源的分布式发布 / 订阅消息系统,最初是服务于队列用例的。最近,它又增加了事件流处理功能。Pulsar 被设计为一个(几乎)无状态代理实例层,它连接到单独的 BookKeeper
  • 10年Java开发经验,Java数据处理的常用技术
    今年互联网形式依旧严峻,再次爆发几次大规模裁员潮。我决定把这篇文章分享出来帮助那些对前途感到迷茫的朋友。 在猎头的眼里,我已不是根正苗红的程序员。何为根正苗红?计算机专业毕业,从毕业起就从事特定方向的开发工作,这才是猎头眼中的香饽饽。 毕业之后的那段岁月,可以用悲惨形容,每当和人提起,我总会有点自嘲的说“睡过凌晨一点的办公室,吃过凌晨三点的便利店,做过凌晨五点的首班车”。但是回头想想,我却要感谢那不堪的经历,让我找到了适合自己的方向。 作为技术人员,我一直有个疑问,什么是你引以为傲的资本?面对已经来临的资本寒冬,应该何去何从? 大学期间,我每年都会给自己总结一个词语。回首做技术的这几年,我同样给自己总结了几个关键词。希望大家可以从中受益。 ActiveMQ 我们先看ActiveMQ。其实一般早些的项目需要引入消息中间件,都是使用的这个MQ,但是现在用的确实不多了,说白了就是有些过时了。我们去它的官网看一看,你会发现官网已经不活跃了,好久才会更新一次。 它的单机吞吐量是万级,一些小的项目已经够用了,但对于高并发的互联网项目完全不够看。 在高可用上,使用的主从架构的实现。 在消息可靠性上,有较低的概率会丢失数据。 综合以上,其实这个产品基本可以弃用掉了,我们完全可以使用RabbitMQ来代替它。 RabbitMQ rabbitMQ出现后
  • 10年Java开发经验,Java数据处理的常用技术
    今年互联网形式依旧严峻,再次爆发几次大规模裁员潮。我决定把这篇文章分享出来帮助那些对前途感到迷茫的朋友。 在猎头的眼里,我已不是根正苗红的程序员。何为根正苗红?计算机专业毕业,从毕业起就从事特定方向的开发工作,这才是猎头眼中的香饽饽。 毕业之后的那段岁月,可以用悲惨形容,每当和人提起,我总会有点自嘲的说“睡过凌晨一点的办公室,吃过凌晨三点的便利店,做过凌晨五点的首班车”。但是回头想想,我却要感谢那不堪的经历,让我找到了适合自己的方向。 作为技术人员,我一直有个疑问,什么是你引以为傲的资本?面对已经来临的资本寒冬,应该何去何从? 大学期间,我每年都会给自己总结一个词语。回首做技术的这几年,我同样给自己总结了几个关键词。希望大家可以从中受益。 ActiveMQ 我们先看ActiveMQ。其实一般早些的项目需要引入消息中间件,都是使用的这个MQ,但是现在用的确实不多了,说白了就是有些过时了。我们去它的官网看一看,你会发现官网已经不活跃了,好久才会更新一次。 它的单机吞吐量是万级,一些小的项目已经够用了,但对于高并发的互联网项目完全不够看。 在高可用上,使用的主从架构的实现。 在消息可靠性上,有较低的概率会丢失数据。 综合以上,其实这个产品基本可以弃用掉了,我们完全可以使用RabbitMQ来代替它。 RabbitMQ rabbitMQ出现后
  • 十年开发经验Java架构师
    开头 如果Redis的读写请求量很大,那么单个实例很有可能承担不了这么大的请求量,如何提高Redis的性能呢?你也许已经想到了,可以部署多个副本节点,业务采用读写分离的方式,把读请求分担到多个副本节点上,提高访问性能。要实现读写分离,就必须部署多个副本,每个副本需要实时同步主节点的数据。 Redis也提供了完善的主从复制机制,使用非常简单的命令,就可以构建一个多副本节点的集群。 同时,当主节点故障宕机时,我们可以把一个副本节点提升为主节点,提高Redis的可用性。可见,对于故障恢复,也依赖Redis的主从复制,它们都是Redis高可用的一部分。 这篇文章我们就来介绍一下Redis主从复制流程和原理,以及在复制过程中有可能产生的各种问题。 一面 介绍项目java 线程池的实现原理,threadpoolexecutor关键参数解释hashmap的原理,容量为什么是2的幂次为什么要同时重写hashcode和equalsConcurrentHashMap如何实现线程安全?介绍Java多线程的5大状态,以及状态图流转过程介绍下Synchronized、Volatile、CAS、AQS,以及各自的使用场景B+树和红黑树时间复杂度如果频繁老年代回收怎么分析解决JVM内存模型,新生代和老年的回收机制mysql limit分页如何保证可靠性 二面 了解哪些排序算法
  • Java工作经验6年,java语言哪个公司开发
    01 前言 辛苦奋斗两个月,秋招终于圆满收官,拿到了头条、字节、菜鸟、腾讯、网易的offer,这要多亏了意外得到的这份资料文档,这么多面试全都靠它了,哈哈~~有好东西还是要分享出来给大家,一起学习呀 Java核心进阶宝典:JVM,JAVA集合,JAVA多线程并发,JAVA基础,Spring原理,微服务,Netty与RPC,网络,日志,Zookeeper,Kafka,RabbitMQ,Hbase,MongoDB,Cassandra,设计模式,负载均衡,数据库,一致性哈希,JAVA算法,数据结构,加密算法,分布式缓存,Hadoop,Spark,Storm,YARN,机器学习,云计算共30个章节。 阿里P8级架构师核心理论落地篇 再造淘宝,贯穿全系,阿里团队代码落地,详细每个版本迭代,拒绝2-3个月PPT架构师再造淘宝之咚宝-技术支撑-完整搭建DevOps再造淘宝之咚宝-统一规则-代码规范落地解析再造淘宝之咚宝搭建基础服务再造淘宝之咚宝-构建step01 -用户中心再造淘宝之咚宝-构建step02 -商品中心再造淘宝之咚宝-构建step03 -库存中心再造淘宝之咚宝-构建step05 -订单中心再造淘宝之咚宝-构建step06 -搜索中心再造淘宝之咚宝-构建step07 -评价中心再造淘宝之咚宝-构建step08-客服中心再造淘宝之咚宝-构建step09 -推荐中心再造淘宝之咚宝
  • 10年阿里开发架构师经验分享:Redis+JVM+Spring-cloud+MySQL文档资料
    最近一个哥们去面试某当红大厂了,其中几个他印象深刻的面试题你们品品: 1、介绍下如何对MySQL SQL语句进行分析和优化? 2、Redis 怎样实现的分布式锁? 3、如何实现本地缓存和分布式缓存? 4、说一下 JVM 的内存布局和运行原理? 5、RocketMQ 是怎么存储消息的?源码中有哪些高可用、高性能的设计? 面试官不愧是大佬,一层接一层的问过来,问完**“Redis 怎样实现的分布式锁”又问“单机锁有哪些?它为什么不能在分布式环境下使用?”** 由于平时只是改改以前的框架代码,哥们当场懵逼!面完瞬间觉得自己的技术弱爆了!结果当然是挂! 为什么哥们这么容易就挂了?我来分析下,你细品。上面几个问题中,1、2考的是技术的具体应用,3、4、5考察的是对于底层原理的理解。 –第一题考察的是MySQL数据库存储原理,本质是理解能力和SQL操作能力 –第二题考察的是对于分布式并发操作的处理能力,本质是操作能力 –第三题考察的是分布式缓存的理解能力和洞察能力 –第四题考察的是对于JVM的理解和洞察能力 –第五题考察的是对于MQ消息中间件架构的理解能力 这些技术都是平时我们在用的,而且10个公司招聘时有8家都会问到。 你以为面试官只是简单的问下MySQL、分布式缓存、Redis,但其实他要考察的是相关的底层原理、使用上的优化、如何实现功能等深度技术的理解。 这里我们分析一个具体问题
  • 阿里首推2021年Java技术成长笔记,业内评级“钻石级”
    前言 根据数据表明,阿里巴巴已经连续3年获评最受欢迎的中国互联网公司,实际上阿里巴巴无论在科技创新力还是社会创造价值这几个方面,都是具有一定代表里的。在行业内,很多互联网企业也将阿里作为自己的标杆,越来越多的“打工人”也希望能够进到阿里工作。 提起阿里,相信对于大部分的程序员来说是不会陌生的,毕竟阿里使用的技术一直都走在前沿,程序员所学和所掌握的也一直以阿里等一线互联网企业的要求为标准,所以阿里需要什么样的人才,成为了很多程序员的发展目标和学习方向。 实际上,阿里巴巴发展也离不开公司里的每一个付出的员工们,更值得一提的是阿里的程序员们除了完成自己的本分工作以外,还会抽出时间去提升自己的技术。近日,阿里又迎来一里程碑,首推Java架构技术成长笔记,理论与实战兼备,被业内评级“钻石级”,可以说是程序员必备! 下文内容主要是写这份《Java技术成长笔记》的主要提纲内容,提纲内容包括Xmind思维图+实战文档+面试礼包, 一、架构筑基必备技能 1.并发编程进阶:线程共享和协作+并发工具类实战+站在巨人肩上操作CAS+阿里面试常问的显式锁和AQS+并发容器源码解析及应用实战+仅会用线程池是不够的+架构师应该知道的并发安全解决方案+性能优化实战+并发编程面试题目汇集 2.JVM性能深度调优:15种方式编写高效优雅Java程序实战+Java内存区域深入剖析+垃圾回收器和内存分配策略
  • 怎么进大厂?166位Java工程师的大厂面试经验分享
    前言 不知不觉2021的跳槽黄金月金三银四已然过去,跳槽结果有人欢喜有人愁,找到好的下家固然可喜,跳槽结果不理想的朋友也不必丧气,只要扎实提升自己的技术,弄明白大厂面试官的出题逻辑,进大厂必是水到渠成。 之前有位粉丝让我写一篇怎么进大厂的文章,这是个老生常谈的问题了,但是像我这么宠粉的人必然不能拒绝,所以今天不敲代码了,聊聊我对于怎么进大厂的看法,一家之言,不喜勿喷。 我也为大家整理好了面试题集和学习资料。需要的话可以自行点击领取。 Java基础知识大全 Java实战项目源码和笔记 从0到1Java学习路线和资料 1000+道2021年最新面试题 好了,话不多说,坐稳扶好,发车喽! 大厂需要什么样的人? 大厂对于非高P职位,面试标准其实很简单 能干活 Java基础要好 最好熟悉些分布式框架 相信这些标准大部分公司都差不多 前段时间,帮一些粉丝进行了模拟面试,工作经验在3到5年间。 不少候选人能力其实不差,但面试时没准备或不会说,这样的人可能在进团队干活后确实能达到期望,但可能就无法通过面试,面试官总是只根据面试情况来判断。 但现实情况是,大多数人可能面试前没准备,或准备方法不得当。要知道,我们平时干活更偏重于业务,不可能大量接触到算法,数据结构,底层代码这类面试必问的问题点,换句话说,面试准备点和平时工作要点匹配度很小。 后面这些人的真正面试结果跟我预料的大差不差