Java后端技能总结
2021-12-26 17:46:11 3 举报AI智能生成
Java后端技能总结
作者其他创作
大纲/内容
SET lock_key unique_value NX PX 10000
加锁
// 释放锁时，先比较 unique_value 是否相等，避免锁的误释放if redis.call(\"get\
解锁的过程就是将 lock_key 键删除，但不能乱删，要保证执行操作的客户端就是加锁的客户端。而实现方式可以通过 lua 脚本判断 unique_value 是否为加锁客户端
释放锁
性能高
实现方便
避免单点故障
优点
不合理设置超时时间
Redis 集群的数据同步机制，都会导致分布式锁的不可靠性。
缺点
Redlock 算法的基本思路，是让客户端和多个独立的 Redis 实例依次请求申请加锁，如果客户端能够和半数以上的实例成功地完成加锁操作，那么我们就认为，客户端成功地获得分布式锁，否则加锁失败。使有某个 Redis 实例发生故障，因为锁的数据在其他实例上也有保存，所以客户端仍然可以正常地进行锁操作，锁的数据也不会丢失。
集群情况下分布式锁的可靠性
分布式锁
Redis 的大部分操作都在内存中完成，并且采用了高效的数据结构，比如哈希表和跳表。
单线程模型避免了多线程之间的竞争，省去了多线程切换带来的时间和性能上的开销，而且也不会导致死锁问题。
Redis 采用了 I/O 多路复用机制处理大量的客户端 Socket 请求，这让 Redis 可以高效地进行网络通信，因为基于非阻塞的 I/O 模型，就意味着 I/O 的读写流程不再阻塞。
Redis 采用单线程为什么还这么快？
缓存
将某一个时刻的内存数据，以二进制的方式写入磁盘
RDB
记录所有的操作命令，并以文本的形式追加到文件中。
AOF
Redis 4.0 后，增加了 AOF 和 RDB 混合的数据持久化机制： 把数据以 RDB 的方式写入文件，再将后续的操作命令以 AOF 的格式存入文件，既保证了 Redis 重启速度，又降低数据丢失风险。
Redis 如何实现数据不丢失？
哨兵模式做到了可以监控主从服务器，并且提供自动容灾恢复的功能
Redis Sentinel 不属于代理层模式，因为对于缓存的写入和读取请求不会经过 Sentinel 节点。Sentinel 节点在架构上和主从是平级的，是作为管理者存在的，所以可以认为是在服务端提供的一种高可用方案。
Redis Sentinel 也是集群部署的，这样可以避免 Sentinel 节点挂掉造成无法自动故障恢复的问题，每一个 Sentinel 节点都是无状态的。在 Sentinel 中会配置 Master 的地址，Sentinel 会时刻监控 Master 的状态，当发现 Master 在配置的时间间隔内无响应，就认为 Master 已经挂了，Sentinel 会从从节点中选取一个提升为主节点，并且把所有其他的从节点作为新主的从节点。Sentinel 集群内部在仲裁的时候，会根据配置的值来决定当有几个 Sentinel 节点认为主挂掉可以做主从切换的操作，也就是集群内部需要对缓存节点的状态达成一致才行。
Redis Sentinel 哨兵模式
采用哈希槽（Hash Slot），来处理数据和实例之间的映射关系
一个切片集群共有 16384 个哈希槽，这些哈希槽类似于数据分区
根据键值对的 key，按照 CRC16 算法计算一个 16 bit 的值。
再用 16bit 值对 16384 取模，得到 0~16383 范围内的模数，每个模数代表一个相应编号的哈希槽。
哈希槽映射支持手动分配和随机分配
Redis Cluster 支持给每个分片增加一个或多个从节点，每个从节点在连接到主节点上之后，会先给主节点发送一个 SYNC 命令，请求一次全量复制，也就是把主节点上全部的数据都复制到从节点上。全量复制完成之后，进入同步阶段，主节点会把刚刚全量复制期间收到的命令，以及后续收到的命令持续地转发给从节点。
客户端请求一个 Key 的时候，被请求的那个 Redis 实例先通过上面的公式，计算出这个 Key 在哪个槽中，然后再查询槽和节点的映射关系，找到数据所在的真正节点，如果这个节点正好是自己，那就直接执行命令返回结果。如果数据不在当前这个节点上，那就给客户端返回一个重定向的命令，告诉客户端，应该去连哪个节点上请求这个 Key 的数据。然后客户端会再连接正确的节点来访问。
Redis Cluster 不太适合构建超大规模集群，主要原因是，它采用了去中心化的设计。刚刚我们讲了，Redis 的每个节点上，都保存了所有槽和节点的映射关系表，客户端可以访问任意一个节点，再通过重定向命令，找到数据所在的那个节点。那你有没有想过一个问题，这个映射关系表，它是如何更新的呢？比如说，集群加入了新节点，或者某个主节点宕机了，新的主节点被选举出来，这些情况下，都需要更新集群每一个节点上的映射关系表。
Redis Cluster 采用了一种去中心化的流言 (Gossip) 协议来传播集群配置的变化
Redis Cluster（集群）
Redis 如何实现服务高可用？
第一个作用是，负责在客户端和 Redis 节点之间转发请求和响应。客户端只和代理服务打交道，代理收到客户端的请求之后，再转发到对应的 Redis 节点上，节点返回的响应再经由代理转发返回给客户端。
第二个作用是，负责监控集群中所有 Redis 节点状态，如果发现有问题节点，及时进行主从切换。
第三个作用就是维护集群的元数据，这个元数据主要就是集群所有节点的主从信息，以及槽和节点关系映射表
twemproxy和Codis
最大的优点是对客户端透明，在客户端视角来看，整个集群和一个超大容量的单节点 Redis 是一样的。并且，由于分片算法是代理服务控制的，扩容也比较方便，新节点加入集群后，直接修改代理服务中的元数据就可以完成扩容。
这个架构的缺点也很突出，增加了一层代理转发，每次数据访问的链路更长了，必然会带来一定的性能损失。而且，代理服务本身又是集群的一个单点，当然，我们可以把代理服务也做成一个集群来解决单点问题，那样集群就更复杂了
子主题
一种是基于代理的方式，在客户端和 Redis 节点之间，还需要增加一层代理服务。这个代理服务有三个作用。
客户端在发起请求之前，先去查询元数据，就可以知道要访问的是哪个分片和哪个节点，然后直连对应的 Redis 节点访问数据。
客户端不用每次都去查询元数据，因为这个元数据是不怎么变化的，客户端可以自己缓存元数据，这样访问性能基本上和单机版的 Redis 是一样的。如果某个分片的主节点宕机了，新的主节点被选举出来之后，更新元数据里面的信息。对集群的扩容操作也比较简单，除了迁移数据的工作必须要做以外，更新一下元数据就可以了。
虽然说，这个元数据服务仍然是一个单点，但是它的数据量不大，访问量也不大，相对就比较容易实现。我们可以用 ZooKeeper、etcd 甚至 MySQL 都能满足要求。这个方案应该是最适合超大规模 Redis 集群的方案了，在
缺点是整个架构比较复杂，客户端不能通用，需要开发定制化的 Redis 客户端，只有规模足够大的企业才负担得起。
另外一种方式是，不用这个代理服务，把代理服务的寻址功能前移到客户端中去。
集群方案对一些类似于“KEYS”这类的多 KEY 命令，都没法做到百分百支持。原因很简单，数据被分片了之后，这种多 KEY 的命令很可能需要跨多个分片查询。当你的系统从单个 Redis 库升级到集群时，可能需要考虑一下这方面的兼容性问题。
如何用 Redis 构建超大规模集群？
高可用
每次查询个别 key 时，key 在缓存系统不命中，此时应用系统就会从数据库中查询，如果数据库中存在这条数据，则获取数据并更新缓存系统。但如果数据库中也没有这条数据，这个时候就无法更新缓存，就会造成一个问题：查询缓存中不存在的数据时，每次都要查询数据库。
解决方式1： 给所有指定的 key 预先设定一个默认值，比如空字符串“Null”，当返回这个空字符串“Null”时，我们可以认为这是一个不存在的 key
使用多个 Hash 算法为元素计算出多个 Hash 值，只有所有 Hash 值对应的数组中的值都为 1 时，才会认为这个元素在集合中。
布隆过滤器会消耗一定的内存空间，所以在使用时需要评估你的业务场景下需要多大的内存，存储的成本是否可以接受。
布隆过滤器不支持删除元素的缺陷也和 Hash 碰撞有关。给你举一个例子，假如两个元素 A 和 B 都是集合中的元素，它们有相同的 Hash 值，它们就会映射到数组的同一个位置。这时我们删除了 A，数组中对应位置的值也从 1 变成 0，那么在判断 B 的时候发现值是 0，也会判断 B 是不在集合中的元素，就会得到错误的结论。
那么我是怎么解决这个问题的呢？我会让数组中不再只有 0 和 1 两个值，而是存储一个计数。比如如果 A 和 B 同时命中了一个数组的索引，那么这个位置的值就是 2，如果 A 被删除了就把这个值从 2 改为 1。这个方案中的数组不再存储 bit 位，而是存储数值，也就会增加空间的消耗。所以，你要依据业务场景来选择是否能够使用布隆过滤器，比如像是注册用户的场景下，因为用户删除的情况基本不存在，所以还是可以使用布隆过滤器来解决缓存穿透的问题的。
解决方式2： 布隆过滤器
缓存穿透
假设在缓存失效的同时，出现多个客户端并发请求获取同一个 key 的情况，此时因为 key 已经过期了，所有请求在缓存数据库中查询 key 不命中，那么所有请求就会到数据库中去查询，然后当查询到数据之后，所有请求再重复将查询到的数据更新到缓存中。会增加数据库的压力，占用缓存开销
解决方式：分布式锁
缓存并发
key 的过期时间都一样的情况，然后当 key 到期时，缓存集体同时失效，如果此时请求并发很高，就会导致大面积的请求打到数据库，造成数据库压力瞬间增大，出现缓存雪崩的现象。
解决方式1： 将缓存失效时间随机打散
解决方式2： 设置缓存不过期
缓存雪崩
MySQL Binlog + Canal + MQ
动态缓存热点数据，和业务借楼
先尝试从缓存中读取数据；
缓存中没有数据或者数据过期，再从数据库中读取数据保存到缓存中；
最终把缓存数据返回给调用方。
读缓存策略
先更新数据库，再删除缓存
写缓存策略
Cache Aside（旁路缓存）策略
读取缓存时如果发现缓存命中则直接返回缓存数据。如果缓存不命中则寻找一个可用的缓存块儿，如果这个缓存块儿是“脏”的，就把缓存块儿中之前的数据写入到后端存储中，并且从后端存储加载数据到缓存块儿，如果不是脏的，则由缓存组件将后端存储中的数据加载到缓存中，最后我们将缓存设置为不是脏的，返回数据就好了。
在“Write Miss”的情况下，我们采用的是“Write Allocate”的方式，也就是在写入后端存储的同时要写入缓存，这样我们在之后的写请求中都只需要更新缓存即可，而无需更新后端存储了，
写缓存
Write Back（写回）策略
缓存策略
把全量的数据都放在 Redis 集群里面，处理读请求的时候，干脆只读 Redis，不去读数据库。这样就完全没有“缓存穿透”的风险了
方式1： MQ订阅
数据更新服务只负责处理业务逻辑，更新 MySQL，完全不用管如何去更新缓存。负责更新缓存的服务，把自己伪装成一个 MySQL 的从节点，从 MySQL 接收 Binlog，解析 Binlog 之后，可以得到实时的数据变更信息，然后根据这个变更信息去更新 Redis 缓存。
方式2： 使用 Binlog 实时更新 Redis 缓存
MySQL To Redis
Redis
Message
topic:message 1:n message:topic 1:1
producer:topic 1:n consumer:topic 1:1
Topic
Tag
一个Topic中可以包含多个Queue，每个Queue中存放的就是该Topic的消息。一个Topic的Queue也被称为一个Topic中消息的分区(Partition)
一个Topic的Queue中的消息只能被一个消费者组中的一个消费者消费。一个Queue中的消息不允许同一个消费者组中的多个消费者同时消费
Queue
分片不同于分区。在RocketMQ 中，分片指的是存放相应Topic的Broker。每个分片中会创建出相应数量的分区，即Queue，每个 Queue的大小都是相同的。
Sharding
示意图
基本概念
消息生产者，负责生产消息。Producer通过MQ的负载均衡模块选择相应的Broker集群队列进行消息投递，投递的过程支持快速失败并且低延迟。
RocketMQ中的消息生产者都是以生产者组(Producer Group)的形式出现的。生产者组是同一类生产者的集合，这类Producer发送相同Topic类型的消息。一个生产者组可以同时发送多个主题的消息。
Porducer集群
消息消费者，负责消费消息。一个消息消费者会从Broker服务器中获取到消息，并对消息进行相关业务处理。
RocketMQ中的消息消费者都是以消费者组(Consumer Group)的形式出现的。消费者组是同一类消费者的集合，这类Consumer消费的是同一个Topic类型的消息。
消费者组使得在消息消费方面，实现负载均衡 (将一个Topic中的不同的Queue平均分配给同一个Consumer Group的不同的Consumer，注 意，并不是将消息负载均衡)和 容错 (一个Consmer挂了，该Consumer Group中的其它Consumer可以接着消费原Consumer消费的Queue)的目标变得非常容易。
消费者组中Consumer的数量应该小于等于订阅Topic的Queue数量。如果超出Queue数量，则多出的 Consumer将不能消费消息。
消费者组只能消费一个Tocpic中的消息，不能同时消费多个Tocpic消息
一个消费者组的消费者必须完全相同的Topic
示意图
Consumer集群
NameServer是一个Broker与Topic路由的注册中心，支持Broker的动态注册与发现。
Broker管理:接受Broker集群的注册信息并且保存下来作为路由信息的基本数据;提供心跳检测机制，检查Broker是否还存活。
路由信息管理:每个NameServer中都保存着Broker集群的整个路由信息和用于客户端查询的队列信息。Producer和Conumser通过NameServer可以获取整个Broker集群的路由信息，从而进行消息的投递和消费。
NameServer通常也是以集群的方式部署，不过，NameServer是无状态的，即NameServer集群中的各 个节点间是无差异的，各节点间相互不进行信息通讯。那各节点中的数据是如何进行数据同步的呢?在 Broker节点启动时，轮询NameServer列表，与每个NameServer节点建立长连接，发起注册请求。在 NameServer内部维护着一个Broker列表，用来动态存储Broker的信息。
Broker节点为了证明自己是活着的，为了维护与NameServer间的长连接，会将最新的信息以 心跳包 的方式上报给NameServer，每30秒发送一次心跳。心跳包中包含 BrokerId、Broker地址(IP+Port)、 Broker名称、Broker所属集群名称等等。NameServer在接收到心跳包后，会更新心跳时间戳，记录这个Broker的最新存活时间。
路由注册
由于Broker关机、宕机或网络抖动等原因，NameServer没有收到Broker的心跳，NameServer可能会将其从Broker列表中剔除。
NameServer中有一个定时任务，每隔10秒就会扫描一次Broker表，查看每一个Broker的最新心跳时间戳距离当前时间是否超过120秒，如果超过，则会判定Broker失效，然后将其从Broker列表中剔除。
路由剔除
RocketMQ的路由发现采用的是Pull模型。当Topic路由信息出现变化时，NameServer不会主动推送给客户端，而是客户端定时拉取主题最新的路由。默认客户端每30秒会拉取一次最新的路由。
客户端在配置时必须要写上NameServer集群的地址，那么客户端到底连接的是哪个NameServer节点 呢?客户端首先会生产一个随机数，然后再与NameServer节点数量取模，此时得到的就是所要连接的 节点索引，然后就会进行连接。如果连接失败，则会采用round-robin策略，逐个尝试着去连接其它节点。
首先采用的是 随机策略 进行的选择，失败后采用的是 轮询策略 。
客户端NameServer选择策略
路由发现
主要包括两个功能
Name Server集群
Broker充当着消息中转角色，负责存储消息、转发消息。Broker在RocketMQ系统中负责接收并存储从生产者发送来的消息，同时为消费者的拉取请求作准备。Broker同时也存储着消息相关的元数据，包括 消费者组消费进度偏移offset、主题、队列等。
Remoting Module:整个Broker的实体，负责处理来自clients端的请求。而这个Broker实体则由以下模 块构成。
Client Manager:客户端管理器。负责接收、解析客户端(Producer/Consumer)请求，管理客户端。例 如，维护Consumer的Topic订阅信息
Store Service:存储服务。提供方便简单的API接口，处理 消息存储到物理硬盘 和 消息查询 功能。
HA Service:高可用服务，提供Master Broker 和 Slave Broker之间的数据同步功能。
Index Service:索引服务。根据特定的Message key，对投递到Broker的消息进行索引服务，同时也提 供根据Message Key对消息进行快速查询的功能。
模块构成
为了增强Broker性能与吞吐量，Broker一般都是以集群形式出现的。各集群节点中可能存放着相同 Topic的不同Queue。不过，这里有个问题，如果某Broker节点宕机，如何保证数据不丢失呢?其解决 方案是，将每个Broker集群节点进行横向扩展，即将Broker节点再建为一个HA集群，解决单点问题。
Broker节点集群是一个主从集群，即集群中具有Master与Slave两种角色。Master负责处理读写操作请 求，Slave负责对Master中的数据进行备份。当Master挂掉了，Slave则会自动切换为Master去工作。所以这个Broker集群是主备集群。一个Master可以包含多个Slave，但一个Slave只能隶属于一个Master。 Master与Slave 的对应关系是通过指定相同的BrokerName、不同的BrokerId 来确定的。BrokerId为0表示Master，非0表示Slave。每个Broker与NameServer集群中的所有节点建立长连接，定时注册Topic信 息到所有NameServer。
集群部署
Broker集群
架构
1)启动NameServer，NameServer启动后开始监听端口，等待Broker、Producer、Consumer连接。
2)启动Broker时，Broker会与所有的NameServer建立并保持长连接，然后每30秒向NameServer定时 发送心跳包。
3)发送消息前，可以先创建Topic，创建Topic时需要指定该Topic要存储在哪些Broker上，当然，在创建Topic时也会将Topic与Broker的关系写入到NameServer中。不过，这步是可选的，也可以在发送消息时自动创建Topic。
4)Producer发送消息，启动时先跟NameServer集群中的其中一台建立长连接，并从NameServer中获取路由信息，即当前发送的Topic消息的Queue与Broker的地址(IP+Port)的映射关系。然后根据算法策略从队选择一个Queue，与队列所在的Broker建立长连接从而向Broker发消息。当然，在获取到路由信息后，Producer会首先将路由信息缓存到本地，再每30秒从NameServer更新一次路由信息。
5)Consumer跟Producer类似，跟其中一台NameServer建立长连接，获取其所订阅Topic的路由信息， 然后根据算法策略从路由信息中获取到其所要消费的Queue，然后直接跟Broker建立长连接，开始消费其中的消息。Consumer在获取到路由信息后，同样也会每30秒从NameServer更新一次路由信息。不过不同于Producer的是，Consumer还会向Broker发送心跳，以确保Broker的存活状态。
工作流程
集群模式:该模式下创建的Topic在该集群中，所有Broker中的Queue数量是相同的。
Broker模式:该模式下创建的Topic在该集群中，每个Broker中的Queue数量可以不同。
手动创建Topic时
默认采用的是Broker模式，会为每个Broker默认创建4个Queue。
自动创建Topic时
Topic的创建模式
同步复制:消息写入master后，master会等待slave同步数据成功后才向producer返回成功ACK
异步复制:消息写入master后，master立即向producer返回成功ACK，无需等待slave同步数据成功
复制策略
复制策略是Broker的Master与Slave间的数据同步方式。分为同步复制与异步复制
刷盘策略指的是broker中消息的 落盘 方式，即消息发送到broker内存后消息持久化到磁盘的方式。分为 同步刷盘与异步刷盘
同步刷盘:当消息持久化到broker的磁盘后才算是消息写入成功。
异步刷盘:当消息写入到broker的内存后即表示消息写入成功，无需等待消息持久化到磁盘。
刷盘策略
数据复制与刷盘策略
只有一个broker(其本质上就不能称为集群)。这种方式也只能是在测试时使用，生产环境下不能使 用，因为存在单点问题。
单Master
Broker集群仅由多个master构成，不存在Slave。同一Topic的各个Queue会平均分布在各个master节点上。
优点:配置简单，单个Master宕机或重启维护对应用无影响，在磁盘配置为RAID10时，即使机器宕机不可恢复情况下，由于RAID10磁盘非常可靠，消息也不会丢(异步刷盘丢失少量消息，同步 刷盘一条不丢)，性能最高;
缺点:单台机器宕机期间，这台机器上未被消费的消息在机器恢复之前不可订阅(不可消费)， 消息实时性会受到影响。
多Master
Broker集群由多个master构成，每个master又配置了多个slave(在配置了RAID磁盘阵列的情况下，一 个master一般配置一个slave即可)。master与slave的关系是主备关系，即master负责处理消息的读写请求，而slave仅负责消息的备份与master宕机后的角色切换。
异步复制即前面所讲的 复制策略 中的 异步复制策略 ，即消息写入master成功后，master立即向 producer返回成功ACK，无需等待slave同步数据成功。
该模式的最大特点之一是，当master宕机后slave能够 自动切换 为master。不过由于slave从master的同步具有短暂的延迟(毫秒级)，所以当master宕机后，这种异步复制方式可能会存在少量消息的丢失问题。
多Master多Slave模式-异步复制
该模式是 多Master多Slave模式 的 同步复制 实现。所谓 同步双写 ，指的是消息写入master成功后，master会等待slave同步数据成功后才向producer返回成功ACK，即master与slave都要写入成功后才会返回成功ACK，也即双写 。
该模式与 异步复制模式 相比，优点是消息的安全性更高，不存在消息丢失的情况。但单个消息的RT略高，从而导致性能要略低(大约低10%)。
该模式存在一个大的问题:对于目前的版本，Master宕机后，Slave不会自动切换到Master。
多Master多Slave模式-同步双写
一般会为Master配置RAID10磁盘阵列，然后再为其配置一个Slave。即利用了RAID10磁盘阵列的高效、安全性，又解决了可能会影响订阅的问题。
最佳实践
Broker集群模式
集群搭建理论
Producer可以将消息写入到某Broker中的某Queue中，其经历了如下过程:
Producer发送消息之前，会先向NameServer发出获取消息Topic的路由信息的请求
NameServer返回该Topic的 路由表 及 Broker列表
Producer根据代码中指定的Queue选择策略，从Queue列表中选出一个队列，用于后续存储消息
Produer对消息做一些特殊处理，例如，消息本身超过4M，则会对其进行压缩
Producer向选择出的Queue所在的Broker发出RPC请求，将消息发送到选择出的Queue
消息的生产过程
对于无序消息，其Queue选择算法，也称为消息投递算法，常见的有两种:
轮询算法：默认选择算法。该算法保证了每个Queue中可以均匀的获取到消息。
最小投递延迟算法：该算法会统计每次消息投递的时间延迟，然后根据统计出的结果将消息投递到时间延迟最小的Queue。 如果延迟相同，则采用轮询算法投递。该算法可以有效提升消息的投递性能。
Queue选择算法
消息的生产
RocketMQ中的消息存储在本地文件系统中，这些相关文件默认在当前用户主目录下的store目录中。
commitlog目录中存放着很多的mappedFile文件，当前Broker中的所有消息都是落盘到这些 mappedFile文件中的。mappedFile文件大小为1G(小于等于1G)，文件名由20位十进制数构成，表示当前文件的第一条消息的起始位移偏移量。
需要注意的是，一个Broker中仅包含一个commitlog目录，所有的mappedFile文件都是存放在该目录中的。即无论当前Broker中存放着多少Topic的消息，这些消息都是被顺序写入到了mappedFile文件中 的。也就是说，这些消息在Broker中存放时并没有被按照Topic进行分类存放。
mappedFile文件内容由一个个的 消息单元 构成。每个消息单元中包含消息总长度MsgLen、消息的物理位置physicalOffset、消息体内容Body、消息体长度BodyLength、消息主题Topic、Topic长度 TopicLength、消息生产者BornHost、消息发送时间戳BornTimestamp、消息所在的队列QueueId、消息在Queue中存储的偏移量QueueOffset等近20余项消息相关属性。
消息单元
commitlog文件
为了提高效率，会为每个Topic在~/store/consumequeue中创建一个目录，目录名为Topic名称。在该 Topic目录下，会再为每个该Topic的Queue建立一个目录，目录名为queueId。每个目录中存放着若干 consumequeue文件，consumequeue文件是commitlog的索引文件，可以根据consumequeue定位到具体的消息。
consumequeue文件名也由20位数字构成，表示当前文件的第一个索引条目的起始位移偏移量。与 mappedFile文件名不同的是，其后续文件名是固定的。因为consumequeue文件大小是固定不变的。
每个consumequeue文件可以包含30w个索引条目，每个索引条目包含了三个消息重要属性:消息在 mappedFile文件中的偏移量CommitLog Offset、消息长度、消息Tag的hashcode值。这三个属性占20 个字节，所以每个文件的大小是固定的30w * 20字节。
span style=\
一条消息进入到Broker后经历了以下几个过程才最终被持久化。
Broker根据queueId，获取到该消息对应索引条目要在consumequeue目录中的写入偏移量，即 QueueOffset将queueId、queueOffset等数据，与消息一起封装为消息单元将消息单元写入到commitlog同时，形成消息索引条目将消息索引条目分发到相应的consumequeue
消息写入
当Consumer来拉取消息时会经历以下几个步骤
1.Consumer获取到其要消费消息所在Queue的消费偏移量offset ，计算出其要消费消息的消息offset
2.Consumer向Broker发送拉取请求，其中会包含其要拉取消息的Queue、消息offset及消息 Tag。
3.Broker计算在该consumequeue中的queueOffset。
4.从该queueOffset处开始向后查找第一个指定Tag的索引条目。
5.解析该索引条目的前8个字节，即可定位到该消息在commitlog中的commitlog offset
6.从对应commitlog offset中读取消息单元，并发送给Consumer
消息拉取
对文件的读写
RocketMQ中，无论是消息本身还是消息索引，都是存储在磁盘上的。其不会影响消息的消费吗?当然不会。其实RocketMQ的性能在目前的MQ产品中性能是非常高的。因为系统通过一系列相关机制大大提升了性能。
首先，RocketMQ对文件的读写操作是通过 mmap零拷贝 进行的，将对文件的操作转化为直接对内存地址进行操作，从而极大地提高了文件的读写效率。
其次，consumequeue中的数据是顺序存放的，还引入了 PageCache的预读取机制 ，使得对 consumequeue文件的读取几乎接近于内存读取，即使在有消息堆积情况下也不会影响性能。
RocketMQ中可能会影响性能的是对commitlog文件的读取。因为对commitlog文件来说，读取消息时会产生大量的随机访问，而随机访问会严重影响性能。不过，如果选择合适的系统IO调度算法，比如设置调度算法为Deadline(采用SSD固态硬盘的话)，随机读的性能也会有所提升。
性能提升
RocketMQ的很多思想来源于Kafka，其中commitlog与consumequeue就是。
RocketMQ中的commitlog目录与consumequeue的结合就类似于Kafka中的partition分区目录。 mappedFile文件就类似于Kafka中的segment段。
与Kafka的对比
消息的存储
拉取式消费：Consumer主动从Broker中拉取消息，主动权由Consumer控制。一旦获取了批量消息，就会启动消费过程。不过，该方式的实时性较弱，即Broker中有了新的消息时消费者并不能及时发现并消费。
推送式消费：该模式下Broker收到数据后会主动推送给Consumer。该获取方式一般实时性较高。
获取消费类型
广播消费：相同Consumer Group的每个Consumer实例都接收同一个Topic的全量消息。即每条 消息都会被发送到Consumer Group中的 每个 Consumer。
集群消费：集群消费模式下，相同Consumer Group的每个Consumer实例 平均分摊 同一个Topic的消息。即每条消息只会被发送到Consumer Group中的某个 Consumer。
消费模式
广播消费：消费进度保存在consumer端。因为广播模式下consumer group中每个consumer都会 消费所有消息，但它们的消费进度是不同。所以consumer各自保存各自的消费进度。
集群模式:消费进度保存在broker中。consumer group中的所有consumer共同消费同一个Topic 中的消息，同一条消息只会被消费一次。消费进度会参与到了消费的负载均衡中，故消费进度是需要共享的。下图是broker中存放的各个Topic的各个Queue的消费进度。
消息进度保存
Rebalance即再均衡，指的是，将一个Topic下的多个Queue在同一个Consumer Group中的多个 Consumer间进行重新分配的过程。
Rebalance机制的本意是为了提升消息的 并行消费能力 。例如，一个Topic下5个队列，在只有1个消费 者的情况下，这个消费者将负责消费这5个队列的消息。如果此时我们增加一个消费者，那么就可以给其中一个消费者分配2个队列，给另一个分配3个队列，从而提升消息的并行消费能力。
Rebalance限制：由于一个队列最多分配给一个消费者，因此当某个消费者组下的消费者实例数量 大于 队列的数量时， 多余的消费者实例将分配不到任何队列。
消费暂停:在只有一个Consumer时，其负责消费所有队列;在新增了一个Consumer后会触发 Rebalance的发生。此时原Consumer就需要暂停部分队列的消费，等到这些队列分配给新的Consumer 后，这些暂停消费的队列才能继续被消费。
消费重复:Consumer 在消费新分配给自己的队列时，必须接着之前Consumer 提交的消费进度的offset 继续消费。然而默认情况下，offset是异步提交的，这个异步性导致提交到Broker的offset与Consumer 实际消费的消息并不一致。这个不一致的差值就是可能会重复消费的消息。
消费突刺:由于Rebalance可能导致重复消费，如果需要重复消费的消息过多，或者因为Rebalance暂停 时间过长从而导致积压了部分消息。那么有可能会导致在Rebalance结束之后瞬间需要消费很多消息。
Rebalance危害
导致Rebalance产生的原因，无非就两个:消费者所订阅Topic的Queue数量发生变化，或消费者组中消费者的数量发生变化。
Rebalance产生的原因
在Broker中维护着多个Map集合，这些集合中动态存放着当前Topic中Queue的信息、Consumer Group 中Consumer实例的信息。一旦发现消费者所订阅的Queue数量发生变化，或消费者组中消费者的数量发生变化，立即向Consumer Group中的每个实例发出Rebalance通知。
Consumer实例在接收到通知后会采用 Queue分配算法自己获取到相应的Queue，即由Consumer实例自主进行Rebalance。
Rebalance过程
在Kafka中，一旦发现出现了Rebalance条件，Broker会调用Group Coordinator来完成Rebalance。 Coordinator是Broker中的一个进程。Coordinator会在Consumer Group中选出一个Group Leader。由 这个Leader根据自己本身组情况完成Partition分区的再分配。这个再分配结果会上报给Coordinator， 并由Coordinator同步给Group中的所有Consumer实例。
Kafka中的Rebalance是由Consumer Leader完成的。而RocketMQ中的Rebalance是由每个Consumer自身完成的，Group中不存在Leader。
一个Topic中的Queue只能由Consumer Group中的一个Consumer进行消费，而一个Consumer可以同时消费多个Queue中的消息。那么Queue与Consumer间的配对关系是如何确定的，即Queue要分配给哪个Consumer进行消费，也是有算法策略的。常见的有四种策略。这些策略是通过在创建Consumer时的 构造器传进去的。
平均分配策略：该算法是要根据avg = QueueCount / ConsumerCount的计算结果进行分配的。如果能够整除， 则按顺序将avg个Queue逐个分配Consumer;如果不能整除，则将多余出的Queue按照Consumer顺序逐个分配
子主题
环形平均策略：环形平均算法是指，根据消费者的顺序，依次在由queue队列组成的环形图中逐个分配。
该算法会将consumer的hash值作为Node节点存放到hash环上，然后将queue的hash值也放到hash环 上，通过 顺时针 方向，距离queue最近的那个consumer就是该queue要分配的consumer。
分配不均匀
一致性hash策略：
该算法会根据queue的部署机房位置和consumer的位置，过滤出当前consumer相同机房的queue。然 后按照平均分配策略或环形平均策略对同机房queue进行分配。如果没有同机房queue，则按照平均分 配策略或环形平均策略对所有queue进行分配。
同机房策略
一致性hash算法存在的问题:两种平均分配策略的分配效率较高，一致性hash策略的较低。因为一致性hash算法较复杂。另外，一 致性hash策略分配的结果也很大可能上存在不平均的情况。
一致性hash算法存在的意义: 其可以有效减少由于消费者组扩容或缩容所带来的大量的Rebalance。
一致性hash算法的应用场景: Consumer数量变化较频繁的场景
对比
RocketMQ有一个原则:每条消息必须要被成功消费 一次。那么什么是成功消费呢?Consumer在消费完消息后会向其消费进度记录器 提交其消费消息的offset， offset被成功记录到记录器中，那么这条消费就被成功消费了。
至少一次原则
Queue分配算法
与Kafka对比
Rebalance机制
消息的消费
当消费模式为 广播消费 时，offset使用本地模式存储。因为每条消息会被所有的消费者消费，每个消费者管理自己的消费进度，各个消费者之间不存在消费进度的交集。
Consumer在广播消费模式下offset相关数据以json的形式持久化到Consumer本地磁盘文件中，默认文件路径为当前用户主目录下的 .rocketmq_offsets/${clientId}/${group}/Offsets.json 。 其中${clientId}为当前消费者id，默认为ip@DEFAULT;${group}为消费者组名称。
offset本地管理模式：
当消费模式为 集群消费 时，offset使用远程模式管理。因为所有Cosnumer实例对消息采用的是均衡消费，所有Consumer共享Queue的消费进度。
Consumer在集群消费模式下offset相关数据以json的形式持久化到Broker磁盘文件中，文件路径为当前用户主目录下的 store/config/consumerOffset.json 。
Broker启动时会加载这个文件，并写入到一个双层Map(ConsumerOffsetManager)。外层map的key 为topic@group，value为内层map。内层map的key为queueId，value为offset。当发生Rebalance时， 新的Consumer会从该Map中获取到相应的数据来继续消费。
集群模式下offset采用远程管理模式，主要是为了保证Rebalance机制。
offset远程管理模式
消费者是如何从最开始持续消费消息的?消费者要消费的第一条消息的起始位置是用户自己通过 consumer.setConsumeFromWhere()方法指定的。
从queue的当前最后一条消息消费
从queue的第一条消息消费
从指定具体时间戳的消息开始消费
在Consumer启动后，其要消费的第一条消息的起始位置常用的有三种，这三种位置可以通过枚举类型 常量设置。这个枚举类型为ConsumeFromWhere。
当消费完一批消息后，Consumer会提交其消费进度offset给Broker，Broker在收到消费进度后会将其更 新到那个双层Map(ConsumerOffsetManager)及consumerOffset.json文件中，然后向该Consumer进 行ACK，而ACK内容中包含三项数据:当前消费队列的最小offset(minOffset)、最大 offset(maxOffset)、及下次消费的起始offset(nextBeginOffset)。
offset用途
当rocketMQ对消息的消费出现异常时，会将发生异常的消息的offset提交到Broker中的重试队列。系统 在发生消息消费异常时会为当前的topic@group创建一个重试队列，该队列以%RETRY%开头，到达重 试时间后进行消费重试。
重试队列
集群消费模式下，Consumer消费完消息后会向Broker提交消费进度offset，其提交方式分为两种:
同步提交: 消费者在消费完一批消息后会向broker提交这些消息的offset，然后等待broker的成功响应。若在等待超时之前收到了成功响应，则继续读取下一批消息进行消费(从ACK中获取 nextBeginOffset)。若没有收到响应，则会重新提交，直到获取到响应。而在这个等待过程中，消费 者是阻塞的。其严重影响了消费者的吞吐量。
异步提交: 消费者在消费完一批消息后向broker提交offset，但无需等待Broker的成功响应，可以继续读取并消费下一批消息。这种方式增加了消费者的吞吐量。但需要注意，broker在收到提交的offset 后，还是会向消费者进行响应的。可能还没有收到ACK，此时Consumer会从Broker中直接获取 nextBeginOffset。
offset的同步提交与异步提交
offset管理
当出现消费者对某条消息重复消费的情况时，重复消费的结果与消费一次的结果是相同的，并且多次消费并未对业务系统产生任何负面影响，那么这个消费过程就是消费幂等的
在互联网应用中，尤其在网络不稳定的情况下，消息很有可能会出现重复发送或重复消费。如果重复的 消息可能会影响业务处理，那么就应该对消息做幂等处理。
什么是消费幂等
当一条消息已被成功发送到Broker并完成持久化，此时出现了网络闪断，从而导致Broker对Producer应 答失败。 如果此时Producer意识到消息发送失败并尝试再次发送消息，此时Broker中就可能会出现两 条内容相同并且Message ID也相同的消息，那么后续Consumer就一定会消费两次该消息。
发送时消息重复
消息已投递到Consumer并完成业务处理，当Consumer给Broker反馈应答时网络闪断，Broker没有接收到消费成功响应。为了保证消息 至少被消费一次 的原则，Broker将在网络恢复后再次尝试投递之前 被处理过的消息。此时消费者就会收到与之前处理过的内容相同、Message ID也相同的消息。
消费时消息重复
当Consumer Group中的Consumer数量发生变化时，或其订阅的Topic的Queue数量发生变化时，会触发Rebalance，此时Consumer可能会收到曾经被消费过的消息。
Rebalance时消息重复
1. 首先通过缓存去重。在缓存中如果已经存在了某幂等令牌，则说明本次操作是重复性操作;若缓 存没有命中，则进入下一步。
2. 在唯一性处理之前，先在数据库中查询幂等令牌作为索引的数据是否存在。若存在，则说明本次 操作为重复性操作;若不存在，则进入下一步。
3. 在同一事务中完成三项操作:唯一性处理后，将幂等令牌写入到缓存，并将幂等令牌作为唯一索 引的数据写入到DB中。
1. 当支付请求到达后，首先在Redis缓存中却获取key为支付流水号的缓存value。若value不空，则 说明本次支付是重复操作，业务系统直接返回调用侧重复支付标识;若value为空，则进入下一步操作
2. 到DBMS中根据支付流水号查询是否存在相应实例。若存在，则说明本次支付是重复操作，业务系统直接返回调用侧重复支付标识;若不存在，则说明本次操作是首次操作，进入下一步完成唯一性处理
以支付场景为例:
通用解决方案
消息重复的场景分析
消费幂等的解决方案很简单:为消息指定不会重复的唯一标识。因为Message ID有可能出现重复的情 况，所以真正安全的幂等处理，不建议以Message ID作为处理依据。最好的方式是以业务唯一标识作为幂等处理的关键依据，而业务的唯一标识可以通过消息Key设置。
消费者收到消息时可以根据消息的Key即订单号来实现消费幂等:
消费幂等的实现
消费幂等
消息处理流程中，如果Consumer的消费速度跟不上Producer的发送速度，MQ中未处理的消息会越来 越多(进的多出的少)，这部分消息就被称为 堆积消息 。消息出现堆积进而会造成消息的消费延迟 。以下场景需要重点关注消息堆积和消费延迟问题:
业务系统上下游能力不匹配造成的持续堆积，且无法自行恢复。
务系统对消息的消费实时性要求较高，即使是短暂的堆积造成的消费延迟也无法接受。
消息堆积与消费延迟
消息是被顺序存储在commitlog文件的，且消息大小不定长，所以消息的清理是不可能以消息为单位进行清理的，而是以commitlog文件为单位进行清理的。否则会急剧下降清理效率，并实现逻辑复杂。
commitlog文件存在一个 过期时间 ，默认为72小时，即三天。除了用户手动清理外，在以下情况下也 会被自动清理，无论文件中的消息是否被消费过:
文件过期，且到达清理时间点 (默认为凌晨4点)后，自动清理过期文件 文件过期，且磁盘空间占用率已达 过期清理警戒线 (默认75%)后，无论是否达到清理时间点，都会自动清理过期文件磁盘占用率达到 清理警戒线 (默认85%)后，开始按照设定好的规则清理文件，无论是否过期。默认会从最老的文件开始清理磁盘占用率达到 系统危险警戒线 (默认90%)后，Broker将拒绝消息写入
消息的清理
RocketMQ工作原理
RocketMQ
Kafka 中消息是以 topic 进行分类的，生产者生产消息，消费者消费消息，都是面向 topic 的。
topic 是逻辑上的概念，而 partition 是物理上的概念，每个 partition 对应于一个 log 文 件，该 log 文件中存储的就是 producer 生产的数据。Producer 生产的数据会被不断追加到该 log 文件末端，且每条数据都有自己的 offset。消费者组中的每个消费者，都会实时记录自己 消费到了哪个 offset，以便出错恢复时，从上次的位置继续消费。
Kafka 工作流程
index 和 log 文件以当前 segment 的第一条消息的 offset 命名。下图为 index 文件和 log 文件的结构示意图。
“.index”文件存储大量的索引信息，“.log”文件存储大量的数据，索引文件中的元数据指向对应数据文件中 message 的物理偏移地址。
Kafka文件存储机制
方便在集群中扩展，每个 Partition 可以通过调整以适应它所在的机器，而一个 topic又可以有多个 Partition 组成，因此整个集群就可以适应任意大小的数据了;
可以提高并发，因为可以以 Partition 为单位读写了。
分区的原因
指明 partition 的情况下，直接将指明的值直接作为 partiton值;
没有指明 partition 值但有 key 的情况下，将 key 的 hash 值与 topic 的 partition 数进行取余得到 partition 值;
既没有 partition 值又没有 key 值的情况下，第一次调用时随机生成一个整数(后面每次调用在这个整数上自增)，将这个值与 topic 可用的 partition 总数取余得到 partition 值，也就是常说的 round-robin 算法。
分区的原则
分区策略
为保证 producer 发送的数据，能可靠的发送到指定的 topic，topic 的每个 partition 收到 producer 发送的数据后，都需要向 producer 发送 ack(acknowledgement 确认收到)，如果 producer 收到 ack，就会进行下一轮的发送，否则重新发送数据。
采用第二种方案之后，设想以下情景:leader 收到数据，所有 follower 都开始同步数据， 但有一个 follower，因为某种故障，迟迟不能与 leader 进行同步，那 leader 就要一直等下去， 直到它完成同步，才能发送 ack。这个问题怎么解决呢?
leader 维护了一个动态的 in-sync replica set (ISR)，意为和 leader 保持同步的 follower 集 合。当 ISR 中的 follower 完成数据的同步之后，leader 就会给 follower 发送 ack。如果 follower 长时间未向 leader 同步数据，则该 follower 将被踢出 ISR，该时间阈值由replica.lag.time.max.ms 参数设定。Leader 发生故障之后，就会从 ISR 中选举新的 leader。
ISR
副本数据同步策略
对于某些不太重要的数据，对数据的可靠性要求不是很高，能够容忍数据的少量丢失， 所以没必要等 ISR 中的 follower 全部接收成功。所以 Kafka 为用户提供了三种可靠性级别，用户根据对可靠性和延迟的要求进行权衡， 选择以下的配置。
0:producer 不等待 broker 的 ack，这一操作提供了一个最低的延迟，broker 一接收到还 没有写入磁盘就已经返回，当 broker 故障时有可能丢失数据;
1:producer 等待 broker 的 ack，partition 的 leader 落盘成功后返回 ack，如果在 follower 同步成功之前 leader 故障，那么将会丢失数据;
-1(all):producer 等待 broker 的 ack，partition 的 leader 和 follower 全部落盘成功后才 返回 ack。但是如果在 follower 同步完成后，broker 发送 ack 之前，leader 发生故障，那么会造成数据重复
ack 应答机制
LEO:指的是每个副本最大的 offset
HW:指的是消费者能见到的最大的 offset，ISR 队列中最小的 LEO。
follower 发生故障后会被临时踢出 ISR，待该 follower 恢复后，follower 会读取本地磁盘 记录的上次的HW，并将 log 文件高于 HW 的部分截取掉，从 HW 开始向 leader 进行同步。 等该 follower 的 LEO 大于等于该 Partition 的 HW，即 follower 追上 leader 之后，就可以重 新加入 ISR 了。
follower 故障
leader 发生故障之后，会从 ISR 中选出一个新的 leader，之后，为保证多个副本之间的数据一致性，其余的 follower 会先将各自的 log 文件高于 HW 的部分截掉，然后从新的 leader 同步数据。
注意:这只能保证副本之间的数据一致性，并不能保证数据不丢失或者不重复。
leader 故障
故障处理细节
数据可靠性保证
Kafka 生产者
pull 模式不足之处是，如果 kafka 没有数据，消费者可能会陷入循环中，一直返回空数 据。针对这一点，Kafka 的消费者在消费数据时会传入一个时长参数 timeout，如果当前没有数据可供消费，consumer 会等待一段时间之后再返回，这段时长即为 timeout。
consumer 采用 pull(拉)模式从 broker 中读取数据。
push(推)模式很难适应消费速率不同的消费者，因为消息发送速率是由 broker 决定的。它的目标是尽可能以最快速度传递消息，但是这样很容易造成 consumer 来不及处理消息，典型的表现就是拒绝服务以及网络拥塞。而 pull 模式则可以根据 consumer 的消费能力以适 当的速率消费消息。
消费方式
一个 consumer group 中有多个 consumer，一个 topic 有多个 partition，所以必然会涉及 到 partition 的分配问题，即确定那个 partition 由哪个 consumer 来消费。Kafka 有两种分配策略，一是 RoundRobin，一是 Range。
RoundRobin：
Range
分区分配策略
由于 consumer 在消费过程中可能会出现断电宕机等故障，consumer 恢复后，需要从故障前的位置的继续消费，所以 consumer 需要实时记录自己消费到了哪个 offset，以便故障恢 复后继续消费。
offset的维护
Kafka 消费者
Kafka 的 producer 生产数据，要写入到 log 文件中，写的过程是一直追加到文件末端， 为顺序写。官网有数据表明，同样的磁盘，顺序写能到 600M/s，而随机写只有 100K/s。这与磁盘的机械机构有关，顺序写之所以快，是因为其省去了大量磁头寻址的时间。
顺序写磁盘
零复制技术
Kafka 高效读写数据
Kafka 集群中有一个 broker 会被选举为 Controller，负责管理集群 broker 的上下线，所有 topic 的分区副本分配和 leader 选举等工作。Controller 的管理工作都是依赖于 Zookeeper 的。 以下为 partition 的 leader 选举过程:
Zookeeper 在 Kafka 中的作用
为了实现跨分区跨会话的事务，需要引入一个全局唯一的 Transaction ID，并将 Producer 获得的 PID 和 Transaction ID 绑定。这样当 Producer 重启后就可以通过正在进行的 Transaction ID 获得原来的 PID。
为了管理 Transaction，Kafka 引入了一个新的组件 Transaction Coordinator。Producer 就 是通过和 Transaction Coordinator 交互获得 Transaction ID 对应的任务状态。Transaction Coordinator 还负责将事务所有写入 Kafka 的一个内部 Topic，这样即使整个服务重启，由于 事务状态得到保存，进行中的事务状态可以得到恢复，从而继续进行。
Producer 事务
上述事务机制主要是从 Producer 方面考虑，对于 Consumer 而言，事务的保证就会相对 较弱，尤其时无法保证 Commit 的信息被精确消费。这是由于 Consumer 可以通过 offset 访 问任意信息，而且不同的 Segment File 生命周期不同，同一事务的消息可能会出现重启后被 删除的情况。
Consumer 事务
Kafka 事务
Kafka
图中的前两列是队列的基本信息，包括话题名和分区名；第三列是当前消费者的消费进度；第四列是当前生产消息的总数；第五列就是消费消息的堆积数（也就是第四列与第三列的差值）。
Kafka 提供了工具叫做“kafka-consumer-groups.sh”
https://static001.geekbang.org/resource/image/33/2c/3384d3fcb52f98815fac667e5b543e2c.jpg
第二个工具是 JMX。
你先定义一种特殊的消息，然后启动一个监控程序将这个消息定时地循环写入到消息队列中，消息的内容可以是生成消息的时间戳并且也会作为队列的消费者消费数据。业务处理程序消费到这个消息时直接丢弃掉，而监控程序在消费到这个消息时就可以和这个消息的生成时间做比较，如果时间差达到某一个阈值就可以向我们报警。
通过生成监控消息的方式来监控消息的延迟。具体怎么做呢？
如何监控消息延迟？
优化消费代码提升性能
不过第二种方式会受限于消息队列的实现。如果消息队列使用的是 Kafka 就无法通过增加消费者数量的方式来提升消息处理能力。因为在 Kafka 中，一个 Topic（话题）可以配置多个 Partition（分区），数据会被平均或者按照生产者指定的方式写入到多个分区中，那么在消费的时候，Kafka 约定一个分区只能被一个消费者消费，为什么要这么设计呢？在我看来，如果有多个 consumer（消费者）可以消费一个分区的数据，那么在操作这个消费进度的时候就需要加锁，可能会对性能有一定的影响。所以说，话题的分区数量决定了消费的并行度，增加多余的消费者也是没有用处的，你可以通过增加分区来提高消费者的处理能力。
虽然不能增加 consumer，但你可以在一个 consumer 中提升处理消息的并行度，所以可以考虑使用多线程的方式来增加处理能力：你可以预先创建一个或者多个线程池，在接收到消息之后把消息丢到线程池中来异步地处理，这样，原本串行的消费消息的流程就变成了并行的消费，可以提高消息消费的吞吐量，在并行处理的前提下，我们就可以在一次和消息队列的交互中多拉取几条数据，然后分配给多个线程来处理。
增加消费者的数量（这个方式比较简单）。
消费端
最初在设计的时候为了实现简单，使用了普通的数据库来存储消息，但是受限于数据库的性能瓶颈，读取 QPS 只能到 2000，后面我重构了存储模块，使用本地磁盘作为存储介质。Page Cache 的存在就可以提升消息的读取速度，即使要读取磁盘中的数据，由于消息的读取是顺序的并且不需要跨网络读取数据，所以读取消息的 QPS 提升了一个数量级。
说是零拷贝，其实我们不可能消灭数据的拷贝，只是尽量减少拷贝的次数。在读取消息队列的数据的时候，其实就是把磁盘中的数据通过网络发送给消费客户端，在实现上会有四次数据拷贝的步骤：
1. 数据从磁盘拷贝到内核缓冲区；2. 系统调用将内核缓存区的数据拷贝到用户缓冲区；3. 用户缓冲区的数据被写入到 Socket 缓冲区中；4. 操作系统再将 Socket 缓冲区的数据拷贝到网卡的缓冲区中。
操作系统提供了 Sendfile 函数可以减少数据被拷贝的次数。使用了 Sendfile 之后，在内核缓冲区的数据不会被拷贝到用户缓冲区而是直接被拷贝到 Socket 缓冲区，节省了一次拷贝的过程提升了消息发送的性能。高级语言中对于 Sendfile 函数有封装，比如说在 Java 里面的 java.nio.channels.FileChannel 类就提供了 transferTo 方法提供了 Sendfile 的功能。
零拷贝技术
消息队列
减少消息延迟的正确姿势
如何降低消息队列系统中消息的延迟？
消息队列是独立部署在单独的服务器上的。两者之间的网络虽然是内网但是也会存在抖动的可能，而一旦发生抖动，消息就有可能因为网络的错误而丢失。
针对这种情况，我建议你采用的方案是消息重传。
消息从生产者写入到消息队列的过程；
拿 Kafka 举例，消息在 Kafka 中是存储在本地磁盘上的，而为了减少消息存储时对磁盘的随机 I/O，我们一般会将消息先写入到操作系统的 Page Cache 中，然后再找合适的时机刷新到磁盘上。
Kafka 可以配置当达到某一时间间隔或者累积一定的消息数量的时候再刷盘，也就是所说的异步刷盘。
Kafka 集群中有一个 Leader 负责消息的写入和消费，可以有多个 Follower 负责数据的备份。Follower 中有一个特殊的集合叫做 ISR（in-sync replicas），当 Leader 故障时，新选举出来的 Leader 会从 ISR 中选择，默认 Leader 的数据会异步地复制给 Follower，这样在 Leader 发生掉电或者宕机时，Kafka 会从 Follower 中消费消息，减少消息丢失的可能。
由于默认消息是异步地从 Leader 复制到 Follower 的，所以一旦 Leader 宕机，那些还没有来得及复制到 Follower 的消息还是会丢失。为了解决这个问题，Kafka 为生产者提供一个选项叫做“acks”，当这个选项被设置为“all”时，生产者发送的每一条消息除了发给 Leader 外还会发给所有的 ISR，并且必须得到 Leader 和所有 ISR 的确认后才被认为发送成功。这样，只有 Leader 和所有的 ISR 都挂了消息才会丢失。
Page Cache 中还没有来得及刷盘的消息就会丢失了。那么怎么解决呢？
消息在消息队列中的存储场景；
我还是以 Kafka 为例来说明。一个消费者消费消息的进度是记录在消息队列集群中的，而消费的过程分为三步：接收消息、处理消息、更新消费进度。
这里面接收消息和处理消息的过程都可能会发生异常或者失败，比如消息接收时网络发生抖动，导致消息并没有被正确地接收到；处理消息时可能发生一些业务的异常导致处理流程未执行完成，这时如果更新消费进度，这条失败的消息就永远不会被处理了，也可以认为是丢失了。
所以，在这里你需要注意的是，一定要等到消息接收和处理完成后才能更新消费进度，但是这也会造成消息重复的问题，比方说某一条消息在处理之后消费者恰好宕机了，那么因为没有更新消费进度，所以当这个消费者重启之后还会重复地消费这条消息
消息被消费者消费的过程。
保证在消息的生产和消费的过程是“幂等”的
在消息生产过程中，在 Kafka0.11 版本和 Pulsar 中都支持“producer idempotency”的特性，翻译过来就是生产过程的幂等性，这种特性保证消息虽然可能在生产端产生重复，但是最终在消息队列存储时只会存储一份。它的做法是给每一个生产者一个唯一的 ID，并且为生产的每一条消息赋予一个唯一 ID，消息队列的服务端会存储 < 生产者 ID，最后一条消息 ID> 的映射。当某一个生产者产生新的消息时，消息队列服务端会比对消息 ID 是否与存储的最后一条 ID 一致，如果一致就认为是重复的消息，服务端会自动丢弃。
如何保证消息只被消费一次
消息一定会被消费到并且只被消费一次呢？
消息中间件
Docker
Master 是控制节点，部署着 Kubernetes 的控制面，负责整个集群的管理和控制
它 是整个 Kubernetes 集群的“灵魂”，是信息的汇聚中枢，提供了所有内部和外部的 API 请求操作的唯一入口。同时也负责整个集群的认证、授权、访问控制、服务发现等能力。
用户可以通过命令行工具 kubectl 和 APIServer 进行交互，从而实现对集群中进行各种资源的增删改查等操作。APIServer 跟 BorgMaster 非常类似，会将所有的改动持久到 Etcd 中，同时也保存着一份内存拷贝
这也是为什么我们希望 Master 节点可以性能好、资源规格大，尤其是当集群规模很大的时候，APIServer 的吞吐量以及占用的 CPU 和内存都要很大。APIServer 还提供很多可扩展的能力，方便增强自己的功能
kube-apiserver
它负责维护整个 Kubernetes 集群的状态，比如多副本创建、滚动更新等。Kube-controller-manager 并不是一个单一组件，内部包含了一组资源控制器，在启动的时候，会通过 goroutine 拉起多个资源控制器。这些控制器的逻辑仅依赖于当前状态，因为在分布式系统中没办法保证全局状态的同步。
在实现的时候避免使用过于复杂的状态机，因此每个控制器仅仅对自己对应的资源对象做操作。而且控制器做了很多容错处理，比如增加 retry 机制等。
kube-scheduler
它的工作简单来说就是监听未调度的 Pod，按照预定的调度策略绑定到满足条件的节点上
kube-controller-manager
Master
Node 为计算节点，或者叫作工作负载节点，每个 Node 上都会运行一些负载容器。
Kubelet 负责维护 Pod 的生命周期，比如创建和删除 Pod 对应的容器。同时也负责存储和网络的管理。一般会配合 CSI、CNI 插件一起工作。
Kube-Proxy 主要负责 Kubernetes 内部的服务通信，在主机上维护网络规则并提供转发及负载均衡能力
Node
用于保存集群中的所有对象以及状态信息。有的时候，我们会将 Etcd 集群也一起部署到 Master 上。但是在集群节点资源足够的情况下，我个人建议可以考虑将 Etcd 集群单独部署，因为Etcd中的数据可是至关重要的，必须要保证 Etcd 数据的安全。Etcd 采用 Raft 协议实现
分布式存储系统 Etcd
CoreDNS 负责为整个集群提供 DNS 服务；
Ingress Controller 为服务提供外网接入能力；
Dashboard 提供 GUI 可视化界面
Fluentd + Elasticsearch 为集群提供日志采集、存储与查询等能力。
Kubernetes 的架构
Pod 由一个或多个容器组成，如下图所示。Pod 中的容器不可分割，会作为一个整体运行在一个 Node 节点上，也就是说 Pod 是你在 Kubernetes 中可以创建和部署的最原子化的单位
每个 Pod 都会拥有一个独立的网络空间，其内部的所有容器都共享网络资源，即 IP 地址、端口。内部的容器直接通过 localhost 就可以通信。
Pod 可以挂载多个共享的存储卷（Volume），这时内部的各个容器就可以访问共享的 Volume 进行数据的读写。
Pod是什么？
容器之间会发生文件交换等，上面提到的例子就是这样。一个写文件，一个读文件。
容器之间需要本地通信，比如通过 localhost 或者本地的 Socket。这种方式有时候可以简化业务的逻辑，因为此时业务就不用关心另外一个服务的地址，直接本地访问就可以了。
容器之间需要发生频繁的 RPC 调用，出于性能的考量，将它们放在一个 Pod 内。
希望为应用添加其他功能，比如日志收集、监控数据采集、配置中心、路由及熔断等功能。这时候可以考虑利用边车模式（Sidecar Pattern），既不需要改动原始服务本身的逻辑，还能增加一系列的功能。比如 Fluentd 就是利用边车模式注入一个对应 log agent 到 Pod 内，用于日志的收集和转发。 Istio 也是通过在 Pod 内放置一个 Sidecar 容器，来进行无侵入的服务治理。
一个 Pod 内运行多个容器，比较适应于以下这些场景
因为使用一个新的逻辑对象 Pod 来管理容器，可以在不重载容器信息的基础上，添加更多的属性，而且也方便跟容器运行时进行解耦，兼容度高。比如：
存活探针（Liveness Probe）可以从应用程序的角度去探测一个进程是否还存活着，在容器出现问题之前，就可以快速检测到问题；
容器启动后和终止前可以进行的操作，比如，在容器停止前，可能需要做一些清理工作，或者不能马上结束进程；
定义了容器终止后要采取的策略，比如始终重启、正常退出才重启等；
为什么 Kubernetes 不直接管理容器，而用 Pod 来管理呢？
由于容器实际上是一个“单进程”的模型，这点非常重要。因为如果你在容器里启动多个进程，这将会带来很多麻烦。不仅它们的日志记录会混在一起，它们各自的生命周期也无法管理。毕竟只有一个进程的 PID 可以为 1，如果 PID 为 1 的进程这个时候挂了，或者说失败退出了，那么其他几个进程就会自然而然地成为“孤儿”，无法管理，也无法回收资源。
用一个 Pod 管理多个容器，既能够保持容器之间的隔离性，还能保证相关容器的环境一致性。使用粒度更小的容器，不仅可以使应用间的依赖解耦，还便于使用不同技术栈进行开发，同时还可以方便各个开发团队复用，减少重复造轮子。
为什么要允许一个 Pod 内可以包含多个容器？
Kubernetes 中定义了如下三种重启策略，可以通过spec.restartPolicy字段在 Pod 定义中进行设置。
Always 表示一直重启，这也是默认的重启策略。Kubelet 会定期查询容器的状态，一旦某个容器处于退出状态，就对其执行重启操作；
OnFailure 表示只有在容器异常退出，即退出码不为 0 时，才会对其进行重启操作
Never 表示从不重启；
Pod 的重启策略
livenessProbe可以用来探测容器是否真的在“运行”，即“探活”。如果检测失败的话，这个时候 kubelet 就会停掉该容器，容器的后续操作会受到其重启策略的影响。
readinessProbe常常用于指示容器是否可以对外提供正常的服务请求，即“就绪”，比如 nginx 容器在 reload 配置的时候无法对外提供 HTTP 服务。
为了简化一些通用的处理逻辑，Kubernetes 也为这些 Probe 内置了如下三个 Handler：ExecAction 可以在容器内执行 shell 脚本；HTTPGetAction 方便对指定的端口和 IP 地址执行 HTTP Get 请求；TCPSocketAction 可以对指定端口进行 TCP 检查；
Pod 中的健康检查
PostStart 可以在容器启动之后就执行。但需要注意的是，此 hook 和容器里的 ENTRYPOINT 命令的执行顺序是不确定的。
PreStop 则在容器被终止之前被执行，是一种阻塞式的方式。执行完成后，Kubelet 才真正开始销毁容器。
同上面的 Probe 一样，hook 也有类似的 Handler：Exec 用来执行 Shell 命令；HTTPGet 可以执行 HTTP 请求。
容器生命周期内的 hook
Pod
我们可以由 Deployment 来创建 ReplicaSet，再由 ReplicaSet 来创建 Pod，当我们更新了 Deployment 中的信息以后（比如更新了镜像的版本），部署控制器就会跟踪到新的期望状态，自动地创建新 ReplicaSet，并逐渐缩减旧的 ReplicaSet 的副本数，直到升级完成后，彻底删除掉旧 ReplicaSet。
Deployment
普通 ReplicaSet 中的 Pod 相比，由 StatefulSet 管理的 Pod 具备几项额外特性。
Pod 会按顺序创建和按顺序销毁：StatefulSet 中的各个 Pod 会按顺序地创建出来，而且，再创建后面的 Pod 之前，必须要保证前面的 Pod 已经转入就绪状态。如果要销毁 StatefulSet 中的 Pod，就会按照与创建顺序的逆序来执行。
Pod 具有稳定的网络名称：Kubernetes 中的 Pod 都具有唯一的名称，在普通的副本集中，这是靠随机字符产生的，而在 StatefulSet 中管理的 Pod，会以带有顺序的编号作为名称，而且能够在重启后依然保持不变。
Pod 具有稳定的持久存储：StatefulSet 中的每个 Pod 都可以拥有自己独立的 PersistentVolumeClaim 资源。即使 Pod 被重新调度到其他节点上，它所拥有的持久磁盘也依然会被挂载到该 Pod，这点会在“容器持久化”这个小章节中进一步介绍。
StatefulSet
ConfigMap
如果该 Service 有 ClusterIP，我们就可以直接用这个虚拟 IP 去访问。
当然我们也可以使用该 Service 的域名，依赖于集群内部的 DNS 即可访问。
集群内如何访问 Service？
通过 kube-proxy 来实现的。所有的节点上都会运行着一个 kube-proxy的服务，主要监听 Kubernetes 中的 Service 和 Endpoints。当 Service 或 Endpoints 发生变化时，就会调用相应的接口创建对应的规则出来，常用模式主要是 iptables 模式和 IPVS 模式。iptables 模式比较简单，使用起来也方便。而 IPVS 支持更高的吞吐量以及复杂的负载均衡策略，你可以通过官方文档了解更多 IPVS 模式的工作原理。
目前 kube-proxy 默认的工作方式是 iptables 模式
当你通过 Service 的域名去访问时，会先通过 CoreDNS 解析出 Service 对应的 Cluster IP，即虚拟 IP。然后请求到达宿主机的网络后，就会被kube-proxy所配置的 iptables 规则所拦截，之后请求会被转发到每一个实际的后端 Pod 上面去，这样就实现了负载均衡。
集群内部的负载均衡如何实现？
如果我们在定义 Service 的时候，将spec.clusterIP设置为 None，这个时候创建出来的 Service 并不会分配到一个 Cluster IP，此时它就被称为Headless Service。
Headless Servicenginx-prod-demo-headless-svc则解析到所有后端的 Pod 的地址。
用户可以自己选择要连接哪个 Pod，通过查询 Service 的 DNS 记录来获取后端真实负载的 IP 地址，自主选择要连接哪个 IP；
可用于部署有状态服务。回顾下，我们在 StatefulSet 那节课也有 Headless Service 例子，每个 StatefulSet 管理的 Pod 都有一个单独的 DNS 记录，且域名保持不变，即<PodName>.<ServiceName>.<NamespaceName>.svc.cluster.local。这样 Statefulset 中的各个 Pod 就可以直接通过 Pod 名字解决相互间身份以及访问问题。
Headless Service
Service
监控数据收集，比如可以将节点信息收集上报给 Prometheus；
日志的收集、轮转和清理；
监控节点状态，比如运行 node-problem-detector 来监测节点的状态，并上报给 APIServer；
负责在每个节点上网络、存储等组件的运行，比如 glusterd、ceph、flannel 等
DaemonSet 的使用场景
DaemonSet
Kubernetes
容器服务
设计模式
如果线程池中的线程数少于 coreThreadCount 时，处理新的任务时会创建新的线程；
如果线程数大于 coreThreadCount 则把任务丢到一个队列里面，由当前空闲的线程执行；
当队列中的任务堆积满了的时候，则继续创建线程，直到达到 maxThreadCount；
当线程数达到 maxTheadCount 时还有新的任务提交，那么我们就不得不将它们丢弃了。
线程池预先创建线程流程
JDK 实现的这个线程池优先把任务放入队列暂存起来，而不是创建更多的线程，它比较适用于执行 CPU 密集型的任务，也就是需要执行大量 CPU 运算的任务。这是为什么呢？因为执行 CPU 密集型的任务时 CPU 比较繁忙，因此只需要创建和 CPU 核数相当的线程就好了，多了反而会造成线程上下文切换，降低任务执行效率。所以当前线程数超过核心线程数时，线程池不会增加线程，而是放在队列里等待核心线程空闲下来。
但是，我们平时开发的 Web 系统通常都有大量的 IO 操作，比方说查询数据库、查询缓存等等。任务在执行 IO 操作的时候 CPU 就空闲了下来，这时如果增加执行任务的线程数而不是把任务暂存在队列中，就可以在单位时间内执行更多的任务，大大提高了任务执行的吞吐量。所以你看 Tomcat 使用的线程池就不是 JDK 原生的线程池，而是做了一些改造，当线程数超过 coreThreadCount 之后会优先创建线程，直到线程数到达 maxThreadCount，这样就比较适合于 Web 系统大量 IO 操作的场景了，你在实际使用过程中也可以参考借鉴。
其次，线程池中使用的队列的堆积量也是我们需要监控的重要指标，对于实时性要求比较高的任务来说，这个指标尤为关键
最后，如果你使用线程池请一定记住不要使用无界队列（即没有设置固定大小的队列）。也许你会觉得使用了无界队列后，任务就永远不会被丢弃，只要任务对实时性要求不高，反正早晚有消费完的一天。但是，大量的任务堆积会占用大量的内存空间，一旦内存空间被占满就会频繁地触发 Full GC，造成服务不可用，我之前排查过的一次 GC 引起的宕机，起因就是系统中的一个线程池使用了无界队列。
线程池需注意的问题
线程池
Synchronized 在修饰同步代码块时，是由 monitorenter 和 monitorexit 指令来实现同步的。进入 monitorenter 指令后，线程将持有 Monitor 对象，退出 monitorenter 指令后，线程将释放该 Monitor 对象。
一种是修饰代码块
当 Synchronized 修饰同步方法时，并没有发现 monitorenter 和 monitorexit 指令，而是出现了一个 ACC_SYNCHRONIZED 标志。
这是因为 JVM 使用了 ACC_SYNCHRONIZED 访问标志来区分一个方法是否是同步方法。当方法调用时，调用指令将会检查该方法是否被设置 ACC_SYNCHRONIZED 访问标志。如果设置了该标志，执行线程将先持有 Monitor 对象，然后再执行方法。在该方法运行期间，其它线程将无法获取到该 Mointor 对象，当方法执行完成后，再释放该 Monitor 对象。
JVM 中的同步是基于进入和退出管程（Monitor）对象实现的。每个对象实例都会有一个 Monitor，Monitor 可以和对象一起创建、销毁。Monitor 是由 ObjectMonitor 实现，而 ObjectMonitor 是由 C++ 的 ObjectMonitor.hpp 文件实现，如下所示：
当多个线程同时访问一段同步代码时，多个线程会先被存放在 ContentionList 和 _EntryList 集合中，处于 block 状态的线程，都会被加入到该列表。接下来当线程获取到对象的 Monitor 时，Monitor 是依靠底层操作系统的 Mutex Lock 来实现互斥的，线程申请 Mutex 成功，则持有该 Mutex，其它线程将无法获取到该 Mutex，竞争失败的线程会再次进入 ContentionList 被挂起。
如果线程调用 wait() 方法，就会释放当前持有的 Mutex，并且该线程会进入 WaitSet 集合中，等待下一次被唤醒。如果当前线程顺利执行完方法，也将释放 Mutex。
一种是修饰方法
偏向锁主要用来优化同一线程多次申请同一个锁的竞争。在某些情况下，大部分时间是同一个线程竞争锁资源，例如，在创建一个线程并在线程中执行循环监听的场景下，或单线程操作一个线程安全集合时，同一线程每次都需要获取和释放锁，每次操作都会发生用户态与内核态的切换。
偏向锁的作用就是，当一个线程再次访问这个同步代码或方法时，该线程只需去对象头的 Mark Word 中去判断一下是否有偏向锁指向它的 ID，无需再进入 Monitor 去竞争对象了。当对象被当做同步锁并有一个线程抢到了锁时，锁标志位还是 01，“是否偏向锁”标志位设置为 1，并且记录抢到锁的线程 ID，表示进入偏向锁状态。
一旦出现其它线程竞争锁资源时，偏向锁就会被撤销。偏向锁的撤销需要等待全局安全点，暂停持有该锁的线程，同时检查该线程是否还在执行该方法，如果是，则升级锁，反之则被其它线程抢占。
在高并发场景下，当大量线程同时竞争同一个锁资源时，偏向锁就会被撤销，发生 stop the word 后， 开启偏向锁无疑会带来更大的性能开销，这时我们可以通过添加 JVM 参数关闭偏向锁来调优系统性能，示例代码如下-XX:-UseBiasedLocking //关闭偏向锁（默认打开）
偏向锁获取与撤销流程
偏向锁
有另外一个线程竞争获取这个锁时，由于该锁已经是偏向锁，当发现对象头 Mark Word 中的线程 ID 不是自己的线程 ID，就会进行 CAS 操作获取锁，如果获取成功，直接替换 Mark Word 中的线程 ID 为自己的 ID，该锁会保持偏向锁状态；如果获取锁失败，代表当前锁有一定的竞争，偏向锁将升级为轻量级锁。
轻量级锁适用于线程交替执行同步块的场景，绝大部分的锁在整个同步周期内都不存在长时间的竞争。
升级轻量级锁流程
轻量级锁
轻量级锁 CAS 抢锁失败，线程将会被挂起进入阻塞状态。如果正在持有锁的线程在很短的时间内释放资源，那么进入阻塞状态的线程无疑又要申请锁资源。
JVM 提供了一种自旋锁，可以通过自旋方式不断尝试获取锁，从而避免线程被挂起阻塞。这是基于大多数情况下，线程持有锁的时间都不会太长，毕竟线程被挂起阻塞可能会得不偿失。
从 JDK1.7 开始，自旋锁默认启用，自旋次数由 JVM 设置决定，这里我不建议设置的重试次数过多，因为 CAS 重试操作意味着长时间地占用 CPU。
自旋锁重试之后如果抢锁依然失败，同步锁就会升级至重量级锁，锁标志位改为 10。在这个状态下，未抢到锁的线程都会进入 Monitor，之后会被阻塞在 _WaitSet 队列中。
自旋后升级为重量级锁的流程
在锁竞争不激烈且锁占用时间非常短的场景下，自旋锁可以提高系统性能。一旦锁竞争激烈或锁占用的时间过长，自旋锁将会导致大量的线程一直处于 CAS 重试状态，占用 CPU 资源，反而会增加系统性能开销。所以自旋锁和重量级锁的使用都要结合实际场景。
在高负载、高并发的场景下，我们可以通过设置 JVM 参数来关闭自旋锁，优化系统性能，示例代码如下：-XX:-UseSpinning //参数关闭自旋锁优化(默认打开) -XX:PreBlockSpin //参数修改默认的自旋次数。JDK1.7后，去掉此参数，由jvm控制
自旋锁与重量级锁
锁升级优化
Java 还使用了编译器对锁进行优化。JIT 编译器在动态编译同步块的时候，借助了一种被称为逃逸分析的技术，来判断同步块使用的锁对象是否只能够被一个线程访问，而没有被发布到其它线程
JIT 编译器在编译这个同步块的时候不会生成 synchronized 所表示的锁的申请与释放的机器码，即消除了锁的使用。在 Java7 之后的版本就不需要手动配置了，该操作可以自动实现。
锁粗化同理，就是在 JIT 编译器动态编译时，如果发现几个相邻的同步块使用的是同一个锁实例，那么 JIT 编译器将会把这几个同步块合并为一个大的同步块，从而避免一个线程“反复申请、释放同一个锁”所带来的性能开销
动态编译实现锁消除 / 锁粗化
Synchronized
AQS 类结构中包含一个基于链表实现的等待队列（CLH 队列），用于存储所有阻塞的线程，
AQS 中还有一个 state 变量，该变量对 ReentrantLock 来说表示加锁状态。
获取锁流程
AQS
RRW 也是基于 AQS 实现的，它的自定义同步器（继承 AQS）需要在同步状态 state 上维护多个读线程和一个写线程的状态，该状态的设计成为实现读写锁的关键。RRW 很好地使用了高低位，来实现一个整型控制两种状态的功能，读写锁将变量切分成了两个部分，高 16 位表示读，低 16 位表示写。
一个线程尝试获取写锁时，会先判断同步状态 state 是否为 0。如果 state 等于 0，说明暂时没有其它线程获取锁；如果 state 不等于 0，则说明有其它线程获取了锁。
此时再判断同步状态 state 的低 16 位（w）是否为 0，如果 w 为 0，则说明其它线程获取了读锁，此时进入 CLH 队列进行阻塞等待；如果 w 不为 0，则说明其它线程获取了写锁，此时要判断获取了写锁的是不是当前线程，若不是就进入 CLH 队列进行阻塞等待；若是，就应该判断当前线程获取写锁是否超过了最大次数，若超过，抛异常，反之更新同步状态。
获取写锁流程
一个线程尝试获取读锁时，同样会先判断同步状态 state 是否为 0。如果 state 等于 0，说明暂时没有其它线程获取锁，此时判断是否需要阻塞，如果需要阻塞，则进入 CLH 队列进行阻塞等待；如果不需要阻塞，则 CAS 更新同步状态为读状态。
如果 state 不等于 0，会判断同步状态低 16 位，如果存在写锁，则获取读锁失败，进入 CLH 阻塞队列；反之，判断当前线程是否应该被阻塞，如果不应该阻塞则尝试 CAS 同步状态，获取成功更新同步锁为读状态。
获取读锁流程
读写锁 ReentrantReadWriteLock
RRW 被很好地应用在了读大于写的并发场景中，然而 RRW 在性能上还有可提升的空间。在读取很多、写入很少的情况下，RRW 会使写入线程遭遇饥饿（Starvation）问题，也就是说写入线程会因迟迟无法竞争到锁而一直处于等待状态。
Java 提供了 StampedLock 类解决了这个问题。StampedLock 不是基于 AQS 实现的，但实现的原理和 AQS 是一样的，都是基于队列和锁状态实现的。与 RRW 不一样的是，StampedLock 控制锁有三种模式: 写、悲观读以及乐观读，并且 StampedLock 在获取锁时会返回一个票据 stamp，获取的 stamp 除了在释放锁时需要校验，在乐观读模式下，stamp 还会作为读取共享资源后的二次校验，后面我会讲解 stamp 的工作原理。
一个写线程获取写锁的过程中，首先是通过 WriteLock 获取一个票据 stamp，WriteLock 是一个独占锁，同时只有一个线程可以获取该锁，当一个线程获取该锁后，其它请求的线程必须等待，当没有线程持有读锁或者写锁的时候才可以获取到该锁。请求该锁成功后会返回一个 stamp 票据变量，用来表示该锁的版本，当释放该锁的时候，需要 unlockWrite 并传递参数 stamp。
一个读线程获取锁的过程。首先线程会通过乐观锁 tryOptimisticRead 操作获取票据 stamp ，如果当前没有线程持有写锁，则返回一个非 0 的 stamp 版本信息。线程获取该 stamp 后，将会拷贝一份共享资源到方法栈，在这之前具体的操作都是基于方法栈的拷贝数据。
之后方法还需要调用 validate，验证之前调用 tryOptimisticRead 返回的 stamp 在当前是否有其它线程持有了写锁，如果是，那么 validate 会返回 0，升级为悲观锁；否则就可以使用该 stamp 版本的锁对数据进行操作。
相比于 RRW，StampedLock 获取读锁只是使用与或操作进行检验，不涉及 CAS 操作，即使第一次乐观锁获取失败，也会马上升级至悲观锁，这样就可以避免一直进行 CAS 操作带来的 CPU 占用性能的问题，因此 StampedLock 的效率更高。
读写锁再优化之 StampedLock
锁分离优化 Lock 同步锁
Lock
CAS 是实现乐观锁的核心算法，它包含了 3 个参数：V（需要更新的变量）、E（预期值）和 N（最新值）。
只有当需要更新的变量等于预期值时，需要更新的变量才会被设置为最新值，如果更新值和预期值不同，则说明已经有其它线程更新了需要更新的变量，此时当前线程不做操作，返回 V 的真实值。
在 JDK 中的 concurrent 包中，atomic 路径下的类都是基于 CAS 实现的。AtomicInteger 就是基于 CAS 实现的一个线程安全的整型类。
我们可以看到 AtomicInteger 的自增方法 getAndIncrement 是用了 Unsafe 的 getAndAddInt 方法，显然 AtomicInteger 依赖于本地方法 Unsafe 类，Unsafe 类中的操作方法会调用 CPU 底层指令实现原子操作。
CAS 如何实现原子操作
处理器和物理内存之间的通信速度要远慢于处理器间的处理速度，所以处理器有自己的内部缓存。如下图所示，在执行操作时，频繁使用的内存数据会缓存在处理器的 L1、L2 和 L3 高速缓存中，以加快频繁读取的速度。
处理器提供了总线锁定和缓存锁定两个机制来保证复杂内存操作的原子性。
当处理器要操作一个共享变量的时候，其在总线上会发出一个 Lock 信号，这时其它处理器就不能操作共享变量了，该处理器会独享此共享内存中的变量。但总线锁定在阻塞其它处理器获取该共享变量的操作请求时，也可能会导致大量阻塞，从而增加系统的性能开销。
后来的处理器都提供了缓存锁定机制，也就说当某个处理器对缓存中的共享变量进行了操作，就会通知其它处理器放弃存储该共享资源或者重新读取该共享资源。目前最新的处理器都支持缓存锁定机制。
处理器如何实现原子操作
虽然乐观锁在并发性能上要比悲观锁优越，但是在写大于读的操作场景下，CAS 失败的可能性会增大，如果不放弃此次 CAS 操作，就需要循环做 CAS 重试，这无疑会长时间地占用 CPU。
在 JDK1.8 中，Java 提供了一个新的原子类 LongAdder。LongAdder 在高并发场景下会比 AtomicInteger 和 AtomicLong 的性能更好，代价就是会消耗更多的内存空间。
LongAdder 的原理就是降低操作共享变量的并发数，也就是将对单一共享变量的操作压力分散到多个变量值上，将竞争的每个写线程的 value 值分散到一个数组中，不同线程会命中到数组的不同槽中，各个线程只对自己槽中的 value 值进行 CAS 操作，最后在读取值的时候会将原子操作的共享变量与各个分散在数组的 value 值相加，返回一个近似准确的数值。
LongAdder 内部由一个 base 变量和一个 cell[]数组组成。当只有一个写线程，没有竞争的情况下，LongAdder 会直接使用 base 变量作为原子操作变量，通过 CAS 操作修改变量；当有多个写线程竞争的情况下，除了占用 base 变量的一个写线程之外，其它各个线程会将修改的变量写入到自己的槽 cell[]数组中，最终结果可通过以下公式计算得出：
我们可以发现，LongAdder 在操作后的返回值只是一个近似准确的数值，但是 LongAdder 最终返回的是一个准确的数值， 所以在一些对实时性要求比较高的场景下，LongAdder 并不能取代 AtomicInteger 或 AtomicLong。
优化 CAS 乐观锁
乐观锁
锁
在并发程序中，并不是启动更多的线程就能让程序最大限度地并发执行。线程数量设置太小，会导致程序不能充分地利用系统资源；线程数量设置太大，又可能带来资源的过度竞争，导致上下文切换带来额外的系统开销。
自发性上下文切换指线程由 Java 程序调用导致切出，在多线程编程中，执行调用以下方法或关键字，常常就会引发自发性上下文切换。sleep()wait()yield()join()park()synchronizedlock
自发性上下文切换
换指线程由于调度器的原因被迫切出。常见的有：线程被分配的时间片用完，虚拟机垃圾回收导致或者执行优先级的问题导致。
在 Java 虚拟机中，对象的内存都是由虚拟机中的堆分配的，在程序运行过程中，新的对象将不断被创建，如果旧的对象使用后不进行回收，堆内存将很快被耗尽。Java 虚拟机提供了一种回收机制，对创建后不再使用的对象进行回收，从而保证堆内存的可持续性分配。而这种垃圾回收机制的使用有可能会导致 stop-the-world 事件的发生，这其实就是一种线程暂停行为。
非自发性上下文切
上下文切换问题
，可以将一些与锁无关的代码移出同步代码块，尤其是那些开销较大的操作以及可能被阻塞的操作。
1. 减少锁的持有时间
我们可以考虑将锁粒度拆分得更小一些，以此避免所有线程对一个锁资源的竞争过于激烈。
与传统锁不同的是，读写锁实现了锁分离，也就是说读写锁是由“读锁”和“写锁”两个锁实现的，其规则是可以共享读，但只有一个写。这样做的好处是，在多线程读的时候，读读是不互斥的，读写是互斥的，写写是互斥的。而传统的独占锁在没有区分读写锁的时候，读写操作一般是：读读互斥、读写互斥、写写互斥。所以在读远大于写的多线程场景中，锁分离避免了在高并发读情况下的资源竞争，从而避免了上下文切换。
锁分离
我们在使用锁来保证集合或者大对象原子性时，可以考虑将锁对象进一步分解。例如，我之前讲过的 Java1.8 之前版本的 ConcurrentHashMap 就使用了锁分段。
2. 降低锁的粒度
CAS 是一个无锁算法实现，保障了对一个共享变量读写操作的一致性。CAS 操作中有 3 个操作数，内存值 V、旧的预期值 A 和要修改的新值 B，当且仅当 A 和 V 相同时，将 V 修改为 B，否则什么都不做，CAS 算法将不会导致上下文切换。Java 的 Atomic 包就使用了 CAS 算法来更新数据，就不需要额外加锁。
在 JDK1.6 中，JVM 将 Synchronized 同步锁分为了偏向锁、轻量级锁、自旋锁以及重量级锁，优化路径也是按照以上顺序进行。JIT 编译器在动态编译同步块的时候，也会通过锁消除、锁粗化的方式来优化该同步锁。
3.非阻塞乐观锁替代竞争锁
竞争锁优化
在线程中调用 wait() 方法，将阻塞等待其它线程的通知（其它线程调用 notify() 方法或 notifyAll() 方法），在线程中调用 notify() 方法或 notifyAll() 方法，将通知其它线程从 wait() 方法处返回。
在消费者第一次申请到锁之前，发现没有商品消费，此时会执行 Object.wait() 方法，这里会导致线程挂起，进入阻塞状态，这里为一次上下文切换。
当生产者获取到锁并执行 notifyAll() 之后，会唤醒处于阻塞状态的消费者线程，此时这里又发生了一次上下文切换。
被唤醒的等待线程在继续运行时，需要再次申请相应对象的内部锁，此时等待线程可能需要和其它新来的活跃线程争用内部锁，这也可能会导致上下文切换。
如果有多个消费者线程同时被阻塞，用 notifyAll() 方法，将会唤醒所有阻塞的线程。而某些商品依然没有库存，过早地唤醒这些没有库存的商品的消费线程，可能会导致线程再次进入阻塞状态，从而引起不必要的上下文切换。
wait/notify 的使用导致了较多的上下文切换
首先，我们在多个不同消费场景中，可以使用 Object.notify() 替代 Object.notifyAll()。 因为 Object.notify() 只会唤醒指定线程，不会过早地唤醒其它未满足需求的阻塞线程，所以可以减少相应的上下文切换。
其次，在生产者执行完 Object.notify() / notifyAll() 唤醒其它线程之后，应该尽快地释放内部锁，以避免其它线程在唤醒之后长时间地持有锁处理业务操作，这样可以避免被唤醒的线程再次申请相应内部锁的时候等待锁的释放
最后，为了避免长时间等待，我们常会使用 Object.wait (long）设置等待超时时间，但线程无法区分其返回是由于等待超时还是被通知线程唤醒，从而导致线程再次尝试获取锁操作，增加了上下文切换。
这里我建议使用 Lock 锁结合 Condition 接口替代 Synchronized 内部锁中的 wait / notify，实现等待／通知。这样做不仅可以解决上述的 Object.wait(long) 无法区分的问题，还可以解决线程被过早唤醒的问题。
优化 wait/notify 的使用，减少上下文切换
wait/notify 优化
比如，用 Executors.newCachedThreadPool() 创建的线程池，该线程池会复用其内部空闲的线程来处理新提交的任务，如果没有，再创建新的线程（不受 MAX_VALUE 限制），这样的线程池如果碰到大量且耗时长的任务场景，就会创建非常多的工作线程，从而导致频繁的上下文切换。因此，这类线程池就只适合处理大量且耗时短的非阻塞任务。
合理地设置线程池大小，避免创建过多线程
协程是一种比线程更加轻量级的东西，相比于由操作系统内核来管理的进程和线程，协程则完全由程序本身所控制，也就是在用户态执行。协程避免了像线程切换那样产生的上下文切换，在性能方面得到了很大的提升。
使用协程实现非阻塞等待
JVM 垃圾回收器（serial 收集器、ParNew 收集器）在回收旧对象时，会产生内存碎片，从而需要进行内存整理，在这个过程中就需要移动存活的对象。而移动内存对象就意味着这些对象所在的内存地址会发生变化，因此在移动对象前需要暂停线程，在移动完成后需要再次唤醒该线程。因此减少 JVM 垃圾回收的频率可以有效地减少上下文切换。
减少 Java 虚拟机的垃圾回收
如何优化多线程上下文切换？
多线程调优
Hashtable 使用 Synchronized 同步锁修饰了 put、get、remove 等方法，因此在高并发场景下，读写操作都会存在大量锁竞争，给系统带来性能开销。
相比 Hashtable，ConcurrentHashMap 在保证线程安全的基础上兼具了更好的并发性能。在 JDK1.7 中，ConcurrentHashMap 就使用了分段锁 Segment 减小了锁粒度，最终优化了锁的并发操作。
到了 JDK1.8，ConcurrentHashMap 做了大量的改动，摒弃了 Segment 的概念。由于 Synchronized 锁在 Java6 之后的性能已经得到了很大的提升，所以在 JDK1.8 中，Java 重新启用了 Synchronized 同步锁，通过 Synchronized 实现 HashEntry 作为锁粒度。这种改动将数据结构变得更加简单了，操作也更加清晰流畅。
与 JDK1.7 的 put 方法一样，JDK1.8 在添加元素时，在没有哈希冲突的情况下，会使用 CAS 进行添加元素操作；如果有冲突，则通过 Synchronized 将链表锁定，再执行接下来的操作。
虽然 ConcurrentHashMap 的整体性能要优于 Hashtable，但在某些场景中，ConcurrentHashMap 依然不能代替 Hashtable。例如，在强一致的场景中 ConcurrentHashMap 就不适用，原因是 ConcurrentHashMap 中的 get、size 等方法没有用到锁，ConcurrentHashMap 是弱一致性的，因此有可能会导致某次读无法马上获取到写入的数据。
Hashtable 🆚 ConcurrentHashMap
ConcurrentHashMap在数据量比较大的时候，链表会转换为红黑树。红黑树在并发情况下，删除和插入过程中有个平衡的过程，会牵涉到大量节点，因此竞争锁资源的代价相对比较高。
而跳跃表的操作针对局部，需要锁住的节点少，因此在并发场景下的性能会更好一些。一个跳跃表由若干层链表组成，每一层都实现了一个有序链表索引，只有最底层包含了所有数据，每一层由下往上依次通过一个指针指向上层相同值的元素，每层数据依次减少，等到了最顶层就只会保留部分数据了。
跳跃表的这种结构，是利用了空间换时间的方法来提高了查询效率。程序总是从最顶层开始查询访问，通过判断元素值来缩小查询范围。我们可以通过以下几张图来了解下跳跃表的具体实现原理。
如果对数据有强一致要求，则需使用 Hashtable；在大部分场景通常都是弱一致性的情况下，使用 ConcurrentHashMap 即可；如果数据量在千万级别，且存在大量增删改操作，则可以考虑使用 ConcurrentSkipListMap。
ConcurrentHashMap 🆚 ConcurrentSkipListMap
Map
Vector 也是基于 Synchronized 同步锁实现的线程安全，Synchronized 关键字几乎修饰了所有对外暴露的方法，所以在读远大于写的操作场景中，Vector 将会发生大量锁竞争，从而给系统带来性能开销。
相比之下，CopyOnWriteArrayList 是 java.util.concurrent 包提供的方法，它实现了读操作无锁，写操作则通过操作底层数组的新副本来实现，是一种读写分离的并发策略。我们可以通过以下图示来了解下 CopyOnWriteArrayList 的具体实现原理。
List
并发容器选型
多线程
堆是 JVM 内存中最大的一块内存空间，该内存被所有线程共享，几乎所有对象和数组都被分配到了堆内存中。堆被划分为新生代和老年代，新生代又被进一步划分为 Eden 和 Survivor 区，最后 Survivor 由 From Survivor 和 To Survivor 组成。
在 Java6 版本中，永久代在非堆内存区；到了 Java7 版本，永久代的静态变量和运行时常量池被合并到了堆中；而到了 Java8，永久代被元空间取代了。 结构如下图所示：
堆（Heap）
程序计数器是一块很小的内存空间，主要用来记录各个线程执行的字节码的地址，例如，分支、循环、跳转、异常、线程恢复等都依赖于计数器。
由于 Java 是多线程语言，当执行的线程数量超过 CPU 核数时，线程之间会根据时间片轮询争夺 CPU 资源。如果一个线程的时间片用完了，或者是其它原因导致这个线程的 CPU 资源被提前抢夺，那么这个退出的线程就需要单独的一个程序计数器，来记录下一条运行的指令。
程序计数器
方法区主要是用来存放已被虚拟机加载的类相关信息，包括类信息、运行时常量池、字符串常量池。类信息又包括了类的版本、字段、方法、接口和父类等信息。
JVM 在执行某个类的时候，必须经过加载、连接、初始化，而连接又包括验证、准备、解析三个阶段。在加载类的时候，JVM 会先加载 class 文件，而在 class 文件中除了有类的版本、字段、方法和接口等描述信息外，还有一项信息是常量池 (Constant Pool Table)，用于存放编译期间生成的各种字面量和符号引用。
字面量包括字符串（String a=“b”）、基本类型的常量（final 修饰的变量），符号引用则包括类和方法的全限定名（例如 String 这个类，它的全限定名就是 Java/lang/String）、字段的名称和描述符以及方法的名称和描述符。
而当类加载到内存中后，JVM 就会将 class 文件常量池中的内容存放到运行时的常量池中；在解析阶段，JVM 会把符号引用替换为直接引用（对象的索引值）。
例如，类中的一个字符串常量在 class 文件中时，存放在 class 文件常量池中的；在 JVM 加载完类之后，JVM 会将这个字符串常量放到运行时常量池中，并在解析阶段，指定该字符串对象的索引值。运行时常量池是全局共享的，多个类共用一个运行时常量池，class 文件中常量池多个相同的字符串在运行时常量池只会存在一份。
方法区与堆空间类似，也是一个共享内存区，所以方法区是线程共享的。假如两个线程都试图访问方法区中的同一个类信息，而这个类还没有装入 JVM，那么此时就只允许一个线程去加载它，另一个线程必须等待。
在 HotSpot 虚拟机、Java7 版本中已经将永久代的静态变量和运行时常量池转移到了堆中，其余部分则存储在 JVM 的非堆内存中，而 Java8 版本已经将方法区中实现的永久代去掉了，并用元空间（class metadata）代替了之前的永久代，并且元空间的存储位置是本地内存。之前永久代的类的元数据存储在了元空间，永久代的静态变量（class static variables）以及运行时常量池（runtime constant pool）则跟 Java7 一样，转移到了堆中。
方法区
Java 虚拟机栈是线程私有的内存空间，它和 Java 线程一起创建。当创建一个线程时，会在虚拟机栈中申请一个线程栈，用来保存方法的局部变量、操作数栈、动态链接方法和返回地址等信息，并参与方法的调用和返回。每一个方法的调用都伴随着栈帧的入栈操作，方法的返回则是栈帧的出栈操作。
虚拟机栈
本地方法栈跟 Java 虚拟机栈的功能类似，Java 虚拟机栈用于管理 Java 函数的调用，而本地方法栈则用于管理本地方法的调用。但本地方法并不是用 Java 实现的，而是由 C 语言实现的。
本地方法栈
JVM 内存模型
1.JVM 向操作系统申请内存，JVM 第一步就是通过配置参数或者默认配置参数向操作系统申请内存空间，根据内存大小找到具体的内存分配表，然后把内存段的起始地址和终止地址分配给 JVM，接下来 JVM 就进行内部分配。
2.JVM 获得内存空间后，会根据配置参数分配堆、栈以及方法区的内存大小。
class 文件加载、验证、准备以及解析，其中准备阶段会为类的静态变量分配内存，初始化为系统的初始值
4. 完成上一个步骤后，将会进行最后一个初始化阶段。在这个阶段中，JVM 首先会执行构造器 方法，编译器会在.java 文件被编译成.class 文件时，收集所有类的初始化代码，包括静态变量赋值语句、静态代码块、静态方法，收集在一起成为 () 方法。
5. 执行方法。启动 main 线程，执行 main 方法，开始执行第一行代码。此时堆内存中会创建一个 student 对象，对象引用 student 就存放在栈中。
6. 此时再次创建一个 JVMCase 对象，调用 sayHello 非静态方法，sayHello 方法属于对象 JVMCase，此时 sayHello 方法入栈，并通过栈中的 student 引用调用堆中的 Student 对象；之后，调用静态方法 print，print 静态方法属于 JVMCase 类，是从静态方法中获取，之后放入到栈中，也是通过 student 引用调用堆中的 student 对象
当我们通过 Java 运行以上代码时，JVM 的整个处理过程
JVM 的内存区域中，程序计数器、虚拟机栈和本地方法栈这 3 个区域是线程私有的，随着线程的创建而创建，销毁而销毁；栈中的栈帧随着方法的进入和退出进行入栈和出栈操作，每个栈帧中分配多少内存基本是在类结构确定下来的时候就已知的，因此这三个区域的内存分配和回收都具有确定性。
那么垃圾回收的重点就是关注堆和方法区中的内存了，堆中的回收主要是对象的回收，方法区的回收主要是废弃常量和无用的类的回收。
回收发生在哪里？
那 JVM 又是怎样判断一个对象是可以被回收的呢？一般一个对象不再被引用，就代表该对象可以被回收
引用计数算法：这种算法是通过一个对象的引用计数器来判断该对象是否被引用了。每当对象被引用，引用计数器就会加 1；每当引用失效，计数器就会减 1。当对象的引用计数器的值为 0 时，就说明该对象不再被引用，可以被回收了。这里强调一点，虽然引用计数算法的实现简单，判断效率也很高，但它存在着对象之间相互循环引用的问题。
可达性分析算法：GC Roots 是该算法的基础，GC Roots 是所有对象的根对象，在 JVM 加载时，会创建一些普通对象引用正常对象。这些对象作为正常对象的起始点，在垃圾回收时，会从这些 GC Roots 开始向下搜索，当一个对象到 GC Roots 没有任何引用链相连时，就证明此对象是不可用的。目前 HotSpot 虚拟机采用的就是这种算法。
对象在什么时候可以被回收？
自动性：Java 提供了一个系统级的线程来跟踪每一块分配出去的内存空间，当 JVM 处于空闲循环时，垃圾收集器线程会自动检查每一块分配出去的内存空间，然后自动回收每一块空闲的内存块。
不可预期性：一旦一个对象没有被引用了，该对象是否立刻被回收呢？答案是不可预期的。我们很难确定一个没有被引用的对象是不是会被立刻回收掉，因为有可能当程序结束后，这个对象仍在内存中。
垃圾回收线程在 JVM 中是自动执行的，Java 程序无法强制执行。我们唯一能做的就是通过调用 System.gc 方法来\"建议\"执行垃圾收集器，但是否可执行，什么时候执行？仍然不可预期。
如何回收这些对象？
垃圾回收机制
GC算法
这里的吞吐量是指应用程序所花费的时间和系统总运行时间的比值。我们可以按照这个公式来计算 GC 的吞吐量：系统总运行时间 = 应用程序耗时 +GC 耗时。如果系统运行了 100 分钟，GC 耗时 1 分钟，则系统吞吐量为 99%。GC 的吞吐量一般不能低于 95%。
吞吐量
指垃圾收集器正在运行时，应用程序的暂停时间。对于串行回收器而言，停顿时间可能会比较长；而使用并发回收器，由于垃圾收集器和应用程序交替运行，程序的停顿时间就会变短，但其效率很可能不如独占垃圾收集器，系统的吞吐量也很可能会降低。
停顿时间
多久发生一次指垃圾回收呢？通常垃圾回收的频率越低越好，增大堆内存空间可以有效降低垃圾回收发生的频率，但同时也意味着堆积的回收对象越多，最终也会增加回收时的停顿时间。所以我们只要适当地增大堆内存空间，保证正常的垃圾回收频率即可。
垃圾回收频率
GC 性能衡量指标
需要通过 JVM 参数预先设置 GC 日志，通常有以下几种 JVM 参数设置
-XX:+PrintGC 输出GC日志-XX:+PrintGCDetails 输出GC的详细日志-XX:+PrintGCTimeStamps 输出GC的时间戳（以基准时间的形式）-XX:+PrintGCDateStamps 输出GC的时间戳（以日期的形式，如 2013-05-04T21:53:59.234+0800）-XX:+PrintHeapAtGC 在进行GC的前后打印出堆的信息-Xloggc:../logs/gc.log 日志文件的输出路径
这里使用如下参数来打印日志：-XX:+PrintGCDateStamps -XX:+PrintGCDetails -Xloggc:./gclogs
我们可以通过GCViewer工具打开日志文件，图形化界面查看整体的 GC 性能
，GCeasy是一款非常直观的 GC 日志分析工具，我们可以将日志文件压缩之后，上传到 GCeasy 官网即可看到非常清楚的 GC 日志分析结果：
查看 & 分析 GC 日志
由于新生代空间较小，Eden 区很快被填满，就会导致频繁 Minor GC，因此我们可以通过增大新生代空间来降低 Minor GC 的频率。
1. 降低 Minor GC 频率
减少创建大对象：在平常的业务场景中，我们习惯一次性从数据库中查询出一个大对象用于 web 端显示。例如，我之前碰到过一个一次性查询出 60 个字段的业务操作，这种大对象如果超过年轻代最大对象阈值，会被直接创建在老年代；即使被创建在了年轻代，由于年轻代的内存空间有限，通过 Minor GC 之后也会进入到老年代。这种大对象很容易产生较多的 Full GC。
增大堆内存空间：在堆内存不足的情况下，增大堆内存空间，且设置初始化堆内存为最大堆内存，也可以降低 Full GC 的频率。
2. 降低 Full GC 的频率
假设我们有这样一个需求，要求每次操作的响应时间必须在 500ms 以内。这个时候我们一般会选择响应速度较快的 GC 回收器，CMS（Concurrent Mark Sweep）回收器和 G1 回收器都是不错的选择。
而当我们的需求对系统吞吐量有要求时，就可以选择 Parallel Scavenge 回收器来提高系统的吞吐量。
选择合适的 GC 回收器
GC 调优策略
如何优化垃圾回收机制？
JVM
Java基础
SpringBoot
Spring
Mybatis
在微服务启动后每过5秒，会由微服务内置的 Nacos 客户端主动向 Nacos 服务器发起心跳包（HeartBeat）。心跳包会包含当前服务实例的名称、IP、端口、集群名、权重等信息。
naming 模块收到心跳包，首先根据 IP 与端口判断 Nacos 是否存在该服务实例？如果实例信息不存在，在 Nacos 中注册登记该实例。而注册的本质是将新实例对象存储在“实例 Map”集合中；
如果实例信息已存在，记录本次心跳包发送时间
设置实例状态为“健康”；
naming 模块返回心跳包时间间隔。
推送“微服务状态变更”消息；
Nacos 注册中心的心跳机制
Nacos 节点对外暴露 8848 与 7848 端口。其中 8848 端口的作用是对外暴露 API 与集群间数据同步，而 7848 端口则用于节点选举来确定集群领袖（Leader）。同时 Nacos 在集群环境下需要持久化应用配置、用户权限、历史信息等内置数据，因此需要额外部署 MySQL 数据库提供统一存储。
Nacos 集群采用 Raft 算法实现。它是一种比较简单的选举算法，用于选举出 Nacos 集群中最重要的 Leader（领导）节点。
Leader：领导者，集群中最重要的角色，用于向其他节点下达指令。
Candidate：参选者，参与竞选 Leader 的节点。
Follower：跟随者，用于接收来自 Leader 或者 Candidate 的请求并进行处理。
在 Nacos 节点启动后，还没有产生Leader时选举
集群成员总量变更时重新选举；
当 Leader 停止服务后重新选举。
产生选举的时机
Nacos 集群中 Leader 节点是如何产生的
第一步，Follower 会自动将注册心跳包转给 Leader 节点；
第二步，Leader 节点完成实质的注册登记工作；
第三步，完成注册后向其他 Follower 节点发起“同步注册日志”的指令；
第四步，所有可用的 Follower 在收到指令后进行“ack应答”，通知 Leader 消息已收到；
第五步，当 Leader 接收过半数 Follower 节点的 “ack 应答”后，返回给微服务“注册成功”的响应信息。
此外，对于其他无效的 Follower 节点，Leader 仍会不断重新发送，直到所有 Follower 的状态与 Leader 保持同步。
Nacos 节点间的数据同步过程
如何在生产环境部署 Nacos 集群
注册中心Nacos
RoundRobinRule：轮询策略，Ribbon 默认策略。默认超过 10 次获取到的 server 都不可用，会返回⼀个空的 server。
RandomRule：随机策略，如果随机到的 server 为 null 或者不可用的话。会不停地循环选取。
RetryRule：重试策略，⼀定时限内循环重试。默认继承 RoundRobinRule，也⽀持自定义注⼊，RetryRule 会在每次选取之后，对选举的 server 进⾏判断，是否为 null，是否 alive，并且在 500ms 内会不停地选取判断。而 RoundRobinRule 失效的策略是超过 10 次，RandomRule 没有失效时间的概念，只要 serverList 没都挂。
BestAvailableRule：最小连接数策略，遍历 serverList，选取出可⽤的且连接数最小的⼀个 server。
AvailabilityFilteringRule：可用过滤策略。扩展了轮询策略，会先通过默认的轮询选取⼀个 server，再去判断该 server 是否超时可用、当前连接数是否超限，都成功再返回。
ZoneAvoidanceRule：区域权衡策略。扩展了轮询策略，除了过滤超时和链接数过多的 server，还会过滤掉不符合要求的 zone 区域⾥⾯的所有节点，始终保证在⼀个区域/机房内的服务实例进行轮询。
如何配置 Ribbon 负载均衡策略
负载均衡Ribbon
服务通信 Fegin
Spring Cloud Gateway 启动时基于 Netty Server 监听指定的端口（该端口可以通过 server.port 属性自定义）。当前端应用发送一个请求到网关时，进入 Gateway Handler Mapping 处理过程，网关会根据当前 Gateway 所配置的谓词（Predicate）来决定是由哪个微服务进行处理。
确定微服务后，请求向后进入 Gateway Web Handler 处理过程，该过程中 Gateway 根据过滤器（Filters）配置，将请求按前后顺序依次交给 Filter 过滤链进行前置（Pre）处理，前置处理通常是对请求进行前置检查，例如：判断是否包含某个指定请求头、检查请求的 IP 来源是否合法、请求包含的参数是否正确等。
当过滤链前置（Pre）处理完毕后，请求会被 Gateway 转发到真正的微服务实例进行处理，微服务处理后会返回响应数据，这些响应数据会按原路径返回被 Gateway 配置的过滤链进行后置处理（Post），后置处理通常是对响应进行额外处理，例如：将处理过程写入日志、为响应附加额外的响应头或者流量监控等。
在整个处理过程中谓词（Predicate）与过滤器（Filter）起到了重要作用，谓词决定了路径的匹配规则，让 Gateway 确定应用哪个微服务，而 Filter 则是对请求或响应作出实质的前置、后置处理。
Spring Cloud Gateway 的执行流程
API网关 SpringCloud gateway
在 Nacos 中支持配置热加载，在运行过程中允许直接对新的配置项进行重新加载而不需要手动重启。首先咱们了解下热加载背后的处理机制。Nacos 采用的是 Pull 拉取模式，但并不是简单的 Pull，而是一种长轮训机制。客户端采用长轮训的方式定时发起 Pull 请求，去检查服务端配置信息是否发生了变更，如果发生了变更，则客户端会根据变更的数据获得最新的配置。所谓的长轮训，是客户端发起轮训请求之后，服务端如果有配置发生变更，就直接返回。如果客户端发起 Pull 请求后，发现服务端的配置和客户端的配置是保持一致的，那么服务端会先“Hold”住这个请求，也就是服务端拿到这个连接之后在指定的时间段内一直不返回结果，直到这段时间内配置发生变化，服务端会把原来“Hold”住的请求进行返回，如图所示：
Nacos 服务端收到请求之后，先检查配置是否发生了变更，如果没有，则设置一个定时任务，延期 29.5s 执行，并且把当前的客户端长轮询连接加入 allSubs 队列。这时候有两种方式触发该连接结果的返回：
第一种是在等待 29.5s 后触发自动检查机制，这时候不管配置有没有发生变化，都会把结果返回客户端。而 29.5s 就是这个长连接保持的时间
第二种是在 29.5s 内任意一个时刻，通过 Nacos Dashboard 或者 API 的方式对配置进行了修改，这会触发一个事件机制，监听到该事件的任务会遍历 allSubs 队列，找到发生变更的配置项对应的 ClientLongPolling 任务，将变更的数据通过该任务中的连接进行返回，就完成了一次“推送”操作。
配置热加载技术
配置中心Nacos
Sentinel Core为了能够持续接收到来自 Dashboard的数据，会在微服务实例设备上监听 8719 端口，在心跳包上报时也是上报这个 8719 端口，而非微服务本身的 80 端口。
在 Sentinel Dashboard 接收到心跳包后，来自 Sentinel Core的AppName、IP、端口信息会被封装为 MachineInfo 对象放入 ConcurrentHashMap 保存在 JVM的内存中，以备后续使用。
Sentinel Core 与 Sentinel Dashboard 建立连接；
如果在 Dashboard 页面中设置了新的保护规则，会先从当前的 MachineInfo 中提取符合要求的微服务实例信息，之后通过 Dashboard内置的 transport 模块将新规则打包推送到微服务实例的 Sentinel Core，Sentinel Core收 到新规则在微服务应用中对本地规则进行更新，这些新规则会保存在微服务实例的 JVM 内存中
Sentinel Dashboard 向 Sentinel Core 下发新的保护规则；
Sentinel Core 为服务限流、熔断提供了核心拦截器 SentinelWebInterceptor，这个拦截器默认对所有请求 /** 进行拦截，然后开始请求的链式处理流程，在对于每一个处理请求的节点被称为 Slot（槽），通过多个槽的连接形成处理链，在请求的流转过程中，如果有任何一个 Slot 验证未通过，都会产生 BlockException，请求处理链便会中断，并返回“Blocked by sentinel\" 异常信息。
Sentinel Core 应用新的保护规则，实施限流、熔断等动作。
Sentinel 的执行流程
滑动窗口算法的理念是将整段时间均分后独立计数再汇总统计，滑动窗口算法被广泛应用在各种流控场景中
Sentinel 采用滑动窗口算法来统计访问量
下图清晰的说明了 Sentinel的熔断过程：设置熔断的触发条件，当某接口超过20%的请求访问出现故障，便启动熔断；在熔断状态下，若干秒内所有该接口的请求访问都会直接抛出BlockException拒绝访问。熔断器过后，下一次请求重新访问接口，当前接口为“半开状态”，后续处理以下分两种情况。当前请求被有效处理，接口恢复到正常状态。当前请求访问出现故障，接口继续熔断。
Sentinel的熔断过程
系统保护Sentinel
多 Master 模式是配置最简单的模式，同时也是使用最多的形式。优点是单个 Master 宕机或重启维护对应用无影响，在磁盘配置为 RAID10 时，即使机器宕机不可恢复情况下，由于 RAID10 磁盘非常可靠，同步刷盘消息也不会丢失，性能也是最高的；缺点是单台机器宕机期间，这台机器上未被消费的消息在机器恢复之前不可订阅，消息实时性会受到影响。
多 Master 多 Slave 异步复制模式。每个 Master 配置一个 Slave，有多对 Master-Slave，HA 采用异步复制方式，主备有短暂消息毫秒级延迟，即使磁盘损坏只会丢失少量消息，且消息实时性不会受影响。同时 Master 宕机后，消费者仍然可以从 Slave 消费，而且此过程对应用透明，不需要人工干预，性能同多 Master 模式几乎一样；缺点是 Master 宕机，磁盘损坏情况下会丢失少量消息。
多 Master 多 Slave 同步双写模式，HA 采用同步双写方式，即只有主备都写成功，才向应用返回成功，该模式数据与服务都无单点故障，Master 宕机情况下，消息无延迟，服务可用性与数据可用性都非常高；缺点是性能比异步复制模式低 10% 左右，发送单个消息的执行时间会略高，且目前版本在主节点宕机后，备机不能自动切换为主机。
部署 RocketMQ 集群
在双 Master 架构中，出现了一个新角色 NameServer（命名服务器），NameServer 是 RocketMQ 自带的轻量级路由注册中心，支持 Broker 的动态注册与发现。在 Broker 启动后会自动向 NameServer 发送心跳包，通知 Broker 上线。当 Provider 向 NameServer 获取路由信息，然后向指定 Broker 建立长连接完成数据发送。
为了避免单节点瓶颈，通常 NameServer 会部署两台以上作为高可用冗余。NameServer 本身是无状态的，各实例间不进行通信，因此在 Broker 集群配置时要配置所有 NameServer 节点以保证状态同步。
日志管理SLS
双Master集群
消息队列RocketMQ
分布式事务Seata
定时任务SchedulerX
分布式存储OSS
SpringCloud Alibaba
框架
mysqldump 全量备份
Binlog 增量备份
高可用HA
一条 SQL 在数据库中执行，首先 SQL 经过语法解析成 AST，然后 AST 转换为逻辑执行计划，逻辑执行计划经过优化后，转换为物理执行计划，再经过物理执行计划优化后，按照优化后的物理执行计划执行完成数据的查询。几乎所有的数据库，都是由执行器和存储引擎两部分组成，执行器负责执行计算，存储引擎负责保存数据。
为什么主键不能太长，因为表的每个索引保存的都是主键的值，过长的主键会导致每一个索引都很大。再比如，我们了解了执行计划的优化过程后，就很容易理解，有的时候明明有索引却不能命中的原因是，数据库在对物理执行计划优化的时候，评估发现不走索引，直接全表扫描是更优的选择。
SQL在数据库中怎么执行的？
事务范围内全程写锁，不加读锁，读取都不需要施加读锁，因此，无法防止读的数据是否是别的事务正在写（加了写锁）但未提交的（属于脏数据），因为不加读锁导致根本不会被其它事务的写锁阻塞，出现脏读
读未提交
事务范围内全程写锁，读锁不全程，只要读完就释放，因此，如果读了数据，其它事务又来修改是防不住的，会出现两次读取值不一样，不可重复读问题
读已提交
事务范围内全程写锁、读锁，但没有施加范围锁，因此，一个范围内如果新增了数据，是无法锁定的，会出现幻读，之前发现有5条，被插入了新的符合条件的一条，变成6条了，跟幻觉一样
可重复读
事务范围内全程写锁、读锁、范围锁
可串行化
事务隔离级别
InnoDB 存储引擎默认使用表的主键作为主键索引，该主键索引就是聚簇索引（Clustered Index），如果表没有定义主键，InnoDB 就自己产生一个隐藏的 6 个字节的主键 ID 值作为主键索引，而创建的主键索引默认使用的是 B+Tree 索引。
InnoDB 的索引原理
ALL（全表扫描）
index（全索引扫描）
range（索引范围扫描）
ref（非唯一索引扫描）
eq_ref（唯一索引扫描）
const（结果只有一条的主键或唯一索引扫描）
explain type 字段
MySQL 执行计划
索引中进行了表达式计算，索引会失效
索引使用了函数，会失效
Like进行模糊查询时，Like后面不能是%
使用联合索引时，注意最左原则
索引失效的情况
在一些大字符串的字段作为索引时，使用前缀索引可以帮助我们减小索引项的大小。
前缀索引优化
覆盖索引是指 SQL 中 query 的所有字段，在索引 B+tree 的叶子节点上都能找得到的那些索引，从辅助索引中查询得到记录，而不需要通过聚簇索引查询获得。
覆盖索引优化
按照最左优先的方式进行索引的匹配
联合索引
建立高效索引的技巧
索引
通过数据库行锁 select for update 锁住这行数据
可能产生死锁问题
悲观锁
基于版本号的方式，首先在数据库增加一个 int 型字段 ver，然后在 SELECT 同时获取 ver 值，最后在 UPDATE 的时候检查 ver 值是否为与第 2 步或得到的版本值相同。
如果更新结果的记录数为1，就表示成功，如果更新结果的记录数为 0，就表示已经被其他应用更新过了，需要做异常处理。
分布式锁
主要采用主表里的 1 个或多个字段组合的方式作为区分标识。其中，这个字段可以是时间维度，也可以是状态维度的
如何判断一个数据到底是冷数据还是热数据？
修改写操作的业务代码：建议在业务代码比较简单，并且不按照时间区分冷热数据时使用
监听数据库变更日志：建议在业务代码比较复杂，不敢随意变更，并且不按照时间区分冷热数据时使用
定时扫描数据库：建议在按照时间区分冷热数据时使用。
如何触发冷热数据分离？
找到符合条件的历史订单中最大的那个订单 ID，然后在删除语句中把删除的条件转换成按主键分批删除。
这样每次删除的时候，由于条件变成了主键比较，我们知道在 MySQL 的 InnoDB 存储引擎中，表数据结构就是按照主键组织的一颗 B+ 树，而 B+ 树本身就是有序的，所以不仅查找非常快，也不需要再进行额外的排序操作了。
为什么在删除语句中非得加一个排序呢？因为按 ID 排序后，我们每批删除的记录，基本都是 ID 连续的一批记录，由于 B+ 树的有序性，这些 ID 相近的记录，在磁盘的物理文件上，大致也是放在一起的，这样删除效率会比较高，也便于 MySQL 回收页。
大量的历史订单数据删除完成之后，如果你检查一下 MySQL 占用的磁盘空间，你会发现它占用的磁盘空间并没有变小，这是什么原因呢？这也是和 InnoDB 的物理存储结构有关系。虽然逻辑上每个表是一颗 B+ 树，但是物理上，每条记录都是存放在磁盘文件中的，这些记录通过一些位置指针来组织成一颗 B+ 树。当 MySQL 删除一条记录的时候，只能是找到记录所在的文件中位置，然后把文件的这块区域标记为空闲，然后再修改 B+ 树中相关的一些指针，完成删除。其实那条被删除的记录还是躺在那个文件的那个位置，所以并不会释放磁盘空间。
数据库的磁盘空间很紧张，非要把这部分磁盘空间释放出来，可以执行一次 OPTIMIZE TABLE 释放存储空间。对于 InnoDB 来说，执行 OPTIMIZE TABLE 实际上就是把这个表重建一遍，执行过程中会一直锁表，也就是说这个时候下单都会被卡住，这个是需要注意的。另外，这么优化有个前提条件，MySQL 的配置必须是每个表独立一个表空间（innodb_file_per_table = ON），如果所有表都是放在一起的，执行 OPTIMIZE TABLE 也不会释放磁盘空间。
重建表的过程中，索引也会重建，这样表数据和索引数据都会更紧凑，不仅占用磁盘空间更小，查询效率也会有提升。那对于频繁插入删除大量数据的这种表，如果能接受锁表，定期执行 OPTIMIZE TABLE 是非常有必要的。
-- 新建一个临时订单表create table orders_temp like orders;
-- 删除旧表drop table orders_to_be_dropp
我们的系统可以接受暂时停服，最快的方法是这样的：直接新建一个临时订单表，然后把当前订单复制到临时订单表中，再把旧的订单表改名，最后把临时订单表的表名改成正式订单表。这样，相当于我们手工把订单表重建了一次，但是，不需要漫长的删除历史订单的过程了。
如何批量删除大量数据？
冷热分离
写入 Binlog：主库写 binlog 日志，提交事务，并更新本地存储数据。
同步 Binlog：把 binlog 复制（log dump 线程）到所有从库上，每个从库把 binlog 写到暂存日志（relay log）中。
回放 Binlog：从库还会创建一个 SQL 线程读取 relay log 中的内容，回放 binlog，并更新存储数据。
主从复制原理
同步复制：事务线程要等待所有从库的复制成功响应。
异步复制：事务线程完全不等待从库的复制成功响应。
参数“rpl_semi_sync_master_wait_slave_count”，含义是：“至少等待数据复制到几个从节点再返回”。这个数量配置的越大，丢数据的风险越小，但是集群的性能和可用性就越差。最大可以配置成和从节点的数量一样，这样就变成了同步复制。一般情况下，配成默认值 1 也就够了，这样性能损失最小，可用性也很高，只要还有一个从库活着，就不影响主库读写。
另外一个重要的参数是“rpl_semi_sync_master_wait_point”，这个参数控制主库执行事务的线程，是在提交事务之前（AFTER_SYNC）等待复制，还是在提交事务之后（AFTER_COMMIT）等待复制。默认是 AFTER_SYNC，也就是先等待复制，再提交事务，这样完全不会丢数据。AFTER_COMMIT 具有更好的性能，不会长时间锁表，但还是存在宕机丢数据的风险。
主库提交事务的线程等待复制的时间超时了，这种情况下事务仍然会被正常提交。并且，MySQL 会自动降级为异步复制模式，直到有足够多（rpl_semi_sync_master_wait_no_slave）的从库追上主库，才能恢复成半同步复制。如果这个期间主库宕机，仍然存在丢数据的风险。
半同步复制：MySQL 5.7 版本之后增加的一种复制方式，介于两者之间，事务线程不用等待所有的从库复制成功响应，只要一部分复制成功响应回来就行，比如一主二从的集群，只要数据成功复制到任意一个从库上，主库的事务线程就可以返回给客户端。
目的是通过日志复制和回放的方式来实现集群中所有节点内的状态一致性。
Redis Cluster 中，它的全量备份称为 Snapshot，操作日志叫 backlog
Elasticsearch 用的是 translog，它备份和恢复数据的原理和实现方式也是完全一样
复制状态机
主从复制模式
使用缓存解决
数据的冗余
直接查询主库
解决主从复制延迟
读写分离
单库的性能无法满足要求
分库
因为数据量比较大，导致事务执行缓慢
扩展性很差，节点数量变动，就需要重新计算 Hash，就会导致大规模数据迁移的工作
取模
它是指将存储节点和数据都映射到一个首尾相连的哈希环上。存储节点一般可以根据 IP 地址进行 Hash 计算，数据的存储位置是从数据映射在环上的位置开始，依照顺时针方向所找到的第一个存储节点。
优点是数据可以较为均匀地分配到各节点，其并发写入性能表现也不错
缓存节点在圆环上分布不平均，会造成部分缓存节点的压力较大；当某个节点故障时，这个节点所要承担的所有访问都会被顺移到另一个节点上，会对后面这个节点造成压力。
一致性Hash
解决了一致性Hash中移除上一个节点导致下一个节点负载过高的问题
它将一个缓存节点计算多个 Hash 值分散到圆环的不同位置，这样既实现了数据的平均，而且当某一个节点故障或者退出的时候，它原先承担的 Key 将以更加平均的方式分配到其他节点上，从而避免雪崩的发生。
仍然存在单一热点问题
基于虚拟节点的一致性Hash
Hash分片
保证分片元数据服务的可用性和数据一致性？
专门给元数据做一个服务集群，并通过一致性算法复制数据
给分片元数据做集群服务，并通过 ETCD 存储数据分片信息。
每个数据存储实例节点定时向元数据服务集群同步心跳和分片信息。
当调用端的请求过来时，元数据服务节点只需要做好高可用和缓存即可。
是将元数据服务的高可用和数据一致性问题转嫁给外围协调组件，如 ETCD 集群
ETCD 选择了 Raft 算法
Raft 是 Multi Paxos 的一种实现，是通过一切以领导者为准的方式，实现一系列值的共识，然而不是所有节点都能当选 Leader 领导者，Raft 算法对于 Leader 领导者的选举是有限制的，只有最全的日志节点才可以当选。正因为 ETCD 选择了 Raft，为工业界提供了可靠的工程参考，就有更多的工程实现选择基于 Raft，如 TiDB 就是基于 Raft 算法的优化。
ETCD 的共识算法是什么
基于分片元数据
范围（Range）分片
分表
Proxy 模式
Client 模式
程序端改造
引入了分库分表键，我们之后所有的查询都需要带上这个字段，才能找到数据所在的库和表，否则就只能向所有的数据库和数据表发送查询命令
另外一个问题是一些数据库的特性在实现时可能变得很困难，比如说多表的 JOIN 在单库时是可以通过一个 SQL 语句完成的，但是拆分到多个数据库之后就无法跨库执行 SQL 了，不过好在我们对于 JOIN 的需求不高，即使有也一般是把两个表的数据取出后在业务代码里面做筛选，复杂是有一些，不过是可以实现的。再比如说在未分库分表之前查询数据总数时只需要在 SQL 中执行 count() 即可，现在数据被分散到多个库表中，我们可能要考虑其他的方案，比方说将计数的数据单独存储在一张表中或者记录在 Redis 里面。
解决分库分表引入的问题
Snowflake 的核心思想是将 64bit 的二进制数字分成若干部分，每一部分都存储有特定含义的数据，比如说时间戳、机器 ID、序列号等等，最终生成全局唯一的有序 ID。它的标准算法是这样的：
有一些缺点，其中最大的缺点就是它依赖于系统的时间戳，一旦系统时间不准，就有可能生成重复的 ID。所以如果我们发现系统时钟不准，就可以让发号器暂时拒绝发号，直到时钟准确为止。
另外，如果请求发号器的 QPS 不高，比如说发号器每毫秒只发一个 ID，就会造成生成 ID 的末位永远是 1，那么在分库分表时如果使用 ID 作为分区键就会造成库表分配的不均匀。这一点，也是我在实际项目中踩过的坑，而解决办法主要有两个：
1. 时间戳不记录毫秒而是记录秒，这样在一个时间区间里可以多发出几个号，避免出现分库分表时数据分配不均。2. 生成的序列号的起始号可以做一下随机，这一秒是 21，下一秒是 30，这样就会尽量地均衡了。
Snowflake 算法
发号器（分布式ID）
分库分表
Binlog 实时同步数据
上线同步程序，从旧库中复制数据到新库中，并实时保持同步；
DAO 层需要做如下改造：支持双写新旧两个库，并且预留热切换开关，能通过开关控制三种写状态：只写旧库、只写新库和同步双写。支持读新旧两个库，同样预留热切换开关，控制读旧库还是新库。
上线双写订单服务，只读写旧库
这个双写的业务逻辑，一定是先写旧库，再写新库，并且以写旧库的结果为准。
旧库写成功，新库写失败，返回写成功，但这个时候要记录日志，后续我们会用到这个日志来验证新库是否还有问题。旧库写失败，直接返回失败，就不写新库了。这么做的原因是，不能让新库影响到现有业务的可用性和数据准确性。上面这个过程如果出现问题，可以关闭双写，回滚到只读写旧库的状态。
切换到双写之后，新库与旧库的数据可能会存在不一致的情况，原因有两个：一是停止同步程序和开启双写，这两个过程很难做到无缝衔接，二是双写的策略也不保证新旧库强一致，这时候我们需要上线一个对比和补偿的程序，这个程序对比旧库最近的数据变更，然后检查新库中的数据是否一致，如果不一致，还要进行补偿。
开启双写，同时停止同步程序
开启双写后，还需要至少稳定运行至少几周的时间，并且期间我们要不断地检查，确保不能有旧库写成功，新库写失败的情况出现。对比程序也没有发现新旧两个库的数据有不一致的情况，这个时候，我们就可以认为，新旧两个库的数据是一直保持同步的。
开启对比和补偿程序，确保新旧数据库数据完全一样；
接下来就可以用类似灰度发布的方式，把读请求一点儿一点儿地切到新库上。同样，期间如果出问题的话，可以再切回旧库。全部读请求都切换到新库上之后，这个时候其实读写请求就已经都切换到新库上了，实际的切换已经完成了，但还有后续的收尾步骤。
逐步切量读请求到新库上；
再稳定一段时间之后，就可以停掉对比程序，把订单服务的写状态改为只写新库。到这里，旧库就可以下线了。注意，整个迁移过程中，只有这个步骤是不可逆的。但是，这步的主要操作就是摘掉已经不再使用的旧库，对于在用的新库并没有什么改变，实际出问题的可能性已经非常小了。
下线对比补偿程序，关闭双写，读写都切换到新库上；
如何实现不停机更换数据库？
MySQL 的 InnoDB 存储引擎来说，更新 binlog、redolog、undolog 都是在做顺序 IO，而更新 datafile 和索引文件则是在做随机 IO，而为了减少随机 IO 的发生，关系数据库已经做了很多的优化，比如说写入时先写入内存，然后批量刷新到磁盘上，但是随机 IO 还是会发生。
索引在 InnoDB 引擎中是以 B+ 树方式来组织的，而 MySQL 主键是聚簇索引（一种索引类型，数据与索引数据放在一起），既然数据和索引数据放在一起，那么在数据插入或者更新的时候，我们需要找到要插入的位置，再把数据写到特定的位置上，这就产生了随机的 IO。而且一旦发生了页分裂，就不可避免会做数据的移动，也会极大地损耗写入性能。
LSM 树（Log-Structured Merge Tree）牺牲了一定的读性能来换取写入数据的高性能，Hbase、Cassandra、LevelDB 都是用这种算法作为存储的引擎。
它的思想很简单，数据首先会写入到一个叫做 MemTable 的内存结构中，在 MemTable 中数据是按照写入的 Key 来排序的。为了防止 MemTable 里面的数据因为机器掉电或者重启而丢失，一般会通过写 Write Ahead Log 的方式将数据备份在磁盘上。
MemTable 在累积到一定规模时，它会被刷新生成一个新的文件，我们把这个文件叫做 SSTable（Sorted String Table）。当 SSTable 达到一定数量时，我们会将这些 SSTable 合并，减少文件的数量，因为 SSTable 都是有序的，所以合并的速度也很快。
当从 LSM 树里面读数据时，我们首先从 MemTable 中查找数据，如果数据没有找到，再从 SSTable 中查找数据。因为存储的数据都是有序的，所以查找的效率是很高的，只是因为数据被拆分成多个 SSTable，所以读取的效率会低于 B+ 树索引。
很多 NoSQL 数据库都在使用的基于 LSM 树的存储引擎
使用 NoSQL 提升写入性能
Mysql
Kafka 提供“无限”的消息堆积能力，具有超高的吞吐量，可以满足我们保存原始数据的大部分要求。写入点击流数据的时候，每个原始数据采集服务作为一个生产者，把数据发给 Kafka 就可以了。下游的计算任务，可以作为消费者订阅消息，也可以按照时间或者位点来读取数据。并且，Kafka 作为事实标准，和大部分大数据生态圈的开源软件都有非常好的兼容性和集成度，像 Flink、Spark 等大多计算平台都提供了直接接入 Kafka 的组件。
第一种方案是，使用 Kafka 来存储
使用 HDFS 存储数据也很简单，就是把原始数据写成一个一个文本文件，保存到 HDFS 中。我们需要按照时间和业务属性来组织目录结构和文件名，以便于下游计算程序来读取，比如说：“click/20200808/Beijing_0001.csv”，代表 2020 年 8 月 8 日，从北京地区用户收集到的点击流数据，这个是当天的第一个文件
对于保存海量的原始数据这个特定的场景来说，HDFS 的吞吐量是远不如 Kafka 的。按照平均到每个节点上计算，Kafka 的吞吐能力很容易达到每秒钟大几百兆，而 HDFS 只能达到百兆左右。这就意味着，要达到相同的吞吐能力，使用 HDFS 就要比使用 Kafka，多用几倍的服务器数量。
但 HDFS 也有它的优势，第一个优势就是，它能提供真正无限的存储容量，如果存储空间不够了，水平扩容就可以解决。另外一个优势是，HDFS 能提供比 Kafka 更强的数据查询能力。Kafka 只能按照时间或者位点来提取数据，而 HDFS 配合 Hive 直接就可以支持用 SQL 对数据进行查询，虽然说查询的性能比较差，但查询能力要比 Kafka 强大太多了。
第二种方案是，使用 HDFS 来存储
点击流数据如何存储？
如果你的系统的数据量在 GB 量级以下，MySQL 仍然是可以考虑的，因为它的查询能力足以应付大部分分析系统的业务需求。并且可以和在线业务系统合用一个数据库，不用做 ETL（数据抽取），省事儿并且实时性好。这里还是要提醒你，最好给分析系统配置单独的 MySQL 实例，避免影响线上业务。
如果数据量级已经超过 MySQL 极限，可以选择一些列式数据库，比如：HBase、Cassandra、ClickHouse，这些产品对海量数据，都有非常好的查询性能，在正确使用的前提下，10GB 量级的数据查询基本上可以做到秒级返回。高性能的代价是功能上的缩水，这些数据库对数据的组织方式都有一些限制，查询方式上也没有 MySQL 那么灵活。大多都需要你非常了解这些产品的脾气秉性，按照预定的姿势使用，才能达到预期的性能。
另外一个值得考虑的选择是 Elasticsearch（ES），ES 本来是一个为了搜索而生的存储产品，但是也支持结构化数据的存储和查询。由于它的数据都存储在内存中，并且也支持类似于 Map-Reduce 方式的分布式并行查询，所以对海量结构化数据的查询性能也非常好。
数据量级超过 TB 级的时候，对这么大量级的数据做统计分析，无论使用什么存储系统，都快不到哪儿去。这个时候的性能瓶颈已经是磁盘 IO 和网络带宽了。这种情况下，实时的查询和分析肯定做不了。解决的办法都是，定期把数据聚合和计算好，然后把结果保存起来，在需要时对结果再进行二次查询。这么大量级的数据，一般都选择保存在 HDFS 中，配合 Map-Reduce、Spark、Hive 等等这些大数据生态圈产品做数据聚合和计算。
海量数据怎么查询的更快？
海量数据场景
如果当前连接数小于最小连接数，则创建新的连接处理数据库请求；
如果连接池中有空闲连接则复用空闲连接；
如果空闲池中没有连接并且当前连接数小于最大连接数，则创建新的连接处理请求；
如果当前连接数已经大于等于最大连接数，则按照配置中设定的时间（C3P0 的连接池配置是 checkoutTimeout）等待旧的连接可用；
如果等待超过了这个设定时间则向用户抛出错误。
数据库连接池参数
1. 启动一个线程来定期检测连接池中的连接是否可用，比如使用连接发送“select 1”的命令给数据库看是否会抛出异常，如果抛出异常则将这个连接从连接池中移除，并且尝试关闭。目前 C3P0 连接池可以采用这种方式来检测连接是否可用，也是我比较推荐的方式。
2. 在获取到连接之后，先校验连接是否可用，如果可用才会执行 SQL 语句。比如 DBCP 连接池的 testOnBorrow 配置项，就是控制是否开启这个验证。这种方式在获取连接时会引入多余的开销，在线上系统中还是尽量不要开启，在测试服务上可以使用。
连接探活机制
数据库连接池
数据库
ElasticSearch
存储
调用方持续把请求参数对象序列化成二进制数据，经过 TCP 传输到服务提供方；
服务提供方从 TCP 通道里面接收到二进制数据；
根据 RPC 协议，服务提供方将二进制数据分割出不同的请求数据，经过反序列化将二进制数据逆向还原出请求对象，找到对应的实现类，完成真正的方法调用；
然后服务提供方再把执行结果序列化后，回写到对应的 TCP 通道里面；
调用方获取到应答的数据包后，再反序列化成应答对象。
一次完整的 RPC 流程
JSON：用且应用最广泛， 在通信时需要更多的内存
Hessian： 一种紧凑的二进制序列化框架，在性能和体积上表现比较好
Protobuf： 序列化后体积相比 JSON、Hessian 还要小，兼容性也做得不错。
RPC序列化方式
每当客户端发送一个连接请求给服务端，服务端都会启动一个新的线程去处理客户端连接的读写操作，即每个 Socket 都对应一个独立的线程，客户端 Socket 和服务端工作线程的数量是 1 比 1，这会导致服务器的资源不够用，无法实现高并发下的网络开发。
Socket 连接数量受限，不适用于高并发场景；
有两处阻塞，分别是等待用户发起连接，和等待用户发送数据。
同步阻塞 I/O（BIO）
同步非阻塞 I/O
Linux 系统中的 select、poll、epoll等系统调用都是 I/O 多路复用的机制。
Reactor 的 3 种线程模型，分别是单线程 Reactor 线程模型、多线程 Reactor 线程模型，以及主从 Reactor 线程模型。
I/O 多路复用（NIO）
以及异步 I/O（AIO）
RPC网络通信性能
这里面有一些经验值的推荐。比如将 tcp_nodelay 设置为 true，也有一些参数需要在运行中来调试，比如接受缓冲区和发送缓冲区的大小，客户端连接请求缓冲队列的大小（back log）等等；
调试网络参数
RPC
Nacos
注册中心
配置中心
服务中有一个本地缓存，我们把收集的所有日志数据先存放在这个缓存中，然后后台线程通过异步的方式将缓存中的日志发送给 SkyWalking 服务端。通过这种机制，在日志埋点的地方，我们无须等待服务端接收受数据，也就不影响系统性能。
SkyWalking 的数据收集机制
如果服务端宕机了，理论上日志缓存中的数据会出现没人消费的情况，这样会不会导致数据越积越多，最终撑爆内存呢？在 SkyWalking 中，我们会设置缓存的 size，如果这部分数据超出了缓存 size，Trace 不会保存，我们也就知道内存会不会撑爆了。
如果 SkyWalking 服务端宕机了，会出现什么情况？
SkyWalking 会在每个服务器上配置采样比例，比如设置为 100，代表 1% 的请求数据会被收集，如下代码所示。
一旦启用 forceSampleErrorSegment ，出现错误时所有的数据全部会收集，此时 sampleRate 对出错的请求不再适用。
所有相关联服务的 sampleRate 最好保持一致，如果 A 调用 B，然后 A、B 的采样率不一样，就会出现一个 Trace 串不起来的情况。
流量较大时，如何控制日志的数据量？
SkyWalking 进行配置定时清理
日志的保存时间
SkyWalking 的收集服务（Receiver）和聚合服务（Aggregator），它们支持集群模式。同时呢，在集群服务里，多个服务节点又需要一些协调服务来协调服务间的关系，它们支持 Kubernetes-ZooKeeper、Consul、Etcd、Nacos（开源的协调服务基本支持）
集群配置：如何确保高可用？
SkyWalking
全链路监控
Hystrix 的做法是每个依赖接口（也可以配置成几个接口共用）维护一个线程池，然后通过线程池的大小、排队数等隔离每个服务对依赖接口的调用
线程隔离机制
Hystrix 机制中，我们会配置一个不断滚动的统计时间窗口 metrics.rollingStats.timeInMilliseconds，在每个统计时间窗口中，当调用接口的总数量达到 circuitBreakerRequestVolumeThreshold，且接口调用超时或异常的调用次数与总调用次数的占比超过 circuitBreakerErrorThresholdPercentage，此时就会触发熔断。
在哪种条件下会触发熔断？
如果熔断被触发了，在 circuitBreakerSleepWindowInMilliseconds 的时间内，我们便不再对外调用接口，而是直接调用本地的一个降级方法
熔断了会怎么样？
circuitBreakerSleepWindowInMilliseconds 到时间后，Hystrix 首先会放开对接口的限制（断路器状态 HALF-OPEN），然后尝试使用 1 个请求去调用接口，如果调用成功，则恢复正常（断路器状态 CLOSED），如果调用失败或出现超时等待，就需要再重新等待circuitBreakerSleepWindowInMilliseconds 的时间，之后再重试。
熔断后怎么恢复？
熔断机制
当调用失败的次数累积到一定的阈值时，熔断状态从关闭态切换到打开态。一般在实现时，如果调用成功一次，就会重置调用失败次数。
当熔断处于打开状态时，我们会启动一个超时计时器，当计时器超时后，状态切换到半打开态。你也可以通过设置一个定时器，定期地探测服务是否恢复。
在熔断处于半打开状态时，请求可以达到后端服务，如果累计一定的成功次数后，状态切换到关闭态；如果出现调用失败的情况，则切换到打开态。
三种状态之间切换的过程
滚动（滑动）时间窗口
Hystrix
开关降级指的是在代码中预先埋设一些“开关”，用来控制服务调用的返回值。
针对读取数据的场景，我们一般采用的策略是直接返回降级数据。比如，如果数据库的压力比较大，我们在降级的时候，可以考虑只读取缓存的数据，而不再读取数据库中的数据；如果非核心接口出现问题，可以直接返回服务繁忙或者返回固定的降级数据。
对于一些轮询查询数据的场景，比如每隔 30 秒轮询获取未读数，可以降低获取数据的频率（将获取频率下降到 10 分钟一次）。
而对于写数据的场景，一般会考虑把同步写转换成异步写，这样可以牺牲一些数据一致性保证系统的可用性。
只有经过演练的开关才是有用的开关
降级
熔断
协调者询问事务的所有参与者是否准备好提交，如果已经准备好提交回复 Prepared，否则回复 Non-Prepared。
准备阶段
协调者如果在准备阶段收到所有事务参与者回复的 Prepared 消息，就会首先在本地持久化事务状态为 Commit，然后向所有参与者发送 Commit 指令，所有参与者立即执行提交操作；否则，任意一个参与者回复了 Non-Prepared 消息，或任意一个参与者超时未回复，协调者都会将自己的事务状态持久化为“Abort”之后，向所有参与者发送 Abort 指令，参与者立即执行回滚操作。
执行阶段
参与者等待协调者指令时无法做超时处理。一旦协调者宕机，所有参与者都会受到影响。如果协调者一直没有恢复，没有正常发送 Commit 或者 Rollback 的指令，那所有参与者都必须一直等待。
单点问题
两段提交过程中，所有参与者相当于被绑定成为一个统一调度的整体，期间要经过两次远程服务调用、三次数据持久化（准备阶段写重做日志，协调者做状态持久化，提交阶段在日志写入 Commit Record），整个过程将持续到参与者集群中最慢的那一个处理操作结束为止。这就决定了两段式提交的性能通常都比较差。
性能问题
如果协调者在发出准备指令后，根据各个参与者发回的信息确定事务状态是可以提交的，协调者就会先持久化事务状态，并提交自己的事务。如果这时候网络忽然断开了，无法再通过网络向所有参与者发出 Commit 指令的话，就会导致部分数据（协调者的）已提交，但部分数据（参与者的）既未提交也没办法回滚，导致数据不一致。
一致性风险
2PC
三段式提交把原本的两段式提交的准备阶段再细分为两个阶段，分别称为 CanCommit、PreCommit，把提交阶段改为 DoCommit 阶段。其中，新增的 CanCommit 是一个询问阶段，协调者让每个参与的数据库根据自身状态，评估该事务是否有可能顺利完成。
将准备阶段一分为二的理由是，这个阶段是重负载的操作，一旦协调者发出开始准备的消息，每个参与者都将马上开始写重做日志，这时候涉及的数据资源都会被锁住。如果此时某一个参与者无法完成提交，相当于所有的参与者都做了一轮无用功
所以，增加一轮询问阶段，如果都得到了正面的响应，那事务能够成功提交的把握就比较大了，也意味着因某个参与者提交时发生崩溃而导致全部回滚的风险相对变小了。
因此，在事务需要回滚的场景中，三段式的性能通常要比两段式好很多，但在事务能够正常提交的场景中，两段式和三段式提交的性能都很差，三段式因为多了一次询问，性能还要更差一些。
同样地，也是因为询问阶段使得事务失败回滚的概率变小了，所以在三段式提交中，如果协调者在 PreCommit 阶段开始之后发生了宕机，参与者没有能等到 DoCommit 的消息的话，默认的操作策略将是提交事务而不是回滚事务或者持续等待。你看，这就相当于避免了协调者的单点问题。
缺点： 三段式提交对单点问题和回滚时的性能问题有所改善，但是对一致性风险问题并未有任何改进，甚至是增加了面临的一致性风险。为什么这么说呢？我们看一个例子。比如，进入 PreCommit 阶段之后，协调者发出的指令不是 Ack 而是 Abort，而此时因为网络问题，有部分参与者直至超时都没能收到协调者的 Abort 指令的话，这些参与者将会错误地提交事务，这就产生了不同参与者之间数据不一致的问题。
3PC
Try： 尝试执行阶段，完成所有业务可执行性的检查（保障一致性），并且预留好事务需要用到的所有业务资源（保障隔离性）。
Confirm：确认执行阶段，不进行任何业务检查，直接使用 Try 阶段准备的资源来完成业务处理。注意，Confirm 阶段可能会重复执行，因此需要满足幂等性。
Cancel：取消执行阶段，释放 Try 阶段预留的业务资源。注意，Cancel 阶段也可能会重复执行，因此也需要满足幂等性。
TCC 其实有点类似于 2PC 的准备阶段和提交阶段，但 TCC 是位于用户代码层面，而不是在基础设施层面，这就为它的实现带来了较高的灵活性，我们可以根据需要设计资源锁定的粒度。
缺点： TCC 最主要的限制是它的业务侵入性很强，但并不是指由此给开发编码带来的工作量，而是指它所要求的技术可控性上的约束。
TCC
每一个子事务都对应一个补偿动作，C1，C2，…，Ci，…，Cn
Saga 模式适用于业务流程长，业务流程多且需要保证事务最终一致性的业务系统。
优点：一阶段提交本地数据库事务，无锁，高性能；补偿服务易于理解，易于实现。
缺点：Sage无法保证隔离性，需要额外加锁保证。
Seata
要采取编程的方式手动发送应答
MQ 自动应答机制导致的消息丢失
定时任务扫描的方式，将未完成的消息重新投递来进行消息补偿。这是基于消息队列实现分布式事务的关键，是一种双向消息确认的机制。
高并发场景下的消息积压导致消息丢失
基于 MQ 的可靠消息投递方案
分布式事务
无法限制短时间之内的集中流量。假如我们需要限制每秒钟只能处理 10 次请求，如果前一秒钟产生了 10 次请求，这 10 次请求全部集中在最后的 10 毫秒中，而下一秒钟的前 10 毫秒也产生了 10 次请求，那么在这 20 毫秒中就产生了 20 次请求，超过了限流的阈值。但是因为这 20 次请求分布在两个时间窗口内，所以没有触发限流，这就造成了限流的策略并没有生效。
固定时间窗口计数算法
这个算法的原理是将时间的窗口划分为多个小窗口，每个小窗口中都有单独的请求计数。
虽然滑动窗口算法解决了窗口边界的大流量的问题，但是它和固定窗口算法一样，还是无法限制短时间之内的集中流量，也就是说无法控制流量让它们更加平滑。
滑动时间窗口计数算法
任意请求进来后直接进入漏桶排队；
以特定的速率处理漏桶队列里面的请求；
超出漏桶负载范围的新请求直接抛弃掉，无法进入排队队列。
比如服务器空闲时，理论上服务器可以直接处理一次洪峰，但是漏桶的机制是请求处理速率恒定，因此，前期服务器资源只能根据恒定的漏水速率逐步处理请求，无法用于其他限流场景。令牌桶算法可以解决这个问题。
漏斗算法
按照特定的速率产生 tokens 并存放在令牌桶中，如果令牌桶满了，新的令牌不再产生；
新进来的请求如果需要处理，则消耗桶中的一个令牌；
如果桶中有令牌，直接消耗一个；
如果桶中没有令牌，进入一个队伍中等待新的令牌；
如果等待令牌的队伍满了，新请求就会直接被抛弃掉。
假设令牌在秒杀前已经产生，那么秒杀开始时请求数已经是 100 了，前 100 个请求就会被放行，也就是说机器人又抢到了所有商品。
漏桶算法在面对突发流量的时候，采用的解决方式是缓存在漏桶中， 这样流量的响应时间就会增长，这就与互联网业务低延迟的要求不符；而令牌桶算法可以在令牌中暂存一定量的令牌，能够应对一定的突发流量，所以一般我会使用令牌桶算法来实现限流方案，而 Guava 中的限流方案就是使用令牌桶算法来实现的。
令牌桶算法
算法
基于令牌桶算法的实现库。
permitsPerSecond：每秒允许的请求数。
warmupPeriod：令牌桶多久满。
tryAcquire 的超时时间：当令牌桶为空时，可以等待新的令牌多久
3个配置项
单机算法 Guava
Sentinel
分布式算法
限流技术
限流
基于数据库分布式锁
Elastic-job
xxl-job
分布式定时任务
微服务
Java后端技能总结
0 条评论
下一页
