Synx

断路器背景 微服务连锁故障场景 在分布式环境中，各个微服务相互调用，当某些情况下，比如后端中间件服务故障、第三方服务中断导致某个服务无限期不可用，短时间无法恢复，则可能会导致连锁故障，最终影响压垮整个业务集群 断路器与重试 断路器模式不同于重试模式，重试模式是使应用程序可以重试操作以期望它会成功，而断路器模式是防止应用程序执行一个可能失败的操作，减少执行可能失败操作的CPU、内存、线程等资源的浪费，从而保证服务的整体可用 断路器设计解析 基于代理模式的断路器 断路器相当于一个请求操作执行的代理，托管请求操作的执行 实现原理流程： 拦截服务执行的请求，通过当前状态决定是否直接返回，如果否则执行后续操作 尝试执行操作，并获取返回结果 根据返回结果和当前统计信息，决定当前断路器的状态，修改状态 返回执行结果 断路器状态机  断路器状态机实现上有三种状态：Closed(断路器关闭)、Open(开放)、HalfOpen(半开放) 状态 说明 备注 Closed 关闭 断路器关闭正常执行操作 Open 打开 断路器开放,所有请求直接返回错误，不执行任何请求 HalfOpen 半开放 允许有限数量的请求通过,如果执行成功，恢复到关闭状态，如果仍然失败

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 1. 基础筑基 sync.WaitGroup里面的实现逻辑其实蛮简单的，在看过之前的sync.Mutex和synx.RWMutex之后，阅读起来应该非常简单，而唯一有差异的其实就是sync.WaitGroup里面的state1 1.1 等待机制 sync.WaitGroup主要用于等待一组goroutine退出，本质上其实就是一个计数器，我们可以通过Add指定我们需要等待退出的goroutine的数量，然后通过Done来递减，如果为0,则可以退出 1.2 内存对齐 内存对齐是一个比较大的话题，其核心机制是编译器根据结构体内部元素的size结合平台和编译器自身的规则来进行补位， 而在sync.WaitGroup里面就有用到，也是我感觉可能在WaitGroup所有实现的核心特性里面最重要的一条了 在WaitGroup里面只有state1 [3]uint32这一个元素，通过类型我们可以计算uint32是4个字节，长度3的数组总长度12，其实之前这个地方是[12]byte, 切换uint32是go语言里面为了让底层的编译器保证按照4个字节对齐而做的切换 1.3 8字节 8字节即两个4字节，也就是两个uint32的长度，实际上也是一个uint64的长度，在sync