L1nker4's Blog | 格木观云

SIGMOD '17 Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Databases

Sun, 01 Mar 2026 16:43:37 +0800

1. Introduction

传统的关系数据库架构在云环境中遇到了根本性的性能瓶颈：

网络I/O成为约束：在云基础设施中，计算、内存、存储都已经可以弹性扩展，但数据库实例与存储之间的网络带宽成为了性能瓶颈
RDS MySQL镜像方案：简单地将单机MySQL搬到云上，将本地磁盘替换为EBS，但写放大问题被直接映射到网络上，导致性能急剧下降
分布式复制协议：如Raft、Paxos等通用协议，开销大，对数据库语义理解不足
写放大问题：传统MySQL架构一次逻辑写操作涉及5次物理磁盘写：
- Redo log写入
- Binlog写入
- 数据Page写入（可能触发）
- Double-write buffer写入
- FRM文件写入

针对上述问题，Aurora论文中提出了一个架构理念：

“Log is the Database”

将数据库视为redo log流，存储层变成"日志处理服务"，网络上只传输redo log，其他所有工作（Page写入、检查点等）都下推到存储层异步完成。

2. 架构设计

2.1. 设计亮点：The Log is the Database

传统MySQL镜像架构的存在五倍的写放大的情况，Aurora针对此情况做了如下改进：

只通过网络传输redo log，其他所有写入都在存储层本地完成
存储节点接收并持久化redo log，并异步将日志转换成数据Page，同时维护checkpoint和snapshot，并通过gossip协议检查并修复数据不一致的情况

数据流：


DB Engine → Redo Log → Storage Service → Async Page Generation

			(网络传输)    (分布式存储)         (后台异步)

2.2. 架构概览

2.2.1. Primary Node

Primary写入节点核心职责：

唯一写入节点：接受所有客户端的写请求（INSERT/UPDATE/DELETE）
日志生成器：生成MySQL兼容的redo log，分配单调递增的LSN
日志分发器：将redo log同时发送到两个目的地：
- 存储层的6个Storage Node：用于持久化和Page生成
- 所有Secondary Node：用于实时同步
事务协调器：管理事务提交，等待VDL推进后确认事务完成
查询处理器：处理所有SQL查询（包括读和写）

特点：

OpenManus架构设计分析

Wed, 11 Feb 2026 18:31:56 +0800

1. Intro

OpenManus 是一个基于大语言模型的 AI Agent Framework。它实现了一套完整的 Agent 系统，能够接收用户的自然语言指令，通过"思考-行动-观察"循环（ReAct 模式）自主调用各种工具来完成复杂任务。

核心能力包括：

通过 LLM 理解用户意图并规划执行步骤
调用多种工具（Python 执行、Shell 命令、浏览器操作、网页搜索、文件编辑等）
支持单 Agent 直接执行和多 Agent 协同的 Planning 流程
支持 MCP（Model Context Protocol）协议，可动态连接外部工具服务
支持 Docker 沙箱隔离执行

2. 架构简述

OpenManus 采用分层模块化架构：

┌──────────────────────────────────────────────────────────┐
│                     入口层 (main.py 等)                   │
└──────────────────────────┬───────────────────────────────┘
                           │
         ┌─────────────────┼─────────────────┐
         ▼                 ▼                 ▼
   ┌───────────┐    ┌───────────┐    ┌───────────┐
   │   Agent   │    │   Flow    │    │  Config   │
   │  代理模块  │    │  流程编排  │    │  配置管理  │
   └─────┬─────┘    └─────┬─────┘    └───────────┘
         │                │
         ▼                ▼
   ┌───────────┐    ┌───────────┐
   │   Tool    │    │  Prompt   │
   │  工具模块  │    │  提示词    │
   └─────┬─────┘    └───────────┘
         │
   ┌─────┴─────┐
   │    LLM    │        ┌──────────┐
   │  模型封装  │        │  Schema  │
   └───────────┘        │  数据模型 │
                        └──────────┘

各个模块职责如下：

Semantic Caching（语意缓存）：AI应用降本增效利器

Sun, 01 Feb 2026 15:41:39 +0800

1. Intro

传统缓存的核心逻辑是精确字符串匹配：将查询作为 key完全一致时命中缓存。这种机制在静态内容分发、API 响应缓存等场景下运作良好，但在AI应用领域的表现较差，相似意图的Query无法精准命中。语义缓存（Semantic Caching）是一种利用Embedding向量化和向量相似度搜索来实现基于语义相似进行缓存匹配的机制。

语义缓存的工作流程可以概括为四个阶段：


用户查询 → [1. Embedding 向量化] → [2. 向量相似度搜索] → Hit? → [3. 返回缓存结果]

                                    ↓ Miss

                                [4. 调用 LLM → 缓存结果]

Embedding 向量化：将用户的自然语言查询通过 Embedding 模型映射为高维向量。这一向量编码了查询的语义信息，使得含义相近的文本在向量空间中彼此接近。
向量相似度搜索 ：将新查询的向量与向量数据库中已存储的缓存向量进行比较，使用余弦距离（Cosine Distance）等度量方式计算语义距离，找出最近邻。
缓存命中判定 ：若最近邻的距离小于预设阈值（如 0.15），则判定为缓存命中，直接返回对应的 LLM 响应。
缓存未命中处理 若无满足阈值条件的缓存结果，则将查询发送至 LLM 获取响应，并将该查询的 Embedding 向量与 LLM 响应一起写入缓存，供后续请求复用。

语义缓存在客服聊天机器人、企业内部知识库等场景中能够发挥显著价值，此类场景大量Query集中在少数高频问题中，使用语意缓存可以显著降低AI应用的token成本。

2. 基于RedisVL实现语义缓存

2.1. RedisVL介绍

RedisVL（Redis Vector Library） 是 Redis 官方提供的 Python 客户端库，专为 AI 应用场景设计。它在 Redis 核心的高性能数据存储能力之上，封装了向量索引管理、多种 Embedding 模型集成、向量相似度搜索等功能，使开发者无需直接操作底层的 RediSearch 命令即可构建向量检索应用。在语义缓存领域，RedisVL 提供了 SemanticCache 类作为核心抽象，将索引创建、Embedding 向量化、KNN 搜索、阈值判定、TTL 管理等操作封装为简洁的 check() / store() API。同时，RedisVL 内置了对 OpenAI、HuggingFace、Cohere 等主流 Embedding Model的适配，并支持 Tag 和 Numeric 过滤实现多租户缓存隔离。

EuroSys '15 Large-scale cluster management at Google with Borg

Wed, 22 Oct 2025 12:30:12 +0800

1. Intro

Borg 是支持Google大规模数据中心计算的集群管理系统，其设计理念和工程实现对后来的 Kubernetes、Omega 等系统产生了深远影响。Borg 通过在共享集群上高效调度和管理成千上万的任务，实现了资源的高利用率、任务的高可靠性以及灵活的多租户隔离。论文介绍了 Borg 的整体架构、调度机制、容错设计和运维经验，揭示了支撑谷歌内部服务（如搜索、Gmail、YouTube）运行的关键技术。作为早期的超大规模集群管理系统，Brog提供了以下三个优势：

隐藏底层资源管理和故障处理细节，使用户专注于应用开发。
提供高可靠的集群管理系统
支持上万台机器高效运行

Borg 的创新在于将分布式资源抽象为可调度的统一资源池，并结合任务优先级、抢占机制、作业声明式配置等理念，为现代云计算和容器编排系统奠定了基础。

2. 架构设计

2.1. 架构简述

Brog系统由以下组件构成，与Kubernetes架构几乎一致：

Cluster/Cell：一组机器集群，由大量worker节点（Borglet进程）和BorgMaster组成
BorgMaster：Cell控制器，负责处理来自用户的所有请求，管理Cell中所有Borglet的状态，以及调度和启动任务。由集群组成，使用Paxos协议确保副本的数据一致性。
Borglet：运行在每个worker节点上，运行BrogMaster分配的任务，负责监控本地任务的状态和资源使用情况，并定期上报给BrogMaster。
Scheduler：当新Job被提交到BrogMaster后，Scheduler负责扫描待处理任务，并按照任务优先级，在Cell中寻找合适的Borglet来运行，找到Borglet后通知BorgMaster下发Job，通常Scheduler集成在BrogMaster中。

2.2. Job / Task

用户以Job的形式提交给Borg，Job由一个或多个Task组成，每个Task对应着一组Linux进程，每个Job只运行在同一个Cell中。

Cell主要运行两种Task：

应该永不停止的、长期运行的服务，处理时间较短且对网络延迟敏感的请求。
批处理作业，执行时间较长，例如MapReduce等

Borg通过任务优先级和配额，合理分配集群资源，优先级表示Cell中运行的Job相对重要性，配额用来决定允许哪个作业可以被调度，配额是指特定时间段的资源使用数量。

Borg 为每个Task创建了一个固定的 BNS 域名(Borg Name Service)，使得其他Task可以访问到该服务。

2.3. BorgMaster

BorgMaster由两个进程组成：BrogMaster主进程和scheduler进程，其中主进程负责处理client的RPC请求，并与Borglet通信，提供了Web UI，BorgMaster逻辑上是单个进程，实际上有五个replica，每个replica都在内存中维护了Cell的状态，replica基于Paxos协议组成了一个高可用的分布式系统，其中有一个Master节点，负责处理所有变更Cell状态的RPC请求。某个时刻BrogMaster会创建checkpoint，以定期快照和变更日志的形式，保存在Paxos存储中。

2.4. 调度

当client提交一个Job后，BorgMaster会把它持久化道Paxos存储上，并将这个Job中所有的Task都加入到等待队列中，Scheduler会异步扫描等待队列，将Task分配到合适的机器上。Borg调度算法有两个步骤：

可行性检查：找到可以运行Task的一批机器
评分：从中选择合适的机器

Borg早期使用优化后的E-PVM算法进行评分，这个算法会把负载分散到所有的机器，但是导致了资源的碎片化，对突如其来的大型任务支持性较差。最佳匹配算法与之相反，挨个对机器资源进行分配，这样会有空闲机器来处理大型任务。

2.5. Borglet

Borglet是部署在每台机器上的proxy进程，负责启动、停止Task，并需要将本机状态上报给BorgMaster，每个BorgMaster replica会负责一个无状态的link shard来处理部分的Borglet的通信，来减少Master的更新负担。

2.6. 扩展性设计

Borg支持使用单独的BorgMaster管理有着数千台机器的Cell，Cell可能每分钟有10K的任务被提交到集群。早期BorgMaster使用简单的同步循环实现scheduler，为了处理更多的任务，Borg的scheduler被分离为单独的进程，Scheduler会重复处理流程如下：

从选举出来的BorgMaster获取状态变更数据
更新自己的本地副本状态
执行一轮调度来分配任务
将分配信息发送给Master
Master接受数据，如果分配计划不合理或者过时，会等待下一轮调度。

Borg在性能优化上的方法如下：

缓存评分信息：Borg会缓存计算得出的机器评分，用于下次调度使用，如果机器属性更新，则会触发缓存失效
任务等效类：一般来说，同一个Borg作业的任务都有相同的请求和约束，Borg只对等效类中的一个任务做可行性检查和评分，而不是遍历计算所有的任务
适度随机：Scheduler可能会随机抽取机器，直到找到足够多的可用机器并完成评分，从中挑选最合适的分配任务

2.7. 隔离

Borg使用Linux的chroot作为机器的安全隔离机制，Google的AppEngine使用VM和安全沙箱运行外部软件，每个运行在KVM进程的VM，作为一个Borg任务来运行。

OSDI '12 Spanner Google’s Globally-Distributed Database

Tue, 07 Oct 2025 16:30:12 +0800

Intro

Google Spanner是一个全球性分布式数据库，提供了关系型数据库ACID语义的同时，兼顾了分布式系统的高扩展性，在Spanner之前，Google内部主要依赖两类存储系统：

BigTable：不支持ACID的关系型大规模列式存储，无法支持强事务应用场景。
MegaStore：支持ACID语义，但事务存在跨Entity Group时吞吐量较差，难以支撑跨数据中心的分大规模事务场景。

Spanner的设计目标正是弥补上述缺陷：

全球分布和扩展性：支持跨数据中心部署，并保证线性可扩展
强一致事务：可以细粒度控制数据副本，支持跨数据中心的事务，改善MegaStore的事务限制
一致性时间语义：通过TrueTime API，实现全球范围的外部一致性（线性）

架构设计

Spanner使用Zone作为一个部署服务的最小单元，每个Zone中包含以下三个组件：

zone master：为spanserver分配数据
spanserver：为client提供数据服务
location proxy：负责分发client的请求

在Zone之外还有两个单例服务：

universe master：显示所有Zone的状态信息，用于监控调试。
placement driver：可以分钟级完成Zone间的自动化迁移，定期与spanserver通信获取需要迁移的数据，以满足数据负载均衡的需求。

spanserver

Spanserver架构层次上来看，由下到上分别为：

数据存储层（Colossus、BigTable Tablet）
数据复制和一致性（Paxos）
事务处理、并发控制、领导者选举

数据存储层

Tablet 是 Spanner 管理数据的基本单位，是一个逻辑结构，使用B-Tree和WAL进行管理，内部有timestamp，用于支持Spanner实现MVCC机制。Colossus作为底层的数据存储引擎，它是Google对GFS的优化项目，用于支撑Spanner大规模存储。所有的Tablet以文件形式存储在Colossus中。

数据复制与一致性

为了防止意外情况导致的数据丢失，Spanner支持副本机制，每个Tablet上都实现了一个Paxos状态机，写操作由Tablet leader执行，读操作可以从任意在同步中的Tablet执行。

TrueTime

Spanner为了实现全球范围的分布式事务和一致性，设计了TrueTime，来解决传统分布式系统的时钟问题：

各节点时钟可能存在偏移问题
仅靠NTP同步的时间，无法达到毫秒级一致

TrueTime能在即使物理时间存在偏差的情况下，也能保证严格的线性一致性。

TrueTime API提供了以下三个方法：

TrueTime底层使用的参考时间为GPS和原子时钟两种模式，GPS模式通过数据中心的time server和每台机器的time slave daemon线程实现，其余的master使用原子时钟。

事务管理和并发控制

Spanner 支持 分布式事务（跨多个 Paxos group），其核心机制是：

2PC：跨 Tablet 的事务使用 2PC 协调提交
时间戳分配与 TrueTime

每个leader副本中，都有一个lock table来实现并发控制，并且支持2PC，Spanner中各类读写情况对比如下：

CIDR '11 Megastore: Providing Scalable, Highly Available Storage for Interactive Services

Fri, 25 Jul 2025 14:23:12 +0800

1. Intro

《Megastore: Providing Scalable, Highly Available Storage for Interactive Services》是Google于CIDR 2011上发表的一篇重要论文，该论文介绍了 Google 内部使用的一种分布式存储系统——Megastore，它在强一致性与高可用性之间实现了权衡，构建于BigTable之上，引入了事务机制、同步复制、SQL查询接口等，它将RDB的事务机制、一致性和NoSQL高扩展性结合起来。MegaStore对数据进行分区，并对每个分区使用Paxos算法实现同步复制，在分区内支持完整的ACID语义。

2. 存储设计

2.1. 逻辑设计

MegaStore将数据划分为多个Entity Groups，每个Entity Group都独立进行Paxos数据复制，并且该Group内部支持ACID语义。

一个 Entity Group 是一组相关联的数据实体（records），这些实体共享同一个 分布式事务边界 和 Paxos日志，在这个组内支持强一致的事务操作。

例如一个Group可能同时包含两个Data Model：

<entitygroup name="UserGroup">
  <table name="User">
    <column name="user_id" key="true"/>
    <column name="name"/>
  </table>

  <table name="Settings">
    <column name="user_id" key="true"/>
    <column name="dark_mode"/>
  </table>
</entitygroup>

通过上文可知，Group越大，单个Group的Paxos日志负载越高，Group越小，跨Group事务越容易发生，性能越差，因此如何选定Entity Group的边界十分重要。论文中提到：Megastore 要求应用开发者根据访问模式来决定Entity Group边界。开发者需要遵循以下规则：

高频事务操作的数据放在一个Entity Group
跨Group的事务代价较高，尽量避免
避免将大量数据放进一个Group，可能导致Paxos日志并发性能瓶颈

2.2. 物理存储设计

MegaStore的物理存储层使用BigTable实现，每个Entity Group的数据都存储在BigTable的连续行，来提高系统吞吐量和数据命中效率。

Megastore 并不是从头开发一个全新的存储引擎，而是使用BigTable作为底层存储引擎，负责数据的持久化、分片以及数据中心内的存储和基本读写，跨数据中心的数据复制，则由MegaStore自行实现。

Megastore 通过精心设计 row key规则，将一个 Entity Group 内的所有记录 编码为一组具有相同前缀的 row keys，以实现数据局部性。

NSDI '12 Resilient Distributed Datasets: A Fault-Tolerant Abstraction for In-Memory Cluster Computing

Tue, 22 Jul 2025 13:43:37 +0800

1. Intro

在此之前的分布式计算框架，例如 MapReduce，缺乏对分布式内存的复用能力。在 MapReduce 中，每一轮 Map 和 Reduce 任务之间的中间结果都会被写入磁盘，随后再从磁盘中读取用于下一阶段的计算。这种设计带来了大量的磁盘 I/O、数据复制和对象序列化/反序列化的开销，从而在许多迭代式或交互式的大数据应用中成为性能瓶颈，占据了绝大部分的执行时间。

为了解决上述问题，Spark 引入了弹性分布式数据集（Resilient Distributed Dataset，RDD）的抽象。RDD 是一个只读的分布式对象集合，可以并行操作，支持在内存中缓存中间计算结果，从而显著减少了 I/O 和序列化成本。RDD 提供了丰富的转换操作符（如 map、filter、reduceByKey、collect 等），使得开发人员能够以函数式编程方式，在大规模集群上构建高效、容错的内存计算任务。与此同时，RDD 通过血缘（lineage）信息来实现容错机制，即使节点失败也能基于操作链自动恢复数据，无需数据复制带来的额外存储成本。

2. RDD模型设计

RDD是一个只读，可分区、支持并行计算的数据集，可以通过操作符将RDD转换成新的RDD，并且两个RDD之间存在血缘关联。

RDD的弹性体现在：

存储：内存不足时可以和磁盘进行数据交换
计算：计算出错时支持重试
容错：数据丢失可以自动恢复
分区：支持重新分区

下面是一个从HDFS读取文本文件，并执行计算的案例：

lines = spark.textFile("hdfs://...")  
errors = lines.filter(_.startsWith("ERROR"))  
errors.persist()
// Count errors mentioning MySQL:  
errors.filter(_.contains("MySQL")).count()  
// Return the time fields of errors mentioning  
// HDFS as an array (assuming time is field  
// number 3 in a tab-separated format):  
errors.filter(_.contains("HDFS"))  
      .map(_.split(’\t’)(3))  
      .collect()

下图是上述案例中RDD血缘关系图，不同的RDD之间通过转换操作符进行连接。

OSDI '06 Bigtable A Distributed Storage System for Structured Data

Mon, 07 Jul 2025 14:23:12 +0800

1. Intro

Bigtable: A Distributed Storage System for Structured Data是Google发布于ODDI 2006的一篇论文，介绍了当时Google内部大规模使用的结构化分布式存储系统BigTable的设计与实现。BigTable 被广泛应用于 Google 内部多个核心产品中，如 Google Analytics、Google Earth等产品。

与传统RDB产品相比，BigTable参考了很多实现方案，但它不支持完整的关系数据模型，而是通过一个稀疏的多维映射结构，在性能、可扩展性和容错性之间取得了良好平衡。设计中的BigTable支持扩展到PB级数据量和上千数据节点，实现了高性能、高可用性等设计目标。BigTable 构建于 Google 自身的基础设施之上，使用GFS完成数据存储，使用 Chubby 锁完成分布式协调。本文将围绕论文中数据模型、架构设计、容错机制等方面进行分析。

2. 数据模型设计

A Bigtable is a sparse, distributed, persistent multidimensional sorted map.

BigTable是一个稀疏、分布式、持久化存储的多维Map结构，主要体现在：

Sparse：于关系模型约束严格的RDB相比，BigTable每一行数据的Column组成可能不同，行与行之间可以是不同的列。
Distributed：Map会被切分成多个分区，在多个机器上分布存储。
Persistent：Map中所有记录都会被持久化存储。

数据结构特点：

数据通过row key、column key和一个timestamp进行索引
表中每个数据项都是字节数组
映射关系为：$(row:string, column:string, time:int64) → string$

以下图为例：

row key：逆序URL，方便按照主机名排序，加速查询
contents：列：存储HTML页面信息，存在三个版本，对应时间戳为t3、t5、t6
anchor:：这是一个column family（列族）

BigTable不支持完整的关系型数据模型：

提供客户端的是一个简单数据模型
支持动态控制数据格式，允许client推测数据在底层存储中的locality特性
数据使用行名和列名进行索引

2.1. Row

Row是BigTable的基本数据单位，可以类比RDB中的Row，每个Row通过唯一的Row Key来标识，实际上按照Row Key字典序进行存储，BigTable动态分区规则也是根据Row Key进行切分，每个分区被称为Tablet，这是基本物理存储单元。

OSDI '04 MapReduce Simplified Data Processing on Large Clusters

Wed, 02 Jul 2025 15:43:37 +0800

1. Intro

《MapReduce: Simplified Data Processing on Large Clusters》是Google发布于 OSDI 2004的一篇分布式计算领域论文，奠定了大规模数据处理的基础架构范式，是大数据领域的里程碑式工作。该论文系统性地提出了一种简洁的编程模型，使开发者可以方便地在大规模分布式系统中进行并行计算，而无需关注底层的容错、调度、数据分片等复杂问题。通过将任务划分为 Map 和 Reduce 两个阶段，系统自动完成任务调度、节点容错与数据传输，大幅提升了开发效率与系统可扩展性。

2. 编程模型设计

计算任务大都可以被抽象为map和reduce操作，首先对输入数据中每条逻辑记录应用map操作以计算出一系列的中间键值对，然后对所有键相同的值应用reduce操作以合理地整合这些派生数据。

MapReduce执行过程可以简单理解为：

利用一个输入的key/value pair集合来产生一个输出的key/value pair集合。
自定义的Map函数接受一个key/value pair输入，然后产生一个中间key/value pair集合。会将相同key和对应多个value值集合在一起传递给reduce函数。
自定义的Reduce函数接受上面的集合，合并这些value值，形成一个新的value值集合。

Map Reduce函数可以抽象成以下形式：

map(k1, v1) -> list(k2, v2)
reduce(k2, list(v2)) -> list(v2)

2.1. 以wordcount为例

考虑一个业务场景：需要统计大批量文件中每个单词的出现次数，开发者编写的伪代码如下：

map(String key, String value):
  // key: document name
  // value: document contents
  for each word w in value:
    EmitIntermediate(w, "1");

reduce(String key, Iterator values):
  // key: a word
  // values: a list of counts
  int result = 0;
  for each v in values:
    result += ParseInt(v);
  Emit(AsString(result));

通过两阶段任务，将原始计算需求拆分为：先计算每个单词出现的次数，再通过reduce阶段合并计算每个单词出现次数总和。

SOSP '03 The Google File System

Thu, 26 Jun 2025 11:43:37 +0800

1. Intro

《The Google File System》（GFS）是Google于2003年在ACM SOSP（Symposium on Operating Systems Principles）上发表的一篇论文。它首次系统性地介绍了Google内部为应对大规模数据处理而设计的分布式文件系统架构。

在21世纪初，随着互联网的爆发式发展，Google需要存储并处理海量的网页、图片等数据，传统File System无论在性能、容错性、可靠性等方面都无法满足需求，因此Google设计了GFS以解决大规模文件存储和管理的需求。

2. 设计概览

2.1. 设计目标

GFS的主要设计目标包括：

性能
可用性
可伸缩性

需要满足的需求：

系统由大量廉价的存储介质构成，需要考虑监控、容错、快速回复能力
需要解决大量文件存储和管理。
读取场景：大规模的顺序读，小规模的随机读
写入场景：大规模的顺序写，极少数的小规模随机写
并发支持：支持多Client并发写入同一个文件的场景

2.2. 集群概览

GFS集群从架构上看，节点分成两个类型：

Master：整个集群的Master节点，负责以下职责：
- 维护所有Chunk Server节点的metadata
- 回收废弃chunk
- Chunk Server之间chunk迁移
- 与Chunk Server进行HeartBeat
Chunk Server：文件会被切分成chunk存储到节点中，每个chunk存在三个备份。

存储文件时，GFS会将文件切分成若干个固定大小的Chunk块并存储，Master会为每个Chunk块分配一个唯一Hash key（论文中成为handle），并将它们交由Chunk Server存储，Chunk Server以普通文件的形式将每个Chunk存储在本地磁盘上，并存储多Replica以保证数据可靠性。

Client从GFS读取文件的步骤划分为：

Client在本地通过文件名和byte offset转换为chunk index
Client向Master发送携带filename和chunk index的请求，以获取chunk的唯一标识chunk handle和chunk replica所在的Chunk Server地址
Client向最近的Chunk Server请求chunk数据

2.3. Chunk Size

Chunk Size是分布式文件存储系统中一个重要的性能指标，在参数选择上需要取舍以下因素：

因素	Chunk 越大	Chunk 越小
元数据压力	减少	增加
随机访问延迟	增加（加载较大 chunk耗时）	降低
顺序访问吞吐	更高	更低
负载均衡灵活性	降低（数据倾斜）	更好
容错恢复代价	更大（单个 chunk 损坏数据多）	更小
网络带宽利用效率	更高	更低（小文件碎片化）

GFS的chunk size选取为64MB，论文中提到选取大chunk的原因如下：

Kafka设计简析

Thu, 29 May 2025 14:43:37 +0800

1. Intro

Apache Kafka是一个分布式事件存储和流处理平台，最初由LinkedIn公司开发，旨在解决其内部大规模实时数据流存储的问题。在2011年初，LinkedIn将Kafka作为开源项目发布，并于2012年10月23日，Kafka从Apache孵化器毕业，成为Apache软件基金会的顶级项目。2014年11月，几位曾在LinkedIn参与Kafka开发的工程师，包括Jay Kreps、Neha Narkhede和Jun Rao，离开LinkedIn创立了Confluent公司，专注于提供与Kafka相关的企业级支持和服务。

1.1. 设计亮点

方案	细节
磁盘存储+pagecache替代内存缓存	JVM语言操作内存成本较高，并且Kafka为重网络I/O应用，顺序读写+pagecache场景下磁盘I/O并不会成为性能瓶颈
合适的数据结构	数据存储系统通常使用Btree进行持久化存储，而message system通常为尾端I/O，使用queue可以实现O(1)
异步batch I/O	producer端积攒一批消息，使用一次网络I/O传输到broker，降低多次small I/O的次数
文件零拷贝	broker向client返回log数据时，使用mmap内存映射避免多次
消息压缩	端到端传输/存储时，会对原始消息进行压缩
broker负载均衡	topic再次物理划分partition，producer写入请求均衡打到各个partition所在broker
ISR机制	基于多副本机制，实现集群容错和高可用
broker端网络模式	使用Reactor网络模式，按职责划分为：接受请求的acceptor，实际处理逻辑的processor，提升了broker端吞吐量
exactly once语义	producer端：开启幂等性后，每条消息都会附带sequence number，broker端严格接受递增sequence number，确保不会存在重复数据。 consumer端：实现消费-处理-提交 offset 的原子性（事务实现）

1.2. 消息模型

1.2.1. Queue Model（peer to peer）

生产者将消息发送到Queue时会进行暂时存储，当消费者完成消费或者消息TTL到期，将会从队列中移除，每条消息只有一个consumer进行消费。

案例：redis queue、Amazon SQS、RabbitMQ、activeMQ等

1.2.2. Pub/Sub Model

发布/订阅（Pub/Sub）模型是一种异步消息传递模式，旨在实现应用程序组件之间的解耦。在这种模式中，消息发布者Publisher将消息发布到特定的Topic，而消息订阅者Subscriber则订阅感兴趣的主题，以接收相关消息。这种方式使得发布者和订阅者彼此独立，不直接通信，从而提高系统的灵活性和可扩展性。

案例：Kafka、AutoMQ、Pulsar等

1.3. Streaming Storage Platform选型

维度	ActiveMQ	RabbitMQ	RocketMQ	Kafka	Pulsar
单机吞吐量	较低(万级)	一般（万级）	高（十万级）	高（十万级）	高（十万级）
开发语言	Java	Erlang	Java	Java/Scala	Java
维护者	Apache	Spring	Apache（Alibaba）	Apache（Confluent）	Apache（StreamNative）
社区活跃度	低	高	高	高	高
消费模式	P2P、Pub-Sub	direct、topic、Headers、fanout	基于 Topic 和 MessageTag 的的 Pub-Sub	基于 Topic 的 Pub-Sub	基于 Topic 的 Pub-Sub，支持独占（exclusive）、共享（shared）、灾备（failover）、key 共享（key_shared）4 种模式
持久化	支持（小）	支持（小）	支持（大）	支持（大）	支持（大）
顺序消息	不支持	不支持	支持	支持	支持
集群支持	主备模式	复制模式	主备模式	Leader-Slave 每台既是 master 也是 slave，集群可扩展性强	集群模式，broker 无状态，易迁移，支持跨数据中心
存算分离	不支持	不支持	支持	支持	支持
AMQP 支持	支持	支持	支持	不完全支持	不完全支持

1.4. 相关术语介绍

Kafka Broker：服务端由被称为Broker的服务进程构成，Broker负责接受和处理客户端请求，以及对消息进行持久化。
Kafka Controller：集群metadata的管理节点
Producer：客户端节点，消息生产方。
Customer：客户端节点，消息消费方。
Customer Group：消费者组内每个消费者负责消费不同分区的数据。一个分区只能由组内一个消费者消费，不同消费组之间互不影响。
~~Zookeeper集群：负责元数据管理，集群选举。~~近期发布（2025.03）的4.0版本已经移除Zookeeper依赖，使用内置KRaft模式管理metadata。
Topic：Kafka中消息以topic为单位进行分类，生产者将消息发送到特定的topic，消费者订阅topic进行消费。
Partition：针对Topic维度按照消息key的分区，均衡分布到Kafka集群中的各个节点，对数据存储做到均匀分布。
Replica：针对Partition维度的副本数据，实现数据备份的功能。

2. Client

Kafka clients有5个核心API：

Kafka源码分析(十)- KRaft实现细节

Mon, 14 Apr 2025 10:49:53 +0800

1. Intro

上文介绍了KRaft架构的优势与基本组件，本文对Raft协议在Kafka中的实现做简单分析。

2. 核心属性

2.1. QuorumState

QuorumState用于存储KRaft节点状态，并处理状态转换，状态机图如下（引用自KIP-595）：

核心属性：

//节点id  
private final OptionalInt localId;  
  
//目录id  
private final Uuid localDirectoryId;  
private final Time time;  
private final Logger log;  
  
//用于选举信息存储，JSON格式  
private final QuorumStateStore store;  
  
//kraft状态机  
private final KRaftControlRecordStateMachine partitionState;  
  
//各个listener endpoint节点信息  
private final Endpoints localListeners;  
  
//kraft版本信息  
private final SupportedVersionRange localSupportedKRaftVersion;  
  
private final Random random;  
  
//选举超时时间  
private final int electionTimeoutMs;  
  
//fetch超时时间  
private final int fetchTimeoutMs;  
  
//日志上下文  
private final LogContext logContext;  
  
//节点状态对象  
private volatile EpochState state;

其中EpochState接口是对节点状态的抽象，不同节点类型有对应的实现对象：

Kafka源码分析(九)- KRaft架构简析

Wed, 09 Apr 2025 09:51:53 +0800

1. Intro

Kafka属于单Master多Worker结构，Zookeeper主要提供了metadata存储、分布式同步、集群Leader选举等功能。

至于为何当下Kafka抛弃Zookeeper转而选择自建Raft代替，也是一个老生常谈的问题：

Zookeeper作为单独的分布式系统，加大了Kafka集群的部署、运维成本。
Zookeeper存在性能瓶颈，无法支撑更大的集群规模，而自建KRaft支持更大数据量级的分区元数据管理。

下文会对Kafka提出的KRaft架构做简要分析。

2. Raft算法回顾

Raft算法是一种用于保证分布式集群中数据一致性算法，在Raft论文中也明确提出：正是因为Paxos算法较为复杂，并且不易于应用到工业界，所以构建了更易于理解的Raft算法来解决分布式系统中的一致性问题。

Raft集群中只有三种角色：领导者、候选者、跟随者。Raft算法中每一段任期只有一个领导者节点，每一段任期从一次选举开始，一个或多个候选者参加选举，赢得选举将在接下来的任期充当领导者。跟随者只响应其他服务器的请求。下图为三种状态的转换关系：

3. 架构简析

在KRaft架构之前，整个Kafka集群通过Zookeeper来实现元数据存储、选举等目的，通过Zookeeper来选举是通过创建临时节点来实现的，架构实现可以参考下图（confluent）：

KRaft模式中，会选取其中部分Broker作为Controller来完成metadata存储和集群管理，但某个时间段只能有一个active Controller，它负责处理整个集群中的RPC请求，其他用作热备的Controller会从active节点同步数据。

需要注意的是，在日志复制的实现上，KRaft并没有完全采用原生Raft的方式：Leader节点主动往Follower节点推送，而是让Follower主动从Leader执行Fetch。

4. KRaft 基本结构

KRaft相关提案：

KRaft概述：KIP-500 KRaft复制/quorum维护协议规范：KIP-595 日志压缩：KIP-630

KRaft具体实现位于org.apache.kafka.raft，snapshot被拆分到org.apache.kafka.snapshot中。

KafkaRaftManager：KRaft管理与入口类，封装了dir manager、register listener、handleRequest等接口，内部实现通过调用KafkaRaftClient和KafkaRaftClientDriver完成。
KafkaRaftClientDriver：Thread类，负责运行、管理KafkaRaftClient的生命周期。
KafkaRaftClient：Kafka Raft协议的具体实现，实现RaftClient接口，选举策略采用原生Raft协议，日志复制是follower主动从leader拉取（符合Kafka语义）。

KRaft提供了Listener接口，提供了commit、snapshot等事件的回调接口。

interface Listener<T> {  
    void handleCommit(BatchReader<T> reader);  
  
    void handleLoadSnapshot(SnapshotReader<T> reader);  
  
    default void handleLeaderChange(LeaderAndEpoch leader) {}  
  
    default void beginShutdown() {}  
}

RaftClient抽取的通用方法如下：

void register(Listener<T> listener);  
  
void unregister(Listener<T> listener);
 
long prepareAppend(int epoch, List<T> records);  
  
void schedulePreparedAppend();  
  
CompletableFuture<Void> shutdown(int timeoutMs);  
  
void resign(int epoch);  
  
Optional<SnapshotWriter<T>> createSnapshot(OffsetAndEpoch snapshotId, long lastContainedLogTime);

4.1. listener注册逻辑

listener采用lazy-register方式，在消费RaftMessage的前置处理中，将一个时间段内的listener进行注册。

Kafka源码分析(八)- KafkaController管理(ZK架构)

Tue, 08 Apr 2025 10:38:13 +0800

1. Intro

Controller节点作为Kafka集群的管理节点，它负责为所有partition选举leader副本，并且负责存储和管理集群metadata。本文主要对core模块kafka.controller作简要分析。

核心属性如下：

controllerContext：集群metadata对象
controllerChannelManager：Controller端channel管理器，负责向其他Broker发送请求
kafkaScheduler：定时调度器
eventManager：Controller事件管理器，负责管理事件处理线程。
replicaStateMachine：副本状态机，负责副本状态转换。
partitionStateMachine：分区状态机，负责分区状态转换。
topicDeletionManager：主题删除管理器，负责删除主题及日志。


val controllerContext = new ControllerContext 

var controllerChannelManager = new ControllerChannelManager(  
  () => controllerContext.epoch,  
  config,  
  time,  
  metrics,  
  stateChangeLogger,  
  threadNamePrefix  
)  
  
// have a separate scheduler for the controller to be able to start and stop independently of the kafka server  
// visible for testing  
private[controller] val kafkaScheduler = new KafkaScheduler(1)  
  
// visible for testing  
private[controller] val eventManager = new ControllerEventManager(config.brokerId, this, time,  
  controllerContext.stats.rateAndTimeMetrics)  
  
private val brokerRequestBatch = new ControllerBrokerRequestBatch(config, controllerChannelManager,  
  eventManager, controllerContext, stateChangeLogger)  
val replicaStateMachine: ReplicaStateMachine = new ZkReplicaStateMachine(config, stateChangeLogger, controllerContext, zkClient,  
  new ControllerBrokerRequestBatch(config, controllerChannelManager, eventManager, controllerContext, stateChangeLogger))  
val partitionStateMachine: PartitionStateMachine = new ZkPartitionStateMachine(config, stateChangeLogger, controllerContext, zkClient,  
  new ControllerBrokerRequestBatch(config, controllerChannelManager, eventManager, controllerContext, stateChangeLogger))  
private val topicDeletionManager = new TopicDeletionManager(config, controllerContext, replicaStateMachine,  
  partitionStateMachine, new ControllerDeletionClient(this, zkClient))

2. metadata管理

通过kafka.controller.ControllerContext可以看到集群的所有metadata信息，核心字段如下：

Kafka源码分析(七) - 事务设计

Sat, 05 Apr 2025 11:25:13 +0800

1. Intro

Kafka事务主要适用于以下两种场景：

multi-produce场景：Producer需要将多批次消息进行原子性提交。
consume-transform-produce场景：消费上游数据后，经过处理，生产下游数据。该场景实现可以参考kafka.examples.ExactlyOnceMessageProcessor，事务可以保证消费和生产的原子性。

consume-transform-produce场景案例：

@Override  
public void run() {  
    int retries = 0;  
    int processedRecords = 0;  
    long remainingRecords = Long.MAX_VALUE;  
  
    // it is recommended to have a relatively short txn timeout in order to clear pending offsets faster  
    int transactionTimeoutMs = 10_000;  
    // consumer must be in read_committed mode, which means it won't be able to read uncommitted data  
    boolean readCommitted = true;  
  
    try (KafkaProducer<Integer, String> producer = new Producer("processor-producer", bootstrapServers, outputTopic,  
            true, transactionalId, true, -1, transactionTimeoutMs, null).createKafkaProducer();  
         KafkaConsumer<Integer, String> consumer = new Consumer("processor-consumer", bootstrapServers, inputTopic,  
             "processor-group", Optional.of(groupInstanceId), readCommitted, -1, null).createKafkaConsumer()) {  
        // called first and once to fence zombies and abort any pending transaction  
        producer.initTransactions();  
        consumer.subscribe(singleton(inputTopic), this);  
  
        Utils.printOut("Processing new records");  
        while (!closed && remainingRecords > 0) {  
            try {  
                ConsumerRecords<Integer, String> records = consumer.poll(ofMillis(200));  
                if (!records.isEmpty()) {  
                    // begin a new transaction session  
                    producer.beginTransaction();  
  
                    for (ConsumerRecord<Integer, String> record : records) {  
                        // process the record and send downstream  
                        ProducerRecord<Integer, String> newRecord =  
                            new ProducerRecord<>(outputTopic, record.key(), record.value() + "-ok");  
                        producer.send(newRecord);  
                    }  
  
                    // checkpoint the progress by sending offsets to group coordinator broker  
                    // note that this API is only available for broker >= 2.5                    
	            producer.sendOffsetsToTransaction(getOffsetsToCommit(consumer), consumer.groupMetadata());  
  
                    // commit the transaction including offsets  
                    producer.commitTransaction();  
                    processedRecords += records.count();  
                    retries = 0;  
                }  
            } catch (AuthorizationException | UnsupportedVersionException | ProducerFencedException  
                     | FencedInstanceIdException | OutOfOrderSequenceException | SerializationException e) {  
                // we can't recover from these exceptions  
                Utils.printErr(e.getMessage());  
                shutdown();  
            } catch (OffsetOutOfRangeException | NoOffsetForPartitionException e) {  
                // invalid or no offset found without auto.reset.policy  
                Utils.printOut("Invalid or no offset found, using latest");  
                consumer.seekToEnd(emptyList());  
                consumer.commitSync();  
                retries = 0;  
            } catch (KafkaException e) {  
                // abort the transaction  
                Utils.printOut("Aborting transaction: %s", e.getMessage());  
                producer.abortTransaction();  
                retries = maybeRetry(retries, consumer);  
            }  
  
            remainingRecords = getRemainingRecords(consumer);  
            if (remainingRecords != Long.MAX_VALUE) {  
                Utils.printOut("Remaining records: %d", remainingRecords);  
            }  
        }  
    } catch (Throwable e) {  
        Utils.printErr("Unhandled exception");  
        e.printStackTrace();  
    }  
    Utils.printOut("Processed %d records", processedRecords);  
    shutdown();  
}

1.1. 客户端配置项

Producer配置项：

Kafka源码分析(六) - 网络通信模块设计

Sun, 02 Mar 2025 18:10:12 +0800

Intro

Kafka的网络通信设计如图所示（图片引用自AutoMQ）：

其中SocketServer负责处理外部连接，并将处理结果封装到Response返回。KafkaRequestHandlerPool作为I/O处理线程池，执行请求的具体逻辑。二者之间通过RequestChannel进行交互。

SocketServer

SocketServer负责处理各个Broker之间的通信channel，采用Reactor处理模型，Acceptor负责从socket接受request，Handler负责处理接收来的request，这也是Kafka中的设计亮点之一。

在实现上，分为data-plane和control-plane，防止数据类请求阻塞控制类请求：

// data-plane  
private[network] val dataPlaneAcceptors = new ConcurrentHashMap[EndPoint, DataPlaneAcceptor]()  
val dataPlaneRequestChannel = new RequestChannel(maxQueuedRequests, DataPlaneAcceptor.MetricPrefix, time, apiVersionManager.newRequestMetrics)  
// control-plane  
private[network] var controlPlaneAcceptorOpt: Option[ControlPlaneAcceptor] = None  
val controlPlaneRequestChannelOpt: Option[RequestChannel] = config.controlPlaneListenerName.map(_ =>  
  new RequestChannel(20, ControlPlaneAcceptor.MetricPrefix, time, apiVersionManager.newRequestMetrics))

private[network] val processors = new ArrayBuffer[Processor]()

从上述定义可以看出control-plane的线程数只有一个，这是因为控制类的请求数量较数据类请求少。

初始化逻辑如下：

private def createDataPlaneAcceptorAndProcessors(endpoint: EndPoint): Unit = synchronized {  
  if (stopped) {  
    throw new RuntimeException("Can't create new data plane acceptor and processors: SocketServer is stopped.")  
  }  
  val parsedConfigs = config.valuesFromThisConfigWithPrefixOverride(endpoint.listenerName.configPrefix)  
  connectionQuotas.addListener(config, endpoint.listenerName)  
  val isPrivilegedListener = controlPlaneRequestChannelOpt.isEmpty &&  
    config.interBrokerListenerName == endpoint.listenerName  
  val dataPlaneAcceptor = createDataPlaneAcceptor(endpoint, isPrivilegedListener, dataPlaneRequestChannel)  
  config.addReconfigurable(dataPlaneAcceptor)  
  dataPlaneAcceptor.configure(parsedConfigs)  
  dataPlaneAcceptors.put(endpoint, dataPlaneAcceptor)  
  info(s"Created data-plane acceptor and processors for endpoint : ${endpoint.listenerName}")  
}  
  
private def createControlPlaneAcceptorAndProcessor(endpoint: EndPoint): Unit = synchronized {  
  if (stopped) {  
    throw new RuntimeException("Can't create new control plane acceptor and processor: SocketServer is stopped.")  
  }  
  connectionQuotas.addListener(config, endpoint.listenerName)  
  val controlPlaneAcceptor = createControlPlaneAcceptor(endpoint, controlPlaneRequestChannelOpt.get)  
  controlPlaneAcceptor.addProcessors(1)  
  controlPlaneAcceptorOpt = Some(controlPlaneAcceptor)  
  info(s"Created control-plane acceptor and processor for endpoint : ${endpoint.listenerName}")  
}

Acceptor

Acceptor线程通过Selector + Channel轮询获取acceptable connection，将接收的连接信息传递给下游Processor处理，作为Runnable任务，每个endpoint指定一个acceptor。

Kafka源码分析(五) - 索引细节

Sat, 15 Feb 2025 10:30:12 +0800

Intro

LogSegment日志对象管理以下三种Index：

位移索引文件(.index)
时间戳索引文件(.timeindex)
已中止事物的索引文件(.txnindex)

private final LazyIndex<OffsetIndex> lazyOffsetIndex;  
private final LazyIndex<TimeIndex> lazyTimeIndex;  
private final TransactionIndex txnIndex;

AbstractIndex

AbstractIndex作为索引中的顶层抽象接口，封装索引结构中一些通用的属性和处理逻辑：

protected final ReentrantLock lock = new ReentrantLock();  
  
//当前文件的开始offset  
private final long baseOffset;  
  
//最大索引大小  
private final int maxIndexSize;  
  
//是否可写  
private final boolean writable;  
  
//映射索引文件  
private volatile File file;  
  
// 索引文件长度  
private volatile long length;  
  
//mmap 内存映射buffer  
private volatile MappedByteBuffer mmap;  
  
//最大索引entry数量  
private volatile int maxEntries;  
  
//索引entry数量  
private volatile int entries;

抽象方法：

/**  
 * Do a basic sanity check on this index to detect obvious problems * 
 * @throws CorruptIndexException if any problems are found  
 */
public abstract void sanityCheck();  
  
/**  
 * Remove all entries from the index which have an offset greater than or equal to the given offset. 
 * Truncating to an offset larger than the largest in the index has no effect. */
public abstract void truncateTo(long offset);  
  
/**  
 * Remove all the entries from the index. 
 * */
protected abstract void truncate();

//不同entry大小
protected abstract int entrySize();


/**  
 * To parse an entry in the index. * 
 * @param buffer the buffer of this memory mapped index.  
 * @param n the slot  
 * @return the index entry stored in the given slot.  
 */
 protected abstract IndexEntry parseEntry(ByteBuffer buffer, int n);

初始化逻辑

public AbstractIndex(File file, long baseOffset, int maxIndexSize, boolean writable) throws IOException {  
    Objects.requireNonNull(file);  
    this.file = file;  
    this.baseOffset = baseOffset;  
    this.maxIndexSize = maxIndexSize;  
    this.writable = writable;  
  
    createAndAssignMmap();  
    this.maxEntries = mmap.limit() / entrySize();  
    this.entries = mmap.position() / entrySize();  
}

createAndAssignMmap方法会初始化file和mmap对象，实际加载index文件使用mmap方式，将内核buffer映射到用户buffer，减少了内存拷贝的开销，这也是Kafka较为重要的优化点之一：

Kafka源码分析(四) - 日志读写流程

Mon, 10 Feb 2025 12:51:12 +0800

Intro

上文介绍了Kafka日志加载的基本流程，本文主要分析Kafka日志的读写流程。

日志写入的场景主要有以下几种：

生产者向Leader replica写入消息（包含事务消息）
Follow replica拉取消息并写入
消费者组写入组信息

日志写入

从KafkaApis入口类中可以看到produce的处理动作：

case ApiKeys.PRODUCE => handleProduceRequest(request, requestLocal)

这里重点关注日志的写入逻辑，handleProduceRequest()中会调用replicaManager执行append：

// call the replica manager to append messages to the replicas  
replicaManager.handleProduceAppend(  
  timeout = produceRequest.timeout.toLong,  
  requiredAcks = produceRequest.acks,  
  internalTopicsAllowed = internalTopicsAllowed,  
  transactionalId = produceRequest.transactionalId,  
  entriesPerPartition = authorizedRequestInfo,  
  responseCallback = sendResponseCallback,  
  recordValidationStatsCallback = processingStatsCallback,  
  requestLocal = requestLocal,  
  transactionSupportedOperation = transactionSupportedOperation)

appendRecords

在ReplicaManager中会调用appendRecords()将其追加到消息对应partition的leader replica中，并且等待leader将其同步到其他replica中。

/**  
 * Handles the produce request by starting any transactional verification before appending. * * @param timeout                       maximum time we will wait to append before returning  
 * @param requiredAcks                  number of replicas who must acknowledge the append before sending the response  
 * @param internalTopicsAllowed         boolean indicating whether internal topics can be appended to  
 * @param transactionalId               the transactional ID for the produce request or null if there is none.  
 * @param entriesPerPartition           the records per partition to be appended  
 * @param responseCallback              callback for sending the response  
 * @param recordValidationStatsCallback callback for updating stats on record conversions  
 * @param requestLocal                  container for the stateful instances scoped to this request -- this must correspond to the  
 *                                      thread calling this method * @param actionQueue                   the action queue to use. ReplicaManager#defaultActionQueue is used by default.  
 * @param transactionSupportedOperation determines the supported Operation based on the client's Request api version  
 * * The responseCallback is wrapped so that it is scheduled on a request handler thread. There, it should be called with * that request handler thread's thread local and not the one supplied to this method. */
 def handleProduceAppend(timeout: Long,  
                        requiredAcks: Short,  
                        internalTopicsAllowed: Boolean,  
                        transactionalId: String,  
                        entriesPerPartition: Map[TopicPartition, MemoryRecords],  
                        responseCallback: Map[TopicPartition, PartitionResponse] => Unit,  
                        recordValidationStatsCallback: Map[TopicPartition, RecordValidationStats] => Unit = _ => (),  
                        requestLocal: RequestLocal = RequestLocal.NoCaching,  
                        actionQueue: ActionQueue = this.defaultActionQueue,  
                        transactionSupportedOperation: TransactionSupportedOperation): Unit = {
	
	appendRecords( 
	  timeout = timeout,  
	  requiredAcks = requiredAcks,  
	  internalTopicsAllowed = internalTopicsAllowed,  
	  origin = AppendOrigin.CLIENT,  
	  entriesPerPartition = entriesWithoutErrorsPerPartition,  
	  responseCallback = newResponseCallback,  
	  recordValidationStatsCallback = recordValidationStatsCallback,  
	  requestLocal = newRequestLocal,  
	  actionQueue = actionQueue,  
	  verificationGuards = verificationGuards  
		)
}

传入的参数较多，重要参数的含义如下：

Kafka源码分析(三) - 日志加载流程

Tue, 04 Feb 2025 17:51:13 +0800

Kafka Log由多个LogSegment构成，每个LogSegment对应一个分区，每个LogSegment对象都会在磁盘中创建一组文件：

日志消息文件(.log)
位移索引文件(.index)
时间戳索引文件(.timeindex)
已中止十五的索引文件(.txnindex)

LogManager

LogManager作为Kafka Log管理的入口点，负责日志创建、检索、清理，所有的读写操作都会委托给对应的日志实例。

private val currentLogs = new Pool[TopicPartition, UnifiedLog]()
private val _liveLogDirs: ConcurrentLinkedQueue[File] = createAndValidateLogDirs(logDirs, initialOfflineDirs)

currentLogs字段是用于存储分区和UnifiedLog映射的map结构，Pool内部使用ConcurrentHashMap作为存储。

liveLogDirs用于存储log路径下所有有效的File对象，存储结构使用ConcurrentLinkedQueue。createAndValidateLogDirs()方法用来检查并追加有效路径到队列中。

startup启动流程

KafkaServer的startup()方法中会调用logManager的startup()方法，用来加载所有的日志。

logManager.startup(zkClient.getAllTopicsInCluster())

startup的第一个参数是topic名称集合，第二个可选参数isStray通过metadata计算当前UnifiedLog是否需要当前broker加载（kafka.log.LogManager.isStrayKraftReplica）

/**  
 *  Start the background threads to flush logs and do log cleanup */def startup(topicNames: Set[String], isStray: UnifiedLog => Boolean = _ => false): Unit = {  
  // ensure consistency between default config and overrides  
  val defaultConfig = currentDefaultConfig  
  startupWithConfigOverrides(defaultConfig, fetchTopicConfigOverrides(defaultConfig, topicNames), isStray)  
}s

fetchTopicConfigOverrides()方法用于检查topic是否存在自定义配置并覆盖。接下来看startupWithConfigOverrides()的具体实现。

调用loadLogs()加载所有log
启动以下定时调度任务：
1. 日志清理任务
2. 日志刷盘任务
3. 日志checkpoint更新任务
4. log start offset属性checkpoint更新任务
5. 日志删除任务
检查log.cleaner.enable参数，true则配置LogCleaner

scheduler定时调度

scheduler定时调度使用内部封装的org.apache.kafka.server.util.KafkaScheduler，它是对ScheduledThreadPoolExecutor的简单封装。

private[log] def startupWithConfigOverrides(  
  defaultConfig: LogConfig,  
  topicConfigOverrides: Map[String, LogConfig],  
  isStray: UnifiedLog => Boolean): Unit = {  
    
  loadLogs(defaultConfig, topicConfigOverrides, isStray) // this could take a while if shutdown was not clean  
  
  /* Schedule the cleanup task to delete old logs */  if (scheduler != null) {  
    info("Starting log cleanup with a period of %d ms.".format(retentionCheckMs))  
    scheduler.schedule("kafka-log-retention",  
                       () => cleanupLogs(),  
                       initialTaskDelayMs,  
                       retentionCheckMs)  
    info("Starting log flusher with a default period of %d ms.".format(flushCheckMs))  
    scheduler.schedule("kafka-log-flusher",  
                       () => flushDirtyLogs(),  
                       initialTaskDelayMs,  
                       flushCheckMs)  
    scheduler.schedule("kafka-recovery-point-checkpoint",  
                       () => checkpointLogRecoveryOffsets(),  
                       initialTaskDelayMs,  
                       flushRecoveryOffsetCheckpointMs)  
    scheduler.schedule("kafka-log-start-offset-checkpoint",  
                       () => checkpointLogStartOffsets(),  
                       initialTaskDelayMs,  
                       flushStartOffsetCheckpointMs)  
    scheduler.scheduleOnce("kafka-delete-logs", // will be rescheduled after each delete logs with a dynamic period  
                       () => deleteLogs(),  
                       initialTaskDelayMs)  
  }  
  if (cleanerConfig.enableCleaner) {  
    _cleaner = new LogCleaner(cleanerConfig, liveLogDirs, currentLogs, logDirFailureChannel, time = time)  
    _cleaner.startup()  
  }  
}

loadLogs流程

loadLogs()方法作为实际加载Log数据的入口，逻辑链路较长，首先看下方法中使用到的类属性：

Kafka源码分析(二)- Consumer消费逻辑

Sat, 18 Jan 2025 15:51:13 +0800

Consumer

Consumer作为Kafka Clients中的消费者，继承关系如下图所示：

KafkaConsumer作为Facade类，提供API供clients使用，而ConsumerDelegate作为实现类接口，提供了两种实现方式，通过配置group.protocol进行控制，其中ClassicKafkaConsumer所有的线程都会处理网络IO请求，AsyncKafkaConsumer则是基于Reactor模式，使用单独线程处理网络IO，以事件驱动模式处理任务，具体细节见 Consumer threading refactor design。

本次分析也以AsyncKafkaConsumer为例。

KafkaConsumer内置的成员变量如下：

//用于创建delegate的工厂类  
private static final ConsumerDelegateCreator CREATOR = new ConsumerDelegateCreator();  
  
//consumer具体的实现类  
private final ConsumerDelegate<K, V> delegate;

初始化方法：

KafkaConsumer(ConsumerConfig config, Deserializer<K> keyDeserializer, Deserializer<V> valueDeserializer) {  
    delegate = CREATOR.create(config, keyDeserializer, valueDeserializer);  
}

public <K, V> ConsumerDelegate<K, V> create(ConsumerConfig config,  
                                            Deserializer<K> keyDeserializer,  
                                            Deserializer<V> valueDeserializer) {  
    try {  
        //根据配置选取对应的实现类
        GroupProtocol groupProtocol = GroupProtocol.valueOf(config.getString(ConsumerConfig.GROUP_PROTOCOL_CONFIG).toUpperCase(Locale.ROOT));  
  
        if (groupProtocol == GroupProtocol.CONSUMER)  
            return new AsyncKafkaConsumer<>(config, keyDeserializer, valueDeserializer);  
        else  
            return new ClassicKafkaConsumer<>(config, keyDeserializer, valueDeserializer);  
    } catch (KafkaException e) {  
        throw e;  
    } catch (Throwable t) {  
        throw new KafkaException("Failed to construct Kafka consumer", t);  
    }  
}

事件处理逻辑

AsyncKafkaConsumer的核心使用事件驱动模式来处理各类事件，具体事件类型见org.apache.kafka.clients.consumer.internals.events.ApplicationEvent

Kafka源码分析(一)- Producer生产逻辑

Sun, 05 Jan 2025 21:47:13 +0800

前言

clients模块是Kafka官方提供的默认Java客户端，该模块分为三部分：

Admin：提供了管理topic、partition、config的相关API
Consumer：提供了消费topic的API
Producer：提供了向topic投递消息的功能

源码以Kafka 3.9为例。

Producer

Producer作为Kafka client中的消息生产者，提供send()方法用于写入消息，并有后台sender线程定时发送消息。

send流程

核心send方法提供了以下两种异步方式：

/**  
 * See {@link KafkaProducer#send(ProducerRecord)}  
 */Future<RecordMetadata> send(ProducerRecord<K, V> record);  
  
/**  支持回调方法
 * See {@link KafkaProducer#send(ProducerRecord, Callback)}  
 */Future<RecordMetadata> send(ProducerRecord<K, V> record, Callback callback);

interceptor机制

send流程中首先会检查用户是否自定义interceptor实现，用于处理send前置逻辑，具体业务场景不多赘述。

@Override  
public Future<RecordMetadata> send(ProducerRecord<K, V> record, Callback callback) {  
    // 拦截器前置send动作  
    ProducerRecord<K, V> interceptedRecord = this.interceptors.onSend(record);  
    return doSend(interceptedRecord, callback);  
}

其中ProducerInterceptor提供了以下接口：

ProducerRecord<K, V> onSend(ProducerRecord<K, V> record)：send前置处理逻辑
onAcknowledgement(RecordMetadata metadata, Exception exception)：消息被应答之后或发送消息失败时调用。
close()：用于关闭interceptor资源。

自定义interceptor需要考虑线程安全。

doSend流程

private Future<RecordMetadata> doSend(ProducerRecord<K, V> record, Callback callback) {  
    // 1.1 创建callback对象  
    AppendCallbacks appendCallbacks = new AppendCallbacks(callback, this.interceptors, record);  
  
    try {  
        //1.2 检查producer是否被close  
        throwIfProducerClosed();  
        // first make sure the metadata for the topic is available  
        long nowMs = time.milliseconds();  
        ClusterAndWaitTime clusterAndWaitTime;  
  
        //1.3 拉取指定topic、分区的元数据，和等待时间  
        try {  
            clusterAndWaitTime = waitOnMetadata(record.topic(), record.partition(), nowMs, maxBlockTimeMs);  
        } catch (KafkaException e) {  
            if (metadata.isClosed())  
                throw new KafkaException("Producer closed while send in progress", e);  
            throw e;  
        }  
        nowMs += clusterAndWaitTime.waitedOnMetadataMs;  
        long remainingWaitMs = Math.max(0, maxBlockTimeMs - clusterAndWaitTime.waitedOnMetadataMs);  
        Cluster cluster = clusterAndWaitTime.cluster;  
  
        //1.4 key value进行序列化  
        byte[] serializedKey;  
        try {  
            serializedKey = keySerializer.serialize(record.topic(), record.headers(), record.key());  
        } catch (ClassCastException cce) {  
            throw new SerializationException("Can't convert key of class " + record.key().getClass().getName() +  
                    " to class " + producerConfig.getClass(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG).getName() +  
                    " specified in key.serializer", cce);  
        }  
        byte[] serializedValue;  
        try {  
            serializedValue = valueSerializer.serialize(record.topic(), record.headers(), record.value());  
        } catch (ClassCastException cce) {  
            throw new SerializationException("Can't convert value of class " + record.value().getClass().getName() +  
                    " to class " + producerConfig.getClass(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG).getName() +  
                    " specified in value.serializer", cce);  
        }  
  
        // 1.5 计算当前消息所属的partition  
        int partition = partition(record, serializedKey, serializedValue, cluster);  
  
        // 1.6 设置消息header为readOnly  
        setReadOnly(record.headers());  
        Header[] headers = record.headers().toArray();  
  
        //1.7 检查消息大小是否符合  
        int serializedSize = AbstractRecords.estimateSizeInBytesUpperBound(apiVersions.maxUsableProduceMagic(),  
                compression.type(), serializedKey, serializedValue, headers);  
        ensureValidRecordSize(serializedSize);  
        long timestamp = record.timestamp() == null ? nowMs : record.timestamp();  
  
        // 自定义partitioner  
        boolean abortOnNewBatch = partitioner != null;  
  
        // 1.8 将消息追加到accumulator中  
        RecordAccumulator.RecordAppendResult result = accumulator.append(record.topic(), partition, timestamp, serializedKey,  
                serializedValue, headers, appendCallbacks, remainingWaitMs, abortOnNewBatch, nowMs, cluster);  
        assert appendCallbacks.getPartition() != RecordMetadata.UNKNOWN_PARTITION;  
  
        // 1.9 消息入新batch的情况  
        if (result.abortForNewBatch) {  
            int prevPartition = partition;  
            onNewBatch(record.topic(), cluster, prevPartition);  
            partition = partition(record, serializedKey, serializedValue, cluster);  
            if (log.isTraceEnabled()) {  
                log.trace("Retrying append due to new batch creation for topic {} partition {}. The old partition was {}", record.topic(), partition, prevPartition);  
            }  
            result = accumulator.append(record.topic(), partition, timestamp, serializedKey,  
                serializedValue, headers, appendCallbacks, remainingWaitMs, false, nowMs, cluster);  
        }  
  
        // 2.1 开启事务的情况  
        if (transactionManager != null) {  
            transactionManager.maybeAddPartition(appendCallbacks.topicPartition());  
        }  
  
        // 2.2 如果batch满了，或者新batch被创建，唤醒后台sender线程  
        if (result.batchIsFull || result.newBatchCreated) {  
            log.trace("Waking up the sender since topic {} partition {} is either full or getting a new batch", record.topic(), appendCallbacks.getPartition());  
            this.sender.wakeup();  
        }  
        return result.future;  
        // handling exceptions and record the errors;  
        // for API exceptions return them in the future,        // for other exceptions throw directly    } catch (ApiException e) {  
        log.debug("Exception occurred during message send:", e);  
        if (callback != null) {  
            TopicPartition tp = appendCallbacks.topicPartition();  
            RecordMetadata nullMetadata = new RecordMetadata(tp, -1, -1, RecordBatch.NO_TIMESTAMP, -1, -1);  
            callback.onCompletion(nullMetadata, e);  
        }  
        this.errors.record();  
        this.interceptors.onSendError(record, appendCallbacks.topicPartition(), e);  
        if (transactionManager != null) {  
            transactionManager.maybeTransitionToErrorState(e);  
        }  
        return new FutureFailure(e);  
    } catch (InterruptedException e) {  
        this.errors.record();  
        this.interceptors.onSendError(record, appendCallbacks.topicPartition(), e);  
        throw new InterruptException(e);  
    } catch (KafkaException e) {  
        this.errors.record();  
        this.interceptors.onSendError(record, appendCallbacks.topicPartition(), e);  
        throw e;  
    } catch (Exception e) {  
        // we notify interceptor about all exceptions, since onSend is called before anything else in this method  
        this.interceptors.onSendError(record, appendCallbacks.topicPartition(), e);  
        throw e;  
    }  
}

partition机制

Producer中计算消息partition的流程较为简单：

读《中国官僚政治研究》

Wed, 01 Jan 2025 23:14:50 +0800

该书作者王亚南老师是建国初期著名的经济学家，曾翻译《资本论》、《国富论》等著名的经济学著作。本书从经济角度切入，剖析了中国秦代至民国的官僚政治的形成、发展演变。指出官僚政治的专制性质是导致中国社会长期停滞的主要原因。

他在书中多次指出：决定社会形态的是经济，换而言之，经济基础决定中国封建社会性质。

书中着重提出统治阶级想要巩固自己的统治地位，需要做到以下两点：

控制社会基本的生产资料（物质生产手段：土地）
控制精神生产手段（思想、意识形态）

统治阶级通过将官僚政治与儒家思想结合，控制上述两类资料，从而达成统治中国政治文化两千多年。因此历朝历代的变革，大都围绕以上两点进行：物质生产手段的田制税法改革、精神生产手段的科举制。

书中的一些重要观点：

知识的垄断推动了官僚阶层固化。
两税制和科举制是推动官僚政治高度发展的两个重要因素。
每个新王朝最初几代君主官僚为了收买人心、增加生产，还能保持一些戒慎恐惧的精神，等到经济高度发展后，官场腐败现象不期而然地发生。
中国农民具备极强的忍耐性，这是由宗法社会组织、伦理教义、以及一再再生产出来的那种同形态的统治方式，把他们教育、锻炼出来的。
战争的集权模式，促进了官僚政治体制的发展。
官僚政治通过政治特权，在一定名义下管制人民、以达成权势者自私自利的目的。
如何摆脱官僚政治
1. 人民自觉参与并主导政治革新运动
2. 民主手段革新官僚政治

值得注意的是，作者作为马克思主义经济学家，在书中多次对于苏联的预测，都与事实大相径庭。

Spark入门

Tue, 12 Nov 2024 15:37:52 +0800

简介

Apache Spark是一个分布式计算系统，具备以下特点：

使用RDD(Resilient Distributed Datasets)，提供了比MapReduce更为丰富的模型
基于内存计算，性能比MapReduce模型高
集成离线计算、实时计算、机器学习、图计算等模块

核心模块：

Spark Core：提供Spark核心功能，是SQL、Streaming等模块实现的基础。
Spark SQL：提供SQL进行数据查询的组件
Spark Streaming：提供流式计算的组件
MLlib：Spark平台的机器学习算法库
GraphX：面向图计算的组件

Spark名词解释：

名称	含义
Application	指用户提交的 Spark 应用程序
Job	指 Spark 作业，是 Application 的子集，由行动算子（action）触发
Stage	指 Spark 阶段，是 Job 的子集，以 RDD 的宽依赖为界
Task	指 Spark 任务，是 Stage 的子集，Spark 中最基本的任务执行单元，对应单个线程，会被封装成 TaskDescription 对象提交到 Executor 的线程池中执行
Driver	运行用户程序`main()`方法并创建SparkContext的实例
Cluster Manager	集群管理器，例如Yarn、Mesos、Kubernetes等

Spark运行过程：

Driver执行用户程序的main方法，并创建SparkContext，与Cluster Manager建立连接。
Cluster Manager为用户程序分配计算资源，返回可使用的Executor列表。
获取Executor资源后，Spark会将用户程序代码以及依赖包，发送给Executor
SparkContext发送task到Executor，由executor执行计算任务。

Demo

<dependency>  
    <groupId>org.apache.spark</groupId>  
    <artifactId>spark-core_2.12</artifactId>  
    <version>3.1.2</version>  
    <scope>provided</scope>  
</dependency>

import org.apache.spark.SparkConf;  
import org.apache.spark.api.java.JavaPairRDD;  
import org.apache.spark.api.java.JavaRDD;  
import org.apache.spark.api.java.JavaSparkContext;  
import scala.Tuple2;  
  
import java.util.Arrays;  
  
public class WordCountDemo {  
  
    private static void wordCount(String fileName) {  
  
        SparkConf sparkConf = new SparkConf().setMaster("local").setAppName("JD Word Counter");  
  
        JavaSparkContext sparkContext = new JavaSparkContext(sparkConf);  
  
        JavaRDD<String> inputFile = sparkContext.textFile(fileName);  
  
        JavaRDD<String> wordsFromFile = inputFile.flatMap(content -> Arrays.asList(content.split(" ")).iterator());  
  
        JavaPairRDD countData = wordsFromFile.mapToPair(t -> new Tuple2(t, 1)).reduceByKey((x, y) -> (int) x + (int) y);  
  
        countData.saveAsTextFile("CountData");  
    }  
  
    public static void main(String[] args) {  
  
        if (args.length == 0) {  
            System.out.println("No files provided.");  
            System.exit(0);  
        }  
  
        wordCount(args[0]);  
    }  
}

提交应用：

Flink入门

Fri, 11 Oct 2024 21:37:41 +0800

简介

Apache Flink是一个用于有状态的并行数据流的分布式计算系统，同时支持流式处理和批量处理。

实际数据分析应用都是面向无限数据流，三类通常使用有状态流处理实现的应用程序：

事件驱动应用程序：使用特定的业务逻辑来提取事件流并处理事件。
1. 实时推荐、行为模式检测、异常检测
数据管道应用程序：将数据从A组件复制到B组件的ETL流程，pipeline包括多个源（source）和接收器（sink）。 3. 实时数据仓库：数据实时清洗、归并、结构化
数据流式分析应用程序：连续地提取事件流数据，并计算出最新结果并存储，用于查询。
1. 用户行为等实时数据分析

常见的流式处理框架对比：

	Flink	Spark Streaming	Apache Storm
架构	主从模式	主从模式，依赖Spark，每个Batch处理都依赖主节点	主从模式，依赖ZK
处理方式	Native	Micro-Batch	Native
容错	基于Chandy-Lamport distributed snapshots checkpoint机制	WAL与RDD机制	Record’s ACK
处理模式	单条事件处理、时间窗口划分的所有事件	时间窗口内的所有时间	单条事件处理
数据保证	exactly once	exactly once	at least once
API支持	high	high	low
社区活跃度	high	high	medium
部署性	部署简单，仅依赖JRE	部署简单，仅依赖JRE	依赖JRE和Zookeeper

Flink优点：

毫秒级延迟
统一数据处理组件栈，可以处理不同类型的数据需求
支持事件时间、接入时间、处理时间等概念
基于轻量级分布式快照实现的容错
支持有状态计算，灵活的state-backend（HDFS、内存、RocksDB）
满足Exactly-once需求
支持高度灵活的window操作
带反压的连续流模型
每秒千万级吞吐量
易用性：提供了SQL、Table API、Stream API等方式

流式计算的时间窗口，涉及处理时间和事件时间，主要有以下区别：

JVM内存问题排查流程

Sun, 03 Mar 2024 21:34:49 +0000

确认问题现象

可以通过服务状态，监控面板、日志信息、监控工具（VisualVM）等，确认问题类型：

内存使用率居高不下、内存缓慢增加、OOM等
频繁GC：Full GC等

发现问题不建议重启，留存状态。

保留数据

heapdump文件

#arthas导出方式
heapdump /tmp/dump.hprof

#jmap命令保存整个Java堆
jmap -dump:format=b,file=heap.bin <pid> 

#jmap命令只保存Java堆中的存活对象, 包含live选项，会在堆转储前执行一次Full GC
jmap -dump:live,format=b,file=heap.bin <pid>

#jcmd命令保存整个Java堆,Jdk1.7后有效
jcmd <pid> GC.heap_dump filename=heap.bin

#在出现OutOfMemoryError的时候JVM自动生成（推荐）节点剩余内存不足heapdump会生成失败
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/heap.bin

#编程的方式生成
使用HotSpotDiagnosticMXBean.dumpHeap()方法

#在出现Full GC前后JVM自动生成，本地快速调试可用
-XX:+HeapDumpBeforeFullGC或 -XX:+HeapDumpAfterFullGC

JVM参数：

-XX:printGCDetails -XX:+UseConcMarkSweepGC -XX:+HeapDumpOnOutOfMemoryError

GC日志

JVM启动参数如下：

# Java8及以下
-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:<path>

# Java9及以上
-Xlog:gc*:<path>:time

可以通过EasyGC进行日志分析。

服务日志

通常由日志组件（Promtail & loki）进行采集、存储、展示。

实际问题

堆内存溢出

问题现象：

OutOfMemoryError

直接内存溢出

问题现象：top指令中相关Java进程占用的RES超过了-Xmx的大小，并且内存占用不断上升。

问题定位方法：

可通过开启NMT（-XX:NativeMemoryTracking=detail）定位问题
jcmd查看直接内存情况：jcmd pid VM.native_memory detail

NIO、Netty等常用直接内存，Netty可以通过-Dio.netty.leakDetectionLevel开启

栈空间溢出

问题现象：

StackOverflow
OutOfMemoryError：unable to create new native thread

问题定位方法：

《软件研发效能之美》思维导图

Sun, 14 Jan 2024 21:40:59 +0000

OSDI'10 《Finding a needle in Haystack Facebook’s photo storage》

Fri, 08 Dec 2023 22:57:50 +0000

业务量级

FaceBook存储超过2600亿张图片，20PB，一周存储10亿张，峰值每秒100W图片。一次性写、不修改、很少删除的图片数据。

原始设计的挑战

访问webserver，获取图片URL，先去CDN获取，cache hit则返回，miss则去Storage加载到CDN再返回。

当文件存储NAS的文件夹存储数千个文件时，请求单个图片的请求会产生多于10次的磁盘IO，即使文件夹内文件数量下降到几百时，还是会产生三次磁盘IO。

可以看出，原始架构的性能瓶颈：读操作存在多次磁盘IO。

传统POSIX filesystem缺点：文件元信息，例如权限等信息占用较多存储成本。对于巨量数据的情况，成本极大，对于NAS，一个文件读写需要三次磁盘IO：

根据filename获取inode number
读取指定inode
读取文件信息本身

设计目标

Haystack结构实现的四个目标：

高吞吐量与低延迟：所有metadata都存储在内存，最多执行一次磁盘IO
容错：异地容灾
低成本
简单

新设计

Haystack主要解决上述架构的瓶颈问题：多次磁盘IO，关键方法：将多个图片存储为单个大文件，由此仅需要保存大文件的文件元信息。

Haystack架构包括以下三部分：

Haystack Store：真正存储文件的组件，管理文件系统元信息。使用物理volume进行管理，可以将不同主机上的某些物理volume组成一个逻辑volume，这样就可以产生多份副本，进行容错或分流。
Haystack Directory：管理逻辑到物理volume的映射关系，以及一些应用元信息，例如图片到逻辑volume的映射，逻辑volume的空闲空间等信息。
Haystack Cache：内部缓存CDN，减少对外部CDN的依赖。

浏览器从Haystack Directory组件获取到的URL如下：

http://〈CDN〉/〈Cache〉/〈Machine id〉/〈Logical volume, Photo〉

CDN，Haystack Cache层如果hit cache就返回，否则去掉该层地址，请求转发到下一层。

Haystack Directory

四个功能：

逻辑volume到物理volume的映射。
跨逻辑卷读写的负载均衡能力。
决定一个请求是由CDN处理还是Cache处理。
检查逻辑卷是否因为操作原因或达到存储容量导致read-only

Haystack Cache

从浏览器或CDN接收HTTP请求。该组件使用图片id定位数据，将其组织成了分布式hash table，如果cache miss，则去Haystack Store服务器获取图片信息。

对图片进行cache的两个必要条件：

请求直接来自浏览器而非CDN
图片从可写服务器获取的

Haystack Store

每台存储服务器都维护了多个逻辑volume，每个volume都可以理解为一个大文件（100 GB ），文件名为/hay/haystack_<volume_id>，可以通过逻辑volume id和图片offset快速定位到图片信息，可以不通过磁盘IO读取图片（Q：为什么能不通过磁盘操作读取到磁盘数据？），服务器都在内存中维护着物理卷对应文件描述符和图片id到文件系统元信息的映射关系

具体的物理结构如下图所示：

每台存储服务器代表着一个物理卷，同时也称为superblock，其中包括多个needle，每个needle存储着图片元信息和图片数据。

Read

来自Cache服务器的读请求会有以下参数：逻辑volume id、key、alternate key、cookie，Store服务器首先从内存中查找对应元信息，然后读取图片数据，使用checksum进行校验后返回。

Write

写请求会包括以下参数：逻辑volume id、key、alternate key、cookie、data，Store服务器将数据组装成needle结构并追加到volume file中。如果(key, alternate key)唯一二元组存在重复问题，有两种情况：

述职报告要点小记

Sun, 07 May 2023 20:32:25 +0000

述职目的

企业：掌握员工的具体工作情况与表现。
个人：对自己的阶段性总结、反思、阶段规划

文档结构

概述

核心：用一分钟总结一下自己这段时间干了些什么，让大家对你有个总体的认知。业务结果有两个重点：

归因：业务结果与个人的关系
增量：业务价值有一定的增量部分
技术结果：个人的技术能力
1. 不要造轮子
2. 带来变化：新项目、代码重构、性能优化、技术先进性、效率提升等

工作总结（重点）

业务背景

核心：搞清楚why

方法论：

靠谱的PD，会把why说清楚
不靠谱的PD，需要自己去调研清楚，调研方案：
1. 扩大自己的领域知识
2. 请教专家

解题思考

需要盘清楚现有的资源情况（人力、机器、资金、组织等），然后给出最合适的解决方案，这个过程就是解题思考。

目标制定

环境决定决策：业务目标由业务增长率决定
技术目标：技术目标是围绕着业务在当前的阶段或形态来设定的

技术方案

面向未来的架构设计：着眼眼前，根据眼前的情况定一个合适的目标，设计系统要面向未来
怎么画系统架构图（四部分）：系统和外部的边界、内部组件的上下左右关系、系统的非功能性设计、面向未来的设计
- 面向未来的设计：起码看到未来三年的发展形态，抽象总结业务表层问题，把本质抽象成领域模型的概念。
落地再次贴近现实：架构设计完成后，到具体的落地环节，做出时序图、流程图等，最好能做到后面可以直接编码的程度，后续的多次迭代其实就是对原始的图不断完善和扩展。
技术深度：某个领域，通过长时间的沉淀积累，总结出一套在该领域下的技术方案。

结果说明

具体的数据、计算公式等，技术结果可以把核心模块、扩展性、性能等方面例举出来

总结反思

总结出做得好的和做的不好的地方。

个人成长&团队贡献

可迁移的个人能力：复杂系统架构设计能力、结构化思考能力、组织协调能力、项目管理能力、团队管理能力、沟通能力、演讲能力、数据洞察能力
团队贡献：本质还是个人成长，需要把你的成长输出给团队成员。

财年规划

一块业务的下一年的规划

难点：

业务定位
衡量指标
核心业务&技术问题，解决方案
竞品分析
资源组织最大化
风险分析
…………

Reference

来自一线技术人的经验分享｜如何写出让人眼前一亮的述职报告

《十次经济危机》学习笔记

Sat, 29 Apr 2023 13:39:13 +0000

概述

本课程分析了中国从1949-2018的十次经济危机。

理性分析专业知识，无任何意识形态掺杂在内。

背景和问题

二战后超级大国地缘政治的不确定性以及冷战特点：

战后双寡头地缘政治重构派生两个雁阵式重工产业转移：
- USA完成了对西欧日韩的控制（马歇尔计划）
  - 朝鲜战争导致日本得到美国约150亿美元投资再实现工业化
  - 中国得到苏联约50亿美元投资用于国家工业化
- USSR完成对东欧的控制，但受阻于中国维护原住民暴力革命夺取的国家主权
  - 中国土改利于新政权战胜最初的危机但不利于工业化：分散小农户经济70%在山区不可能使用工业化产品；资本不断增密的重工业无法提取原始积累

现代化：资本和风险向城市集中的过程，周期性爆发危机，是一个阶段性过程。

美国最严重经济波动发生于一战和二战时期。

中国严重波动发生于西方主导的冷战时期，伴随着意识形态偏差的庸俗化传播。

土地革命完成了：动员全民参加经济建设，土改提供的农产品打赢了城市私人资本引导的白色大战。

工业化：资本增密、排斥劳动力的过程。

1950-1960：第一次外资因苏联1967年援助投资终止而引发60-62和68-70两次债务/赤字/危机。
1971-1980：第二次外资引进西方设备，造成74-76和79-81两次外债/赤字/危机。
1980-1990：第三次外资（改革开放）造成88-89和93-94两次恶性通胀经济危机。
1990-now：第四次外资，带来98-99输入性通缩演化为第一次生产过剩，08-09输入型通胀，2015受西方债务危机影响发生第二次生产过剩
- 产业资本危机->金融资本危机
- 三大差距逐渐拉大：沿海和内地的区域差别、城市和乡村的收入差别、贫富差距
- 政府通过倾斜投资来缓解差距，基础设施建设、农村五通，促进经济发展。
- 国债投资基础设施建设存在的三个问题
  - 贷款被国有企业占有，既不产生税收，也不产生回报，对私人企业有挤出效应，资本主义国家也无法避免。
  - 短期生产过剩通过投资解决，无法根治，导致长期产生。
  - 金融资本流动性减缓，导致金融资本不断扩张，导致金融资本过剩
- 2020之后产业资本、商业资本、金融资本全部过剩

中国的金字塔形双稳态经济/社会结构：

经济结构
- 地方主要掌握实质资产500万亿，土地随基建投资升值到150万亿。
- 中央主要掌握金融资产180万亿（可扩张）
- 无限负责政府债务资产约40万亿（可扩张）
社会结构
- 地方面对分散小资60%（农民住宅拥有率约为100%）
- 地方面对新崛起中资30-40%，约为5亿人
- 中央掌握政治化大资约10%

就业形势：

劳动力总量8亿，每年增加0.1亿
- 农村劳动力5亿：农业需要0.5亿、乡镇企业吸纳1亿、进城打工2.2亿、仍有1亿以上需要非农就业。
- 越多劳动力进入市场，劳工待遇越差
  - 收入减少、劳动强度增大、缺乏社保体系
经济增长 vs 社会稳定
双重过剩：生产过剩和劳动力过剩

路权战略：

一带一路：向南向西的陆路交通建设与次区域交通网络连接。

发展中国家在资本主义文明阶段的经验归纳：

任何跟进工业化的后发国家面对资本稀缺都势所必然地采取亲资本政策，只有进入资本过剩阶段后才可能转向亲民生。
任何资本投资国都在试图运用其建制权直接控制，或以债权来渗透后发国家的政府制度体系以最大化获取资本收益。
发展中国家只有维护资源和货币主权，才能在危机挑战中使用逆周期调节。
- 没有货币主权时，危机爆发，外部资本会逃走（做空）。

新中国的第一次周期性经济危机（1949-1951）

革命红利 + 局部战争 –> 恶性通胀

政治上：三反五反
经济上：动用国有部门政府直接干预，战争拉动

引入外资->外债->财政赤字->降低财政对于扩大再生产的投入->减少就业->经济危机->社会动乱

不支持线性社会发展论，只适合地中海周围的国家

危机情况：

物价恶性上涨：解放的大城市物价上涨几十倍。
财政严重赤字：军队开支超过财政总支出60%

农业自身内在具有自然过程与经济过程高度结合的特征，在世界近代通过殖民化推工业化的资本文明史中，农业内在特质不可能被根除，客观分化为三个异质性很强的不同类型：

盎格鲁撒克逊的殖民化大农场：新大陆因彻底殖民化造成资源充足的客观条件而得以实现农业规模化和资本化，对应的是公司化和产业化的农业政策。
莱茵模式的前殖民主义宗主国（欧盟为代表）的中小农场农业：农业资本化和生态化结合，农业不能为工业化提供原始积累，也没有自由市场体制下的竞争力，另一方面与农业生态化高度相关的绿色社会运动从欧洲兴起。
未被西方彻底殖民化的原住民为主的东亚模式的传统小农经济国家的农户经济（日韩为代表）：通过对农村人口全覆盖的普惠制的综合性合作社体系来实现社会资源资本化维持工业化原始积累时期的三农的稳定。

危机根源于增发无储备货币和物价失控：

Java File IO的几种姿势

Wed, 26 Apr 2023 22:41:57 +0000

读写方式

Java中的File IO基本可以分为三类：

面向字节传输的传统IO方式
FileChannel文件通道
mmap内存映射

Buffered Stream I/O

BufferedReader通过内部buffer将文件的一部分字节缓存下来，减少频繁的磁盘IO。

public static void testStream(){
        try (BufferedReader reader = Files.newBufferedReader(Paths.get(PATH), StandardCharsets.UTF_8)) {
            String line = null;
            while ((line = reader.readLine()) != null) {
                System.out.println(line);
            }
        } catch (IOException x) {
            System.err.format("IOException: %s%n", x);
        }
    }

Unbuffered Streams I/O

public static void testUnStream() {
        try (InputStream in = Files.newInputStream(Paths.get(PATH));
             BufferedReader reader =
                     new BufferedReader(new InputStreamReader(in))) {
            String line = null;
            while ((line = reader.readLine()) != null) {
                System.out.println(line);
            }
        } catch (IOException x) {
            System.err.println(x);
        }
    }

Channel I/O

public static byte[] readAllBytes(Path path) throws IOException {
        try (SeekableByteChannel sbc = Files.newByteChannel(path);
             InputStream in = Channels.newInputStream(sbc)) {
            long size = sbc.size();
            if (size > (long)MAX_BUFFER_SIZE)
                throw new OutOfMemoryError("Required array size too large");

            return read(in, (int)size);
        }
    }


public static SeekableByteChannel newByteChannel(Path path, OpenOption... options)
        throws IOException
    {
        Set<OpenOption> set = new HashSet<OpenOption>(options.length);
        Collections.addAll(set, options);
        return newByteChannel(path, set);
    }


public static SeekableByteChannel newByteChannel(Path path,
                                                     Set<? extends OpenOption> options,
                                                     FileAttribute<?>... attrs)
        throws IOException
    {
        return provider(path).newByteChannel(path, options, attrs);
    }

public abstract SeekableByteChannel newByteChannel(Path path,
        Set<? extends OpenOption> options, FileAttribute<?>... attrs) throws IOException;

public static void testChannel() {
        try (SeekableByteChannel sbc = Files.newByteChannel(Paths.get(PATH))) {
            final int BUFFER_CAPACITY = 10;
            ByteBuffer buf = ByteBuffer.allocate(BUFFER_CAPACITY);

            // Read the bytes with the proper encoding for this platform. If
            // you skip this step, you might see foreign or illegible
            // characters.
            String encoding = System.getProperty("file.encoding");
            while (sbc.read(buf) > 0) {
                buf.flip();
                System.out.print(Charset.forName(encoding).decode(buf));
                buf.clear();
            }
        }catch (IOException e){
            System.err.println(e);
        }
    }

FileChannel

public static void testFileChannel() {
        try {
            FileChannel fileChannel = new RandomAccessFile(new File(PATH), "rw").getChannel();
            ByteBuffer byteBuffer = ByteBuffer.allocate(4);
            fileChannel.read(byteBuffer);
            String str = new String(byteBuffer.array(), StandardCharsets.UTF_8);
            System.out.println(str);
        }catch (IOException e){
            System.err.println(e);
        }
    }

mmap

适用于读写小文件的应用场景。

跑步理论知识

Sat, 15 Apr 2023 16:20:59 +0000

心率区间

心率区间有以下三种计算方式，最大心率百分比、储备心率百分比、乳酸阈值百分比

计算方式：

最大心率：220 - age
储备心率：最大心率 - 静息心率
乳酸阈值百分比：根据乳酸阈值划分心率区间

乳酸阈值：血液中乳酸浓度的增长速度快于乳酸的代谢速度，使得乳酸开始在血液中堆积的临界状态。

储备心率法

心率区间 =（最大心率-静止心率）*储备心率%+静止心率

心率区间名称	储备心率法	实际数值	说明	含义
区间1（E）	59%-74%	138-159	LSD配速，有氧耐力	轻松聊天，锻炼心肌强度，增强身体供氧能力，提高有氧耐力
区间2（M）	74%-84%	159-173	马拉松配速	呼吸加重
区间3（T）	84%-88%	173-179	乳酸阈值强度	呼吸会喘，身体开始堆积乳酸，提升乳酸阈值，增强乳酸排出能力
区间4（A）	88%-95%	179-188	无氧区间	间歇跑，增强乳酸耐受能力，提升无氧耐力
区间5（I）	95%-100%	188-196	最大摄氧量强度	高强度间歇，提高无氧能力和速度

最大心率法

心率区间名称	最大心率法	说明	实际数值
区间1（热身）	50%-60%	热身	98-117
区间2（燃脂）	60%-70%	有效燃脂，增强心肺能力	117-137
区间3（有氧耐力）	70%-80%	有氧耐力	137-156
区间4（马拉松配速）	80%-90%	提升乳酸耐受能力	156-176
区间5（无氧耐力）	90%-100%	高强度	176-196

有氧心率区间计算方法

最大心率法
储备心率法
MAF180：最大有氧心率= 180 - age

有氧能力

解析Java动态代理机制的实现

Sun, 05 Mar 2023 21:23:54 +0000

简介

代理模式主要是Proxy对原始方法做了一层包装，用以增加一些新的统一处理逻辑，来增强目标对象的功能。静态代理是传统设计模式中一种传统的实现方案，动态代理能将代理对象的创建延迟到程序运行阶段。

以下是一个动态代理的示例：

被代理类：

public interface DemoService {

    public String process(String value);
}


@Slf4j
public class DemoServiceImpl implements DemoService{

    public static final String RESULT = "result";

    @Override
    public String process(String value) {
        log.info("{} is processing, parameter: {}", this.getClass().getName(), value);
        return RESULT;
    }
}

代理类：

@Slf4j
public class DemoInvokerHandler implements InvocationHandler {

    private final Object target;

    public DemoInvokerHandler(Object target) {
        this.target = target;
    }

    @Override
    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
        log.info("before...");
        Object result = method.invoke(target, args);
        log.info("after...");
        return result;
    }

    public Object getProxy() {
        // 创建代理对象
        return Proxy.newProxyInstance(Thread.currentThread().getContextClassLoader(),
                target.getClass().getInterfaces(), this);

    }
}

代理调用：

Java SPI机制学习与常用框架SPI案例

Tue, 28 Feb 2023 17:01:26 +0000

概念

SPI（Service Provider Interface）是JDK内置的服务提供机制，常用于框架的动态扩展，类似于可拔插机制。提供方将接口实现类配置在classpath下的指定位置，调用方读取并加载。当提供方发生变化时，接口的实现也会改变。Java生态中JDK、Dubbo、Spring等都通过SPI提供了动态扩展的能力。

样例

public interface Search {
    void search();
}

public class FileSearchImpl implements Search {
    @Override
    public void search() {
        System.out.println("file search...");
    }
}

public class DataBaseSearchImpl implements Search {
    @Override
    public void search() {
        System.out.println("db search");
    }
}



public class SpiTest {
    public static void main(String[] args) {
        ServiceLoader<Search> searches = ServiceLoader.load(Search.class);
        searches.forEach(Search::search);
    }
}

resources文件夹创建META-INF/services/wang.l1n.spi.Search文件，内容为接口实现类：

wang.l1n.spi.FileSearchImpl
wang.l1n.spi.DataBaseSearchImpl

运行结果：

load加载流程

ServiceLoder.load静态方法用于加载SPI实现类，实现逻辑如下：

获取当前线程类加载器和上下文信息，调用实例化方法，重新加载SPI
重新加载SPI的流程：
1. 清空缓存providers中已实例化的SPI服务，providers是LinkedHashMap类型，用于保存已经被成功加载的SPI示例对象
  - 如果providers非空，直接返回Iterator，否则返回LazyIterator的Iterator。
2. 创建LazyIterator懒加载迭代器，传入SPI类型和类加载器

实现代码和对应的成员变量如下：

public static <S> ServiceLoader<S> load(Class<S> service) {
        ClassLoader cl = Thread.currentThread().getContextClassLoader();
        return ServiceLoader.load(service, cl);
    }

public static <S> ServiceLoader<S> load(Class<S> service,
                                            ClassLoader loader)
    {
        return new ServiceLoader<>(service, loader);
    }

private ServiceLoader(Class<S> svc, ClassLoader cl) {
        service = Objects.requireNonNull(svc, "Service interface cannot be null");
        loader = (cl == null) ? ClassLoader.getSystemClassLoader() : cl;
        acc = (System.getSecurityManager() != null) ? AccessController.getContext() : null;
        reload();
    }

public void reload() {
        providers.clear();
        lookupIterator = new LazyIterator(service, loader);
    }

	
	private static final String PREFIX = "META-INF/services/";

    // The class or interface representing the service being loaded
    private final Class<S> service;

    // The class loader used to locate, load, and instantiate providers
    private final ClassLoader loader;

    // The access control context taken when the ServiceLoader is created
    private final AccessControlContext acc;

    // Cached providers, in instantiation order
    private LinkedHashMap<String,S> providers = new LinkedHashMap<>();

    // The current lazy-lookup iterator
    private LazyIterator lookupIterator;

public Iterator<S> iterator() {
        return new Iterator<S>() {

            Iterator<Map.Entry<String,S>> knownProviders
                = providers.entrySet().iterator();

            public boolean hasNext() {
                if (knownProviders.hasNext())
                    return true;
                return lookupIterator.hasNext();
            }

            public S next() {
                if (knownProviders.hasNext())
                    return knownProviders.next().getValue();
                return lookupIterator.next();
            }

            public void remove() {
                throw new UnsupportedOperationException();
            }

        };
    }

LazyIterator加载流程

加载流程参考代码注释：

状态机引擎的业务实践

Sat, 25 Feb 2023 20:57:00 +0000

前言

在开发中通常会有状态属性，例如订单状态、事件处置状态、OA请假单状态等，都会根据不同的动作，去更新对应的状态。如下：

int status = 0;  
if (condition1){  
    status = 1;  
}else if (condition2){  
    status = 2;  
}else if (condition3){  
    status = 3;  
}

上述示例存在的问题：

在需求增加的情况下，if.else会不断膨胀
代码可读性差，略微改动会导致各种问题
其他业务逻辑会耦合在if.else代码段中

针对系统中状态的管理，可以使用有限状态机去解决，有限状态机是表示有限个状态以及状态间转移的模型。状态机由事件、状态、动作三部分组成。

状态机的简单实现

条件分支判断

最简单的方案是通过条件分支控制状态的转移，这适合于业务状态较少，并且状态跳转的逻辑较简单的场景，但是当触发事件较多时，需要嵌套多层条件判断，当需求中状态变更事件改变时，需要改动的逻辑较大。案例代码如下：

public enum ActivityState {

    PREPARE(0),
    STARTED(1),
    END(2)
    ;

    public final int status;


    ActivityState(int status) {
        this.status = status;
    }

    public int getStatus() {
        return status;
    }
}

/**
 * 活动状态-状态机
 * @author l1nker4
 */
public class ActivityStateMachine {
    /**
     * 活动状态
     */
    private ActivityState currentState;

    public ActivityStateMachine() {
        this.currentState = ActivityState.PREPARE;
    }


    /**
     * 活动开始
     */
    public void begin() {
        if (currentState.equals(ActivityState.PREPARE)) {
            this.currentState = ActivityState.STARTED;
            //do something....
        }
    }

    /**
     * 活动结束
     */
    public void end(){
        if (currentState.equals(ActivityState.STARTED)){
            this.currentState = ActivityState.END;
            //do something...
        }
    }

}

状态模式实现

设计模式中的状态模式也是状态机的一种实现方式，定义了状态-行为的对应关系，并将各自的行为封装到状态类中。状态模式会引入较多的状态类和方法，需求变更时维护成本大。

HTTPS通信过程分析

Fri, 10 Feb 2023 21:33:11 +0000

为什么需要HTTPS

HTTP缺点：

明文传输
C/S两端不存在验证机制，无法确认对方身份，可能存在中间人攻击。

概念

对称加密：客户端和服务器持有同一个密钥对数据进行加密解密。
非对称加密：公钥加密私钥解密、私钥加密公钥解密
CA：证书认证机构，签发数字证书，保证公钥的可信度。
数字证书：包含版本、序列号、有效期、颁发者、公钥等信息

数字证书是由CA颁发用于证明身份的证书，通过域名申请对应证书，域名的合法性由CA机构保证。

TLS有以下几个子协议：

记录协议（Record Protocol）：规定TLS收发数据的基本单位为record，类似于TCP的segment，所有子协议都必须通过记录协议发出。
警报协议（Alert Protocol）：向对方发出警报信息，比如：证书问题等
握手协议（Handshake Protocol）：两端协商TLS版本号、随机数、密码套件等信息，然后客户端通过服务端的公钥和证书上的数字签名、两端协商得到会话密钥。
变更密码规范协议：通知对方后续数据使用密码加密保护

HTTPS通信过程

HTTPS通信可以划分为三个阶段：

TCP协议：通过三次握手建立TCP连接
TLS协议：四次握手建立TLS连接
HTTPS协议：客户端发送请求，服务端响应请求，通信报文使用密钥加密。
TLS 1.2 握手：使用非对称加密方式创建对称密钥，并使用对称加密完成HTTP通信。

详细过程：

客户端发送Client Hello消息到服务端，消息包含TLS版本、加密套件（Cipher Suite）、压缩算法、随机数，会话信息扩展信息等。
服务端发送Server Hello消息，消息包含服务端的TLS版本、加密套件（Cipher Suite）、会话信息
服务端发送Certificate消息，包括服务端的证书信息。
服务端发送Server Key Exchange消息，发送公钥与签名信息等。可能与Server Hello Done消息一同发送。
客户端发送Client Key Exchange消息，根据自己信任的CA列表，验证服务端证书是否可行，可信则生成一串伪随机数，并使用公钥加密，这串随机数被用于生成新的对称密钥。
服务器端使用私钥解密随机数，并使用随机数生成自己的对称主密钥。
客户端发送Finished消息，使用对称密钥加密这次通信的hash值。
服务端生成自己的hash值，然后解密客户端发来的信息，检查这两个值是否对应，若对应则发送Finished消息。
接下来，整个HTTP会话都是用对称密钥进行加密并传输。

TLS握手的关键点：通过生成的随机数和服务端公钥，生成新的密钥，后续通信使用这个对称密钥加密，防止中间人攻击。

ShardingSphere-JDBC学习笔记

Wed, 11 Jan 2023 18:41:32 +0000

基础概念

ShardingSphere-JDBC是Apache ShardingSphere项目中的一个子项目，Apache ShardingSphere是一款分布式的数据库生态系统，可以通过分片、弹性伸缩、加密等能力对原有数据库进行增强。

ShardingSphere-JDBC定位是轻量级Java框架，在JDBC层提供额外服务。它能尽量透明化水平分库分表所带来的影响，让业务方逻辑上感知到一个数据库节点和逻辑表，当收到SQL查询，主要做了以下工作：

SQL解析：词法解析和语法解析，提炼出解析上下文
SQL路由：根据解析上下文匹配用户配置的库表的分片策略，并生成路由后的SQL（一条或多条）。
SQL改写：将SQL改写为物理数据库能正常执行的语句（逻辑SQL -> 物理SQL）。
SQL执行：通过多线程异步执行改写后的SQL语句。
结果归并：将多个执行结果归并为统一的JDBC接口输出。

几个概念：

逻辑表：ORM框架的业务层面，表现为一张表，例如：t_order
物理表：数据库层面实际存在的表，例如：t_order_0、t_order_1
绑定表：分片规则一致的一组分片表，进行关联查询时，建议使用分片键进行关联，否则影响查询效率。
- SELECT i.* FROM t_order o JOIN t_order_item i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);
广播表：数据源中都存在的表，且结构和数据都完全一致。适用于数据量不大且需要与其他大数据量表进行关联查询。
分片键：根据某个字段的计算结果（取模等）进行水平分片
路由：通过SQL语句中的信息，找到对应分片的过程

分片算法

标准分片算法：单一键作为分片键。
- 取模算法：根据一些字段，或多个字段hash求值再取模。
- 范围限定算法，按照年份、实践等策略路由到目标数据库。
复合分片算法：多键作为分片键，自行设计
Hint分片算法：用于处理使用Hint行分片的场景（非数据库字段的分片方式）

分片策略

包含分片键和分片算法，ShardingSphere-JDBC提供了以下几种分片策略：

标准分片策略（StandardSharingStrategy）：使用精确分片算法或范围分片算法，支持单分片键。
复合分片策略（ComplexShardingStrategy）：使用复合分片算法，支持多分片键。
Hint分片策略（HintShardingStrategy）：使用Hint分片算法
Inline分片策略（InlineShardingStrategy）：使用groovy表达式作为分片算法
不分片策略（NoneShardingStrategy）：不使用分片算法

Demo

pom.xml

<dependency>
            <groupId>org.mybatis.spring.boot</groupId>
            <artifactId>mybatis-spring-boot-starter</artifactId>
            <version>2.1.4</version>
        </dependency>

        <dependency>
            <groupId>com.mysql</groupId>
            <artifactId>mysql-connector-j</artifactId>
            <scope>runtime</scope>
            <version>8.0.32</version>
        </dependency>
        <dependency>
            <groupId>org.projectlombok</groupId>
            <artifactId>lombok</artifactId>
            <optional>true</optional>
        </dependency>
        <dependency>
            <groupId>com.baomidou</groupId>
            <artifactId>mybatis-plus-boot-starter</artifactId>
            <version>3.2.0</version>
        </dependency>
        <dependency>
            <groupId>com.alibaba</groupId>
            <artifactId>druid</artifactId>
            <version>1.2.15</version>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.apache.shardingsphere</groupId>
            <artifactId>sharding-jdbc-spring-boot-starter</artifactId>
            <version>4.0.0-RC1</version>
        </dependency>

        <dependency>
            <groupId>org.apache.shardingsphere</groupId>
            <artifactId>sharding-core-common</artifactId>
            <version>4.0.0-RC1</version>
        </dependency>

ShardingSphere提供了多种配置方式：

Netty学习笔记(三)- 时间轮算法

Sat, 03 Dec 2022 10:12:54 +0000

定时器理论

实际的业务场景会遇到许多使用定时任务的场景，定时器主要有三种表现形式：固定周期定时执行、延迟一定时间执行，指定某个时刻执行。再实现层面，定时器需要考虑存储和调度指定任务，内部通过轮询的方式检查任务是否到期并需要执行。

Java定时器

Java提供了三种常用的定时器实现方式：

Timer
DelayQueue
ScheduledThreadPoolExecutor

Timer

Timer使用的就是上述最原始的定时器实现方式：

存储：TaskQueue是数组实现的小根堆，deadline最近的任务位于堆顶端。
调度：TimerThread异步线程，定时轮询队列，如果堆顶任务的deadline已到，那么执行任务，如果是周期性任务，执行完计算下次deadline，并再次放入小根堆。

public class Timer {

    private final TaskQueue queue = new TaskQueue();

    private final TimerThread thread = new TimerThread(queue);
    public Timer(String name) {

        thread.setName(name);

        thread.start();

    }

}

Timer存在几个缺陷：

单线程模式，某个TimeTask阻塞，会影响其他的任务调度。
Timer的任务调度基于系统时间的，系统时间不正确，可能出现问题。
TimeTask执行出现异常，Timer不会捕获，线程终止后，其他任务都不能执行。

使用案例：

Timer timer = new Timer();

//设置一个10s后调度一个周期为1s的定时任务
timer.scheduleAtFixedRate(new TimerTask() {

    @Override

    public void run() {

        // do something

    }

}, 10000, 1000);

DelayQueue

DelayQueue是一种可以延迟获取对象的阻塞队列，内部使用PriorityQueue存储任务，每个元素必须实现Delayed接口，并重写指定方法。DelayQueue提供了put和take两个阻塞方法。对象put进去后，通过compareTo进行优先级排序，getDelay计算出剩余时间，只有小于等于0时，对象才能从其中被取出。

实际上只实现了存储定时任务的功能，还需要配合异步线程才能实现定时器。

ScheduledThreadPoolExecutor

该线程池继承于ThreadPoolExecutor，提供了周期执行和延迟执行的功能，在ThreadPoolExecutor的基础上，重新设计了任务ScheduledFutureTask和阻塞队列DelayedWorkQueue。

Netty学习笔记(二)- 内部机制

Sat, 19 Nov 2022 08:12:54 +0000

事件调度层

Reactor线程模型

Netty中三种Reactor线程模型来源于Scalable I/O in Java，主要有以下三种：

单线程模型：所有IO操作（连接建立、读写、事件分发）都由一个线程完成。
多线程模型：使用多线程处理任务。线程内部仍然是串行化。
主从多线程模型：主线程只负责连接的Accept事件，从线程负责除连接外的事件。

Reactor线程模型运行机制可以分为以下四个步骤：

注册连接：将Channel注册到Reactor线程中的Selector。
事件轮询：轮询Selector中已注册的Channel的IO事件。
事件分发：将连接的IO事件分发给worker线程。
任务处理：Reactor线程负责队列中的非IO任务。

EventLoop

EventLoop是一种事件处理模型，Netty中EventLoop运行机制如下图所示：

BossEventLoopGroup：负责监听客户端的Accept事件，触发时将事件注册到WorkerEventLoopGroup中的一个NioEventLoop，
WorkerEventLoopGroup：每建立一个Channel，都选择一个NioEventLoop与其绑定，Channel的所有事件都是线程独立的。不会和其他线程发生交集。

任务处理机制

NioEventLoop不仅负责处理IO事件，还要兼顾执行任务队列中的任务。任务队列遵守FIFO原则。任务基本可以分为三类：

普通任务：通过NioEventLoop的execute()方法向taskQueue中添加的。
定时任务：通过NioEventLoop的schedule()方法向scheduledtaskQueue添加的定时任务，例如心跳消息可以通过该任务实现。
尾部队列：执行完taskQueue中任务后会去获取尾部队列tailTasks中的任务去执行。主要做收尾工作，例如统计事件循环的执行时间等。

使用技巧

使用Boss和Worker两个Group分别处理不同的事件，合理分担压力。
对于耗时较长的ChannelHandler可以考虑维护一个业务线程池，将任务封装成Task进行异步处理。，避免ChannelHandler阻塞而造成EventLoop不可用。
选用合理的ChannelHandler数量，明确业务和Netty的分层。

服务编排层

ChannelPipeline

Pipeline如同字面意思，原始的网络字节流流经pipeline，被逐层处理，最终得到成品数据并返回。Netty中的ChannelPipeline采取责任链模式，调用链路环环相扣。

ChannelPipeline由一组ChannelHandlerContext组成，内部通过双向链表将ChannelHandlerContext连接起来，当IO事件触发时，依次调用Handler对数据进行处理。ChannelHandlerContext用于保存ChannelHandler的上下文，包含了其生命周期的所有事件：connect、bind、read等。

根据数据流向，ChannelPipeline可以分为入站和出站两种处理器，对应ChannelInboundHandler和ChannelOutboundHandler。

异常处理

ChannelHandler采用了责任链模式，如果前置的Handler抛出呢Exception，会传递到后置Handler，异常处理的最佳实践，就是在最后加上自定义的异常处理器。

public class ExceptionHandler extends ChannelDuplexHandler {

    @Override

    public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) {

        if (cause instanceof RuntimeException) {

            System.out.println("Handle Business Exception Success.");
        }
    }

}

零拷贝

Netty中面向用户态的数据操作优化，主要包含以下几个方面：

使用堆外内存，避免JVM内存到堆外内存之间的数据拷贝
使用CompositeByteBuf，可以组合多个Buffer，将其合并成逻辑上的一个对象，避免物理的内存拷贝。
使用Unpooled.wrappedBuffer，将byte数组包装成ByteBuf对象，过程间不产生内存拷贝。
ByteBuf.slice切分时不产生内存拷贝，底层共享一个byte数组。
使用FileRegion实现文件传输，使用的FileChannel#transferTo()，直接将缓冲区数据输出到目标Channel，避免内核缓冲区和用户态缓冲区的数据拷贝。

MinIO的分布式存储实践方案

Fri, 19 Aug 2022 21:12:54 +0000

简介

MinIO是一个开源的分布式对象存储组件，它兼容Amazon S3 API，适合于存储大容量的非结构化数据，支持单个对象最大5TB。

MinIO特点：

部署简单，仅需要单独一个二进制文件
支持纠删码机制，能恢复部分数据块丢失的情况。
读写性能高

基础原理

纠删码

纠删码是分布式存储领域常见的一种冗余技术，与副本机制相对比，纠删码拥有更高的磁盘利用率。纠删码的基本原理：通过纠删码算法对原始数据进行计算，得到冗余的编码数据，并将数据和冗余编码一起存储，如果未来存储介质发生故障，导致其中部分数据出错，此时可以通过对应的重构算法，解码出完整的原始数据，以达到容错的目的。即总数据块 = 原始块 + 校验快($n = k + m$)。纠删码技术的磁盘利用率为$k / (k + m)$，允许总数据块中任意m个数据块损坏。

上面提到的n、m的比值，是衡量纠删码的核心参数，这个值被称为冗余度，冗余度越高（校验快越多），允许丢失的数据块可以越多，同时数据存储成本也就越高。k值决定数据分块的粒度，k越小，数据分散度越小、重建代价越大。k值越大，数据拷贝的负载越大。常见的公有云独享存储的冗余度一般在1.2-1.4左右。

目前常用的纠删码算法：Reed-Solomon，它有两个参数n和m，记为$RS(n , m)$。n代表原始数据块个数。m代表校验块个数。

下图中是使用16块磁盘作为存储设备的情况，假设此时MinIOn持有16个磁盘，MinIO会将其中8块作为数据盘，另外八块作为校验盘，数据盘存储对象的原始数据，校验盘存储对象的校验数据。纠删码默认配置是1:1，也就是将所有磁盘中的一半作为数据盘，一半做为校验盘。同时MinIO使用HighwayHash编码计算数据块的hash值，获取文件时会计算hash值来校验文件的准确性。

纠删码缺点
- 需要读取其他的数据块和校验块
- 编码解码需要消耗CPU资源
纠删码优点
- 副本机制对于大文件机极其消耗磁盘空间，纠删码可以通过较少的磁盘冗余，较为高效的解决数据丢失的问题。
应用场景
- 对于不被长期访问的冷数据，采用纠删码技术，可以大大减少副本数量。

Server Pool

使用minio server指令创建的MinIO节点集合，提供对象存储和处理请求的功能。

MinIO可以通过增加Server Pool的方式，实现集群的横向扩展。

当有新的Server Pool加入Cluster，存储的元数据会进行同步，但是其他Server Pool已存储对象不会同步。

举例：

minio server https://minio{1…4}.example.net/mnt/disk{1…4}代表一个Server Pool，其中有四个server节点各有4块磁盘。
minio server https://minio{1…4}.example.net/mnt/disk{1…4} https://minio{5…8}.example.net/mnt/disk{1…4}代表有两个Server Pool。

MinIO选择Server Pool策略；选择剩余空间最大的Server Pool进行存储。

存储级别

MinIO目前支持两种存储级别：Reduced Redundancy和Standard，提供两种不同的级别来修改数据块和校验块的比例。MinIO使用EC:N来表示EC Set中存储校验块的磁盘数量，N越大，容错能力越强，但占用磁盘空间越多。

可以通过在S3 Put API中添加x-amz-storage-class参数来指定当前文件的存储级别。

Standard：默认使用的存储级别，EC:N参数与Set中磁盘数量有关。可通过环境变量MINIO_STORAGE_CLASS_STANDARD=EC:N来设置，N不能大于磁盘数量的一半。
Reduced Redundancy：使用比Standard级别更少的磁盘数量存储校验块。通过环境变量MINIO_STORAGE_CLASS_RRS=EC:N来设置。默认参数为EC:2

Netty学习笔记(一)-概览

Sat, 06 Aug 2022 08:12:54 +0000

简介

Netty是一个应用于网络编程领域的NIO网络框架，通过屏蔽底层Socket编程细节，封装了提供上层业务使用的API，简化了网络应用的开发过程。Netty需要关注以下几点：

IO模型、线程模型
事件处理机制
API接口的使用
数据协议、序列化的支持

Netty的IO模型是基于非阻塞IO实现的，底层通过JDK NIO中的Selector实现，Selector可以同时轮询多个Channel，采用epoll模式后只需要一个线程负责Selector的轮询。

IO多路复用的场景中，需要一个Event Dispather负责将读写事件分发给对应的Event Handler，事件分发器主要有两种：

Reactor：采用同步IO，实现简单，适用于处理耗时短的场景，耗时长的IO操作容易出现阻塞。
Proactor：采用异步IO，实现逻辑复杂，性能更高

Netty的优点：

易用：将NIO的API进一步封装，提供了开箱即用的工具
稳定：修复了NIO的bug
可扩展：可以通过启动参数选择Reactor线程模型
低消耗：Netty性能优化
- 对象池复用
- 零拷贝

NIO基础

NIO是一种同步非阻塞的IO模型，NIO与普通IO的最大区别就是非阻塞，通过每个线程通过Selector去监听多个Channel，并且读写数据是以块为单位，与BIO相比，大大提升了IO效率。

BIO存在的问题：

accept、read、write都是同步阻塞，处理IO时，线程阻塞。
BIO模型严重依赖线程，线程资源比较宝贵。
- Linux中用task_struct管理，创建或销毁线程使用系统调用，开销大，并且进程切换也存在开销
- 每个线程在JVM中占用1MB内存，连接数量大的时候，极易产生OOM

Standard IO是对字节流进行读写，读写单位是字节，NIO将IO抽象成块，读写单位是块。

基本概念：

Channel：对原IO包中流的模拟，可以通过它来读取和写入数据，数据流向是双向的。
- FileChannel：从文件中读取数据
- DatagramChannel：通过UDP读写网络数据
- SocketChannel：通过TCP读写网络数据
- ServerSocketChannel：监听新的TCP连接，对每个新连接都创建一个SocketChannel
Buffer：Channel中的数据都需要通过Buffer进行传递，本质上是数组
- ByteBuffer、CharBuffer等
- Buffer的内部变量：
  - capacity：最大容量
  - position：当前读写处的下标位置
  - limit：还可读写的下标位置
Selector：NIO采用的Reactor模型，一个线程使用一个Selector通过轮询的方式去监听多个Channel上面的事件，将Channel配置为非阻塞，那么Selector检测到当前Channel没有IO事件，就会轮询其他Channel。

内存映射文件：是一种读写文件的方式，比常规基于流或者Channel的IO快。

//将文件的前1024字节映射到内存中，map()方法返回一个MappedByteBuffer
MappedByteBuffer mbb = fc.map(FileChannel.MapMode.READ_WRITE, 0, 1024);

Demo

public class SimpleServer {
    public static void main(String[] args) {
        /**
         * ServerBootstrap：服务端启动器，负责组装、协调netty组件
         * NioEventLoopGroup：thread + selector
         * NioServerSocketChannel：对原生NIO的ServerSocketChannel封装
         * ChannelInitializer：对channel进行初始化
         */
        new ServerBootstrap()
                .group(new NioEventLoopGroup())
                .channel(NioServerSocketChannel.class)
                .childHandler(new ChannelInitializer<NioSocketChannel>() {
                    //连接建立后执行initChannel
                    @Override
                    protected void initChannel(NioSocketChannel ch) throws Exception {
                        //StringDecoder：将Bytebuffer转为string
                        ch.pipeline().addLast(new StringDecoder());
                        //自定义handler
                        ch.pipeline().addLast(new ChannelInboundHandlerAdapter() {
                            @Override
                            public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {
                                System.out.println(msg);
                            }
                        });
                    }
                })
                .bind(8080);
    }
}

public class SimpleClient {
    public static void main(String[] args) throws IOException, InterruptedException {
        new Bootstrap()
                .group(new NioEventLoopGroup())
                .channel(NioSocketChannel.class)
                .handler(new ChannelInitializer<NioSocketChannel>() {
                    @Override
                    protected void initChannel(NioSocketChannel ch) throws Exception {
                        ch.pipeline().addLast(new StringEncoder());
                    }
                })
                .connect(new InetSocketAddress("localhost", 8080))
                //阻塞直到连接建立
                .sync()
                //代表连接对象
                .channel()
                //发送数据
                .writeAndFlush("hello world");
    }
}

Netty组件

Core：提供了底层网络通信的抽象和实现，支持零拷贝的ByteBuffer、可扩展的事件模型、通信API。
协议支持层：对主流协议的编解码实现，包括：HTTP、SSL、Protobuf等，还支持自定义应用层协议。
传输服务层：提供了网络传输能力的抽象和实现，支持Socket、HTTP tunnel、VM pipe等方式

Linux文件管理模块分析

Sat, 23 Jul 2022 09:52:49 +0000

硬盘文件系统

inode与块的存储

硬盘读写时以扇区为单位，文件系统中读写数据最小单位为块，一个块（簇）内部是相邻的几个扇区，在Linux中的ext文件系统，默认大小为4K。

文件的元数据存放在inode中，ext4中定义如下：

struct ext4_inode {
	__le16	i_mode;		/* File mode */
	__le16	i_uid;		/* Low 16 bits of Owner Uid */
	__le32	i_size_lo;	/* Size in bytes */
	__le32	i_atime;	/* Access time */
	__le32	i_ctime;	/* Inode Change time */
	__le32	i_mtime;	/* Modification time */
	__le32	i_dtime;	/* Deletion Time */
	__le16	i_gid;		/* Low 16 bits of Group Id */
	__le16	i_links_count;	/* Links count */
	__le32	i_blocks_lo;	/* Blocks count */
	__le32	i_flags;	/* File flags */
......
	__le32	i_block[EXT4_N_BLOCKS];/* Pointers to blocks */
	__le32	i_generation;	/* File version (for NFS) */
	__le32	i_file_acl_lo;	/* File ACL */
	__le32	i_size_high;
......
};


#define	EXT4_NDIR_BLOCKS		12
#define	EXT4_IND_BLOCK			EXT4_NDIR_BLOCKS
#define	EXT4_DIND_BLOCK			(EXT4_IND_BLOCK + 1)
#define	EXT4_TIND_BLOCK			(EXT4_DIND_BLOCK + 1)
#define	EXT4_N_BLOCKS			(EXT4_TIND_BLOCK + 1)

i_block中存放文件所在的磁盘块地址，可以通过多层寻址增加文件大小上限。

Linux内存管理模块分析

Sun, 17 Jul 2022 09:52:49 +0000

概述

内存管理主要分为三个方面：

管理物理内存：只有内核中负责内存管理的模块可以使用
管理虚拟内存：每个进程看到的都是独立且互不干扰的虚拟空间
物理内存和虚拟内存的转换：上述两者的映射关系

无论是内核态程序还是用户态程序，都使用虚拟内存，虚拟内存空间布局如下：

内核空间部分：存放内核进程的程序
用户空间部分：存放用户进程的程序，从最低位开始，逐个段如下：
- Text Segment：存放二进制可执行代码的位置
- Data Segment：存放静态常量
- BSS Segment：存放未初始化的静态变量
- Heap：动态分配内存的区域，malloc在这个空间分配
- Memory Mapping Segment：用来把文件映射到内存的区域，如果可执行文件依赖某个动态链接库，so文件就映射在这。
- Stack：进程的函数调用栈，由一个个frame（相当于函数实体）构成，内部存放局部变量、返回地址等信息，frame结构如下图所示：

可以通过pmap pid展示进程的地址空间相关信息。

基本概念

分段机制

分段机制如下图所示：

在Linux中，段表被称为段描述符表，放在全局描述符表 GDT中，一个段表项由段基址base，界限limit，还有一些标识符组成：

DEFINE_PER_CPU_PAGE_ALIGNED(struct gdt_page, gdt_page) = { .gdt = {
#ifdef CONFIG_X86_64
	[GDT_ENTRY_KERNEL32_CS]		= GDT_ENTRY_INIT(0xc09b, 0, 0xfffff),
	[GDT_ENTRY_KERNEL_CS]		= GDT_ENTRY_INIT(0xa09b, 0, 0xfffff),
	[GDT_ENTRY_KERNEL_DS]		= GDT_ENTRY_INIT(0xc093, 0, 0xfffff),
	[GDT_ENTRY_DEFAULT_USER32_CS]	= GDT_ENTRY_INIT(0xc0fb, 0, 0xfffff),
	[GDT_ENTRY_DEFAULT_USER_DS]	= GDT_ENTRY_INIT(0xc0f3, 0, 0xfffff),
	[GDT_ENTRY_DEFAULT_USER_CS]	= GDT_ENTRY_INIT(0xa0fb, 0, 0xfffff),
#else
	[GDT_ENTRY_KERNEL_CS]		= GDT_ENTRY_INIT(0xc09a, 0, 0xfffff),
	[GDT_ENTRY_KERNEL_DS]		= GDT_ENTRY_INIT(0xc092, 0, 0xfffff),
	[GDT_ENTRY_DEFAULT_USER_CS]	= GDT_ENTRY_INIT(0xc0fa, 0, 0xfffff),
	[GDT_ENTRY_DEFAULT_USER_DS]	= GDT_ENTRY_INIT(0xc0f2, 0, 0xfffff),
......
#endif
} };
EXPORT_PER_CPU_SYMBOL_GPL(gdt_page);

#define __KERNEL_CS			(GDT_ENTRY_KERNEL_CS*8)
#define __KERNEL_DS			(GDT_ENTRY_KERNEL_DS*8)
#define __USER_DS			(GDT_ENTRY_DEFAULT_USER_DS*8 + 3)
#define __USER_CS			(GDT_ENTRY_DEFAULT_USER_CS*8 + 3)

分段机制在Linux中，可以做权限审核，用户态试图访问内核态，权限不足会禁止访问。

Linux进程管理模块分析

Thu, 14 Jul 2022 23:31:46 +0000

二进制程序执行

编译过程

源代码文件会经过以下的步骤生成可执行文件（CSAPP）：

预处理：预处理过程会将头文件嵌入代码中，定义宏展开，生成.i文件
编译：编译生成汇编语言程序,生成.s文件
汇编：汇编器as将汇编语言翻译成机器指令，打包成.o文件，这被称为Relocatable File
链接：链接器ld将链接库和重定位文件合并，生成可执行文件

编译

process.c内容如下：

#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <unistd.h>
 
 
extern int create_process (char* program, char** arg_list);
 
 
int create_process (char* program, char** arg_list)
{
    pid_t child_pid;
    child_pid = fork ();
    if (child_pid != 0)
        return child_pid;
    else {
        execvp (program, arg_list);
        abort ();
    }

createprocess.c内容如下：

#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <unistd.h>
 
extern int create_process (char* program, char** arg_list);
 
int main ()
{
    char* arg_list[] = {
        "ls",
        "-l",
        "/opt/",
        NULL
    };
    create_process ("ls", arg_list);
    return 0;
}

编译上面两个文件，生成.o文件

短网址系统设计总结

Sun, 10 Jul 2022 14:29:01 +0000

需求评估

输入数据：一个长网址、过期时间和一个自定义的别名
输出数据：自定义别名或者随机生成的短网址，过期时间之前访问都会被重定向到原始地址。
读多写少

实现原理：将短网址redirect到长网址（301/302跳转）

约束：

过期即失效
短网址唯一
支持自定义短网址
QPS要求、低延迟、可靠性、安全性

系统设计

可行解

写
1. 输入长域名，判断是否存在
2. 生成一个未使用的短网址，并进行持久化
读
1. 获取短网址，判断是否过期
2. 正常则返回短网址

其他方面：

使用延迟删除策略清理过期数据
读时消重：返回的时候过滤重复元素
写时消重：写时判断以避免重复写入
短网址生成算法：
- UUID：无法保证唯一性
- 哈希：MurMurHash等方法，无法保证唯一性，考虑转为62进制
- ID：使用7位62进制，即长度为7，由大小写字母加数字共62个字符组成
- 雪花算法：转为62进制
用户自定义：记录正在使用的ID，写入时判断是否存在

MySQL表结构如下：

id	long_url	short_url	expire_time	create_time	delete_time

Redis键值设计：

k：长网址, v：短网址

吞吐量优化

水平扩展：使用Nginx做负载均衡
存储层：MySQL替换为持久化KV存储，比如RocksDB，若存在数据分析的需求，可以添加数仓
索引优化：两个方面
1. 写入时判需要判断长网址是否存在
2. 读取时根据短网址查询长网址
分片：短网址进行一致性哈希等方式计算分片位置。
缓存层：读多写少的系统使用缓存优化QPS
- 使用bloom filter检查长网址是否存储，短网址是否分配
- 直接在本地设计缓存
业务层
- 分布式ID生成需要考虑数据一致性问题
网络层：降低广域延迟

可靠性优化

存储层：考虑主从副本机制，增加数据可靠性
提供跨机房的数据冗余备份，通过log同步数据
监控业务集群，实现熔断、限流、扩容缩容等

安全性优化

避免使用自增，防止逐个遍历
防止DDos，对接口做限流，增加IP黑名单机制

Kafka学习笔记(四)-集群工作机制

Wed, 06 Jul 2022 18:49:22 +0000

Controller机制

Controller主要作用是在Zookeeper的帮助下管理和协调整个Kafka集群（在zk中存储集群元数据）。Kafka集群中会有一个或多个Broker，其中一个Broker会被选举为Controller，它负责管理整个集群中所有分区和副本的状态，其工作职责包括以下内容：

Topic管理：完成对Kafka的Topic的创建删除、分区增加等操作。
分区重分配：新的Broker加入集群时，不会自动分担已有的topic负载，只会对后续的topic生效，此时如果需要对已有topic负载，需要用户手动进行分区重分配。
Leader选举：负责Partition Leader选举的工作
集群成员管理：
- Kafka 使用Zookeeper的临时节点来选举Controller
- Zookeeper在Broker加入集群或退出集群时通知Controller
- Controller负责在Broker加入或离开集群时进行分区Leader选举
元数据管理：Controller负责管理集群中所有的元数据

Controller选举流程：

每个Broker启动时，都会尝试读取/controller节点的brokerid的值，如果值不为-1，则表明已经有其他broker节点成为Controller，当前broker放弃选举
如果不存在/controller节点或节点数据异常，则主动创建节点并存储brokerid
其他broker会将选举成功的Brokerid都在内存保存下来
同时使用/controller_epoch持久性节点来记录任期号，记录Controller发生变化的次数，类似于Raft中的任期。
- 初始值为1，每个与Controller交互的请求都会携带controller_epoch，如果请求的controller_epoch大于内存中controller_epoch，说明内存中的值过期了，目前已有新的Controller当选。
- 由两部分组成：
  - epoch：单调递增的版本号，leader发生变更，进行自增
  - start offset：Leader副本在该Epoch值上写入的首条消息的位移。
- 每个分区都缓存该值，并定期持久化到checkpoint文件中

Partition Leader选举

Controller拥有选举分区Leader的功能，每个分区都会有一个Broker作为Leader，处理所有的读写请求，选举流程由Controller负责：

Controller从ZK中读取当前分区所有的ISR集合
调用配置的分区选择算法选举分区的Leader

Partition Leader的定义如下：

Each partition has one server which acts as the “leader” and zero or more servers which act as “followers”. The leader handles all read and write requests for the partition while the followers passively replicate the leader. If the leader fails, one of the followers will automatically become the new leader. Each server acts as a leader for some of its partitions and a follower for others so load is well balanced within the cluster.

Kafka学习笔记(三)-通信协议

Sun, 03 Jul 2022 10:49:22 +0000

协议设计

需要进行网络传输的中间件都会拥有自己的一套通信协议，这往往会成为该组件的性能瓶颈，需要考虑的优化点较多。Kafka自定义了基于TCP的二进制通信协议，Kafka2.0中，一共有43种协议类型，每个都有对应的请求和响应，与HTTP协议类似，它同样有RequestHeader和RequestBody。其中RequestHeader结构如下：

api_key：API标识，例如PRODUCE、FETCH等，用于分别请求的作用。
api_version：API版本号
correlation_id：客户端指定的唯一标识，服务端返回响应需要将该字段返回以此对应。
client_id：客户端id

Kafka除了提供基本数据类型，还提供了以下的特有类型：

nullable_string：可为空的字符串类型，若为空用-1表示
bytes：表示字节序列，开头是数据长度N（int32表示），后面是N个字节
nullable_bytes：与上述string相同
records：表示Kafka中的消息序列
array：表示一个给定类型T的数组

RequestBody结构如下：

transactional_id：事务id，不使用事务，此项为null
acks：对应客户端的acks参数
timeout：超时时间
topic_data：要发送的数据集合，array类型
- topic：主题
- data：数据，array类型
  - partition：分区编号
  - record_set：数据

Response结构如下：

ResponseHeader
- correlation_id：与请求相对应
ResponseBody
- responses：array类型，返回的响应结果
  - topic：主题
  - partition_responses：返回结果，array类型
    - partition：分区编号
    - error_code：错误码，用来标识错误类型
    - base_offset：消息集的起始偏移量
    - log_append_time：消息写入broker的时间
    - log_start_offset：所在分区起始偏移量

分析Linux中的Zero-Copy技术

Thu, 30 Jun 2022 20:33:10 +0000

传统IO的流程

零拷贝技术是对传统IO的性能优化，在介绍零拷贝之前，先简单了解一下传统IO中，数据流向的过程：

用户进程发起read()调用，从用户态切换至内核态，DMA从文件中读取数据，并存储在IO Buffer（内核态）
请求得到的数据从IO Buffer拷贝到用户态Buffer（从内核态切换到用户态），然后返回给用户进程。
用户进程调用write()将数据输出到网卡中，此时将从用户态切换到内核态，请求数据从用户进程空间拷贝到Socket Buffer。
write()调用结束后返回用户进程，此时从内核态切换到用户态。

整个过程中涉及4次上下文切换、4次数据拷贝（2次CPU拷贝 + 2次DMA拷贝）。

我们需要对该流程进行优化，以提高IO的性能，因此诞生了零拷贝的概念。

零拷贝

“Zero-copy” describes computer operations in which the CPU does not perform the task of copying data from one memory area to another or in which unnecessary data copies are avoided. This is frequently used to save CPU cycles and memory bandwidth in many time consuming tasks, such as when transmitting a file at high speed over a network, etc., thus improving performances of programs (processes) executed by a computer.

Kafka学习笔记(二)-存储架构

Wed, 29 Jun 2022 20:06:22 +0000

Kafka存储架构

Kafka是为了解决大数据量的实时日志流而产生的，日志流主要特点包括：

数据实时存储
海量数据存储与处理

Kafka需要保证以下几点：

存储的主要是消息流
要保证海量数据的高效存储
要支持海量数据的高效检索
要保证数据的安全性和稳定性

Kafka使用的存储方案是：磁盘顺序写 + 稀疏哈希索引。

日志目录布局

Kafka中消息以Topic为单位归类，各个Topic下面分为多个分区，分区中每条消息都会被分配一个唯一的序列号（offset）。日志命名方式为：<topic>-<partition>

在不考虑多副本的情况下，一个分区对应一个Log，为了防止Log过大，Kafka引入LogSegment，将Log切分为多个LogSegment。其结构如下所示：

Log
- LogSegment：每个 LogSegment 都有一个基准偏移量 baseOffset，用来表示当前 LogSegment中第一条消息的offset。只有最后一个LogSegment才能写入。下述文件根据baseOffset命名，长度固定为20位数字，没有达到的位数用0填充。
  - .log：日志文件
  - .index：偏移量索引文件
  - .timeindex：时间戳索引文件
  - .snapshot：快照索引文件

消息格式

消息格式关系到存储性能，比如冗余字段会增加分区的存储空间、网络传输的开销较大。

Kafka3.0中将BatchRecords作为磁盘中的存储单元，一个BatchRecords中包含多个Record。

BatchRecords的格式如下：

baseOffset: int64
batchLength: int32
partitionLeaderEpoch: int32
magic: int8 (current magic value is 2)
crc: int32
attributes: int16
    bit 0~2:
        0: no compression
        1: gzip
        2: snappy
        3: lz4
        4: zstd
    bit 3: timestampType
    bit 4: isTransactional (0 means not transactional)
    bit 5: isControlBatch (0 means not a control batch)
    bit 6: hasDeleteHorizonMs (0 means baseTimestamp is not set as the delete horizon for compaction)
    bit 7~15: unused
lastOffsetDelta: int32
baseTimestamp: int64
maxTimestamp: int64
producerId: int64
producerEpoch: int16
baseSequence: int32
records: [Record]

字段解释如下：

小记-构建RPM包

Mon, 27 Jun 2022 18:38:46 +0000

准备工作

OS环境与rpm版本号如下：

[root@localhost ~]# uname -a
Linux localhost.localdomain 3.10.0-693.el7.x86_64 #1 SMP Tue Aug 22 21:09:27 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

[root@localhost ~]# rpm --version
RPM 版本 4.11.3

安装rpm-build

yum install -y rpm-build	# 构建的rpm的核心组件
yum install -y rpmdevtools  # 提供了构建rpm包的一些工具

查看工作目录：

[root@localhost rpmbuild]# rpmbuild --showrc | grep topdir
-14: _builddir	%{_topdir}/BUILD
-14: _buildrootdir	%{_topdir}/BUILDROOT
-14: _rpmdir	%{_topdir}/RPMS
-14: _sourcedir	%{_topdir}/SOURCES
-14: _specdir	%{_topdir}/SPECS
-14: _srcrpmdir	%{_topdir}/SRPMS
-14: _topdir	%{getenv:HOME}/rpmbuild

工作目录位于$HOME/rpmbuild，在该目录下创建以下文件夹、或直接使用rpmdev-setuptree生成目录：

[root@localhost rpmbuild]# mkdir -pv /root/rpmbuild/{BUILD,BUILDROOT,RPMS,SOURCES,SPECS,SRPMS}

目录的各个用途如下：

使用Prometheus + Grafana 构建监控可视化系统

Sat, 11 Jun 2022 13:02:34 +0000

监控系统简介

业务监控系统通常包含以下一些组件：

采集：信息源来自log、metrics等。
- 可以通过定期外围探测、AOP手动织入、字节码自动织入
上报：通过http或者tcp
聚合
存储
可视化、告警

业务监控系统解决了什么问题？

趋势分析：收集长期监控数据，对监控指标进行趋势分析，例如：分析磁盘空间增长率，预测何时进行磁盘扩容。
对照分析：分析不同版本在运行时资源使用情况差异。
告警：当服务出现故障时，监控可以迅速反应并告警。
故障分析与定位：故障发生时，可以通过分析历史数据去定位问题。
数据可视化：通过采集的数据，生成可视化仪表盘。
对于运维：监控CPU、内存、硬盘等使用情况。
对于研发：监控某个异常指标的变化情况，来保证业务的稳定性。
对于产品或运营：关注产品层面：某个活动参加人数的增长情况等

监控系统分为以下五层：

端监控：对网站、APP、小程序等进行端监控，采集页面打开速度、稳定性、外部服务调用成功率等参数。
业务层监控：对业务模块进行监控，采集QPS、DAU、业务接口访问数量等。
应用层监控：对分布式应用进行管理和监控
中间件监控：对中间件进行监控，主要判断组件是否存活。
系统层监控：对操作系统监控，主要包括：CPU、磁盘I/O、网络连接等参数。

Prometheus简介

当前监控系统主要有集中式日志解决方案（ELK）和时序数据库解决方案。监控三要素如下：

Metrics：可聚合，带有时间戳的数据。
Logging：离散日志，分为有结构和无结构。
Tracing：请求域内的调用链。

Prometheus架构

Prometheus的架构图如下所示：

其中各组件功能如下：

Prometheus Server：核心部分，负责实现对监控数据的获取，存储以及查询。
- Retrieval：定时去配置文件中指定target抓取指标数据。（Pull）
- TSDB：Prometheus内置了时序数据库，存储抓取的指标数据。
- HTTP Server：提供了HTTP接口进行操作。
Jobs/exporters：exporter将监控数据通过HTTP服务的形式暴露给Prometheus Server，其定时进行Pull。
Pushgateway：临时性的Job可以将监控数据push到这，Prometheus从Pushgateway拉取数据。
AlertManager：告警处理中心。Prometheus支持基于PromQL创建告警规则。
Data Visualization：数据可视化，其中Prometheus自带的web UI可以通过PromQL进行查询，通过Grafana可以展示丰富的图表数据。

从上述组件可以看出：Prometheus提供了收集数据->存储数据->处理数据->展示数据这一系列功能，完全适用上述的应用场景。

获取监控数据的两种方式

Pull：从监控的target通过轮询获取监控信息。主要是HTTP API。
- 告警可以按照策略分片，可以做到数据的冷热分离。

主要流程如下：

Prometheus根据配置定期去targets拉取数据。
当拉取数据大于配置的内存缓冲区时，Prometheus会将数据持久化到磁盘或云端。
Prometheus通过PromQL、API等方式获取数据，同时可以配置rules，当触发条件时，将alert推送到配置的alertmanager。
alertmanager收到告警时，会执行相应的策略。

Push：程序主动将数据推送到监控系统中，Prometheus采用gateway实现该方式。
- 实时性好
- 由于推送时机的不可预知性，监控系统无法掌握主动性，可能会导致对监控进程产生影响。
- 增加gateway组件，增加了系统的复杂度。

优缺点

优点：

Golang编写，支持云原生，二进制文件直接启动，也支持容器化部署。
支持多种语言的客户端。
支持本地存储和云端存储，单机性能强。
可扩展，使用联邦集群启动多个Prometheus实例来分布式处理。
支持静态文件配置和动态发现等机制。

缺点：

不适用Logging、Tracing等监控。
Prometheus数据默认保留15天，适用于追踪近期数据。
本地存储有限，需要考虑第三方存储。
联邦集群没有提供统一的全局视图。

Grafana简介

Grafana是一个可以通过各种图形方式对数据进行可视化的一个开源软件，官网简介如下：

Kafka学习笔记(一)-基础入门

Fri, 06 May 2022 15:08:22 +0000

简介

Kafka是由LinkedIn使用Scala语言开发的分布式消息引擎系统，目前已被捐献给Apache基金会，它以高吞吐量、可持久化、流数据处理等特性而被广泛使用。它主要有以下三种主要功能：

消息中间件：具备常见的消息队列功能：系统解耦、冗余存储、流量削峰填谷、缓冲、异步通信，同时具备消息顺序性保障、回溯消费等功能。
数据存储系统：使用Kafka存储各种服务的log，然后统一输出，ELK可使用Kafka进行数据中转。
流数据处理平台：与flink、spark、storm等组件整合，提供实时计算。

Kafka支持两种常见消息传输模型：

点对点模型：也称为消息队列模型，系统A发送的消息只能被系统B接收，其它系统读取不到。
发布/订阅模型：使用Topic接收消息，Publisher和Subscriber都可以有多个，可以同时向Topic发送接收消息。

基本概念

Kafka体系结构：一个Kafka集群包括若干Producer、Customer、Broker，以及一个Zookeeper集群。
- Broker：服务端由被称为Broker的服务进程构成，Broker负责接受和处理客户端请求，以及对消息进行持久化。
  - 可以简单看作为一个独立的Kafka服务节点（进程示例）
  - Broker层面的领导者被称为Controller
- Producer：客户端节点，发送消息的一方。
- Customer：客户端节点，接收消息的一方。
- Customer Group：消费者组内每个消费者负责消费不同分区的数据。一个分区只能由组内一个消费者消费，不同消费组之间互不影响。
- ~~Zookeeper集群：负责元数据管理，集群选举。~~目前最新版3.1.0提供了KRaft模式，集群不再依赖ZK。
  - ZK主要负责存储Kafka集群的元数据，协调集群工作。
  - 记录信息如下：
    - 1. /brokers/ids/{0-n}：记录broker服务器节点，不同的broker使用不同的brokerid，会将自己的ip地址和端口信息记录到节点
    - 1. /brokers/topics/{topic}：记录topic分区以及broker的对应信息
    - 1. /comsumers/{group_id}/ids/{consumer_id}：消费者负载均衡
Topic：逻辑概念，Kafka中消息以topic为单位进行分类，生产者将消息发送到特定的topic，消费者订阅topic进行消费。

分区（partition）

Partition：topic可以分为多个partition，分区在物理存储层面可以看作一个可Append的Log文件，消息被Append到Log中会分配一个offset，这个属性是消息的唯一标识，Kafka通过它来保证消息在分区内的顺序性，因此Kafka保证分区有序而不是主题有序。
- 主题中的partition可以分布在不同的Broker中。
- 消息到达broker后，根据分区规则存储到指定的partition。

多副本机制（Replica）

多副本机制（Replica）：是对于分区而言的，同一分区的不同副本中保存的是相同的消息。
- Leader：分区中的主副本，负责处理读写请求，Producer/Consumer交互的对象。
- Follower：分区中的从副本，只会实时从Leader副本同步数据。
- 所有副本被称为AR（Assigned Replicas），所有与Leader副本数据一致性差距过多的副本组成OSR（Out-of-Sync Replicas），于leader保持一定程度同步的副本称为ISR（In-Sync Replicas）。
- Leader故障后，从ISR中选举新的Leader。
- 高水位（HW-High Watermark）：消费者能消费的最大offset位置，相当于所有副本中都存在的消息（木桶效应）
- LEO（Log End Offset）：标识当前日志文件中下一条待写入消息的offset，每个副本都会维护自身的LEO，ISR中最小的LEO即为分区的HW。

多副本的作用：提高Kafka的可用性。

涉及参数：

unclean.leader.election.enable：为true则ISR为空也能选举，为false则只能从ISR选举。

metadata

Q：客户端如何知道请求哪个broker？

client通过metadata从任意broker获取集群信息，其中包括：

topic信息
每个topic的分区、副本情况
leader分区所在的broker连接信息
每个broker的连接信息
其他信息

部署

使用WSL 2环境进行单机部署。

zero@Pluto:~$ uname -a
Linux Pluto 4.19.128-microsoft-standard #1 SMP Tue Jun 23 12:58:10 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Kafka需要Java环境，由于Kafka最新版本3.1.0不再支持Java8，故使用Java11。

Zookeeper论文阅读笔记

Fri, 22 Apr 2022 21:57:47 +0000

摘要

Zookeeper是一个带有事件驱动的分布式系统缓存，提供了强大的分布式协调能力，结合了组播消息、分布式锁等内容。

Zookeeper提供了高性能服务，保证了对客户端请求FIFO顺序执行和线性化写，在给出了在2:1到100:1的读/写比率下，ZooKeeper 每秒可以处理数万到数十万个事务。

1.简介

分布式系统需要不同形式的协调程序，配置是协调的最基本形式。

Zookeeper的API设计，移除了锁等阻塞原语来提高性能，使用wait-free的数据结构来实现对应的功能。

注：wait-free：他保证任何线程都能在有限的过程内执行完成。

Zookeeper可以用集群模式中的副本来实现高可用性和高性能，是西安了基于领导者的原子广播协议（ZAB：Zookeeper Atomic Broadcast），Zookeeper应用的主要负载是读操作，所以需要保证读吞吐量的可扩展。

Zookeeper使用watch机制使得客户端不需要直接管理客户端缓存，对于一个给定的数据对象，客户端可以监视到更新动作，当有更新的时候收到通知消息。而Chubby 直接操作客户端缓存，会阻塞更新直到所有的客户端缓存都被改变。如果任何客户端速度较慢或者故障，更新都会延迟。

本文主要讨论ZooKeeper的设计和实现，包括：

协调内核：提出了一种可用于分布式系统的无等待、具有宽松的一致性保证的协调服务。
协调示例
协调相关的思路

2.Zookeeper服务

2.1 概述

Zookeeper将客户端抽象为znodes，并将其构造为树形结构，客户端可以创建两种znode：

普通：client通过创建和删除显式操作普通节点。
临时：创建后可以显式删除或者系统在会话结束后自动删除。

watch机制使得客户端无须轮询就可以接收到状态变换的通知信息。与一个会话关联的 watches 只会触发一次；一旦触发或者会话结束，就会被注销。

设计znode不是用来保存通用数据，而是用来映射客户端应用的抽象，主要是对于协调用途的元数据。

2.2 客户端API

create(path, data, flags)：使用 path 名称创建一个 znode 节点，保存 data，返回新创建的 znode 名称。 flags 用于创建普通或者临时节点，也可以设置顺序标识。
delete(path, version)：删除指定 path 和 version 的 znode 节点。
exists(path, watch)：如果指定 path 的 znode 存在则返回真，如果不存在则返回假。watch 标识用于在 znode 上设置监视器。
getData(path, watch)：返回数据和元数据，如版本信息。watch 标识与 exists() 的 watch 标识一样，但如果 znode 不存在则不会设置监视器。
setData(path, data, version)：根据 path 和 version 将数据写入到 znode。
getChildren(path, watch)：返回 znode 所有子节点的名称集合。
sync(path)：在操作开始时，等待所有挂起的更新操作发送到客户端连接的服务器。path 当前未使用。

所有API都提供同步异步两个版本，无论同步异步，都会保证执行顺序按照FIFO进行。

Zookeeper入门教程

Mon, 11 Apr 2022 15:26:27 +0000

简介

Zookeeper为分布式系统提供了高效可靠的分布式协调服务，其本质是一个键值存储系统，提供了诸如命名服务、配置管理、分布式锁等服务。其采用ZAB协议对集群数据的一致性进行管理。

它负责存储和管理一些数据，然后接受观察者的注册，一旦数据状态发生变化，Zookeeper负责通知观察者做出相应的反应。

几个特点：

一个Leader，多个Follow组成的集群。
半数以上节点存活，集群即可正常服务，适合部署奇数台节点。
全局数据一致，每个节点都保存相同的数据副本。
所有客户端看到的数据都是一致的，并且请求按照顺序执行（FIFO）
数据更新原子性。
更新删除操作都是基于事务的，是用于读多写少环境。

数据模型

Zookeeper的数据模型由一个树形结构构成，每个节点称为一个ZNode，由于设计目标是实现协调服务，而不是数据存储，故默认存储大小为1MB，每个ZNode可以通过其路径唯一标识。

运行

从官网下载Zookeeper的二进制发布版，解压后得到以下文件：

zero@Pluto:~/Zookeeper/apache-zookeeper-3.5.7-bin$ ls
LICENSE.txt  NOTICE.txt  README.md  README_packaging.txt  bin  conf  docs  lib

执行bin/zkServer.sh version，看到版本信息说明正常运行。

zero@Pluto:~/Zookeeper/apache-zookeeper-3.5.7-bin$ bin/zkServer.sh version
/usr/bin/java
ZooKeeper JMX enabled by default
Using config: /home/zero/Zookeeper/apache-zookeeper-3.5.7-bin/bin/../conf/zoo.cfg
Usage: bin/zkServer.sh [--config <conf-dir>] {start|start-foreground|stop|restart|status|print-cmd}

单机部署

创建一个zoo.cfg文件，内容如下：

tickTime=2000

initLimit=10

syncLimit=5

dataDir=/opt/Zookeeper-3.5.7/zkData

clientPort=2181

执行bin/zkServer.sh start启动服务器节点。

zero@Pluto:/opt/Zookeeper-3.5.7$ bin/zkServer.sh start
/usr/bin/java
ZooKeeper JMX enabled by default
Using config: /opt/Zookeeper-3.5.7/bin/../conf/zoo.cfg
Starting zookeeper ... STARTED

zero@Pluto:/opt/Zookeeper-3.5.7$ jps -l
3892 sun.tools.jps.Jps
3850 org.apache.zookeeper.server.quorum.QuorumPeerMain

执行bin/zkCli.sh启动客户端。

DDIA阅读笔记(一)-数据系统的基石

Sun, 03 Apr 2022 18:59:06 +0000

第一章：可靠性、可伸缩性、可维护性

应用的两个分类：

data-intensive：问题通常来自数据量、数据复杂性、以及数据的变更速度。
compute-intensive：瓶颈在于CPU。

可靠性

可以把可靠性粗略理解为 “即使出现问题，也能继续正确工作”。

造成错误的原因叫做 故障（fault），能预料并应对故障的系统特性可称为 容错（fault-tolerant） 或 韧性（resilient）。

fault种类：

硬件故障（hardware faults）
- 增加单个硬件的冗余度：磁盘可以组建RAID、服务器使用双路电源和热拔插CPU等。
- 云平台的设计就是优先考虑 **灵活性（flexibility）**和 弹性（elasticity），而不是单机可靠性。
- 引入软件容错机制。
系统性错误（systematic error）
- 软件错误
- 修复问题代码、进程隔离、监控分析
人为错误
- 以最小化犯错机会的方式设计系统：精心设计的API
- 与最容易犯错的模块解耦
- 彻底的测试：单元测试、系统测试
- 允许从人为错误中简单快速地恢复：快速回滚配置变更、分批发布新代码。
- 配置详细地监控，比如性能指标和错误率。

可伸缩性

可伸缩性（Scalability） 是用来描述系统应对负载增长能力的术语。

描述性能的指标：

吞吐量（throughput）：每秒可以处理的记录数量。或者在特定规模数据集上运行作业的总时间。
响应时间（response time）：客户端发送请求到接收响应之间的时间。
- 响应时间的高百分位点（尾部延迟）指标非常重要

处理方法：

垂直伸缩：转向更强大的机器。
水平伸缩：负载分布到多台小机器。

弹性（elastic）：在检测到负载增加时自动增加计算资源

可维护性

三个设计原则来避免自己的软件系统变为遗留系统：

可操作性
简单性
可演化性

可操作性

监控系统提供可见性
将系统与标准化工具集成
避免单机部署
提供良好的文档
提供良好的默认行为（配置参数？）
自我修复
行为可预测

简单性

消除额外复杂度的最好工具之一是抽象。

抽象帮助我们控制系统复杂度。

可演化性

系统的需求是变化的，使用敏捷工作模式来应对，例如TDD和重构。

第二章：数据模型与查询语言

问题：需要将数据模型抽象成对应的概念。

每个层都通过提供一个明确的数据模型来隐藏更低层次中的复杂性。

关系模型和文档模型

关系模型

常见分类：

TP（事务性）：银行交易
AP（分析型）：数据报表
HTAP（混合型）

问题：关系模型很难直观表达一对多的关系．

MySQL调优总结

Tue, 01 Mar 2022 12:23:36 +0000

前言

数据库调优的几个维度：

建立索引
SQL语句优化
服务器参数调优：包括缓冲区、线程数等
分库分表、集群模式

调优目标：

尽可能节省系统资源，以提高系统吞吐量。
合理的结构设计和参数调整，以提高用户操作响应的速度。
减少系统的瓶颈，提高MySQL整体性能。

如何定位调优问题：

用户反馈
日志分析
服务器资源监控

调优维度：

选择合适的DBMS
优化表设计
1. 遵循三范式的原则
2. 多表联查可以考虑反范式化
3. 表字段的数据类型选择
优化SQL查询（逻辑）
使用索引（物理）
使用缓存
库级优化
1. 读写分离
  1. 一主一从
  2. 双主双从
2. 数据分片：对数据库进行分库分表。

MySQL服务器优化

两个方面：

硬件优化
MySQL服务的参数优化

硬件调优

配置较大的内存，增加缓冲区容量，减少磁盘IO。
配置高速磁盘系统，减少磁盘IO的时间。
合理分布磁盘IO，将磁盘IO分布在多个设备上，减少竞争。
配置多处理器。

参数调优

通过优化MySQL可以提高资源利用率，从而提高MySQL服务器性能。

几个重要的参数：

innodb_buffer_pool_size：表和索引的缓存区大小。
key_buffer_size：索引缓冲区大小，所有线程共享，值太大也会导致OS频繁换页。
table_cache：同时打开的表的个数。
query_cache_size：查询缓冲区大小，与query_cache_type配合使用。
query_cache_type：0代表所有查询不使用查询缓冲区，1表示所有都使用，当查询语句指定SQL_NO_CACHE则不使用。
sort_buffer_size：每个需要进行排序的线程分配的缓冲区大小，增加这个参数的值可以提高ORDER BY或GROUP BY操作的速度。
join_buffer_size：每个需要联合查询的线程所使用的缓冲区大小。
read_buffer_size：每个线程连续扫描时为扫描的每个表分配的缓冲区的大小。
innodb_flush_log_at_trx_commit：**何时将redo log buffer的数据写入redo log file，并将日志文件写入磁盘中。**默认为1。
- 0：redo log buffer每隔一秒将其数据刷入page cache，该模式下事务提交不会触发刷盘操作。
- 1：每次事务提交都会将将redo log buffer中数据刷入page cache，并立刻刷入磁盘。效率较低也为安全。
- 2：每次事务提交都会将redo log buffer中数据刷入page cache，由OS同步到磁盘。（每秒一次）
  - mysql进程崩溃不会有数据丢失，当时OS宕机会有数据丢失。
innodb_log_buffer_size：InnoDB存储引擎的事务日志缓冲区，为了提升性能，也是先将信息写入 Innodb Log Buffer 中，当满足 innodb_flush_log_trx_commit 参数所设置的相应条件（或者日志缓冲区写满）之后，才会将日志写到文件（或者同步到磁盘）中。
max_connections：允许连接到MySQL数据库的最大数量。如果connection_errors_max_connections不为0，并且一直增长，说明不断有连接因为数据库连接数已到最大值而失败，此时考虑增大max_connections的值。
back_log：用于控制MySQL监听TCP端口时设置的积压请求栈大小。 连接数达到max_connections，新来的请求将会被存在堆栈中，以等待某一连接释放资源，如果等待连接的数量超过back_log，将会报错。
thread_cache_size：线程池缓存线程数量的大小，当客户端断开连接后将当前线程缓存起来，当在接到新的连接请求时快速响应无需创建新的线程。这对于短链接的应用程序十分有用。
wait_timeout：一个连接的最大连接时间。
interactive_timeout：服务器在关闭连接前等待行动的秒数。

优化数据库结构

几个策略：

网络IO模型总结

Tue, 22 Feb 2022 10:44:13 +0000

网络IO流程

网络IO中的一次请求和响应的流程基本如下：

内核通过网卡读取客户端的请求数据，将数据读取到内核缓冲区。数据从网卡到内核空间；
从内核缓冲区读取数据到应用进程缓冲区。数据从内核空间到用户空间；
服务端进程在自己的用户空间中，处理客户端的请求。数据在用户空间中被处理；
处理完数据并构建好的响应之后，将数据从用户缓冲区写入内核缓冲区。
内核将内核缓冲区中的响应写入网卡，网卡通过底层的通讯协议，会将数据发送给目标客户端。

两组概念：

同步：请求被逐个地处理，无法并发执行。
异步：多个请求可以并发执行，内核IO操作完成后会通知用户线程，或者调用用户进程的回调函数。
阻塞：请求发出后，由于该请求操作需要的条件不满足，请求操作一直阻塞，不会返回，直到条件满足。
非阻塞：请求发出后，若该请求需要的条件不满足，则立即返回一个标志信息告知条件不满足，而不会一直等待。一般需要通过循环判断请求条件是否满足来获取请求结果。

在《UNIX网络编程》中，将UNIX的IO模型分为了以下五种：

阻塞式IO
非阻塞式IO
IO多路复用
信号驱动式IO
异步IO

阻塞式IO

该模型中，用户空间的应用程序通过执行read调用（底层是recvfrom系统调用）来从socket中读取数据，在应用程序发起read调用后，会一直阻塞，直到数据包到达网卡上并复制到内核空间中，随后从内核空间拷贝到用户空间之后才会返回。

BIO在实现异步操作时，只能使用多线程进行处理，一个请求对应一个线程，该模型对于高并发环境，开销十分巨大，需要考虑其他的IO处理模型。

非阻塞式IO

应用程序发起系统调用，如果内核数据暂未准备好，进程可以做其他事，然后再次轮询内核获取请求结果。

简单的NIO需要不断的重复发起IO系统调用，这种不断地询问内核的操作，这将占用大量的 CPU 时间，并导致上下文切换，系统资源利用率较低。

IO多路复用

IO多路复用模型通过一个监听线程发起另一种形式的系统调用，由一个线程监听多个文件描述符（fd，linux系统把所有网络请求以一个fd来标识），一旦某个fd的操作就绪（一般是内核缓冲区可读/可写），该系统调用就会返回，随后监听线程可以通知程序对准备好了的fd进行对应的IO系统调用，比如通过recvfrom读取数据。

在Linux中select、poll、epoll函数就是IO多路复用的具体实现。Java4新增的NIO包中引入的选择器Selector，使用的就是IO多路复用模型，通过它，只需要一个线程便可以管理多个客户端连接。

信号驱动IO

应用程序通过sigaction系统调用安装一个信号处理函数，应用程序继续工作，当数据准备好后，内核给进程发送一个SIGIO信号，应用程序开始执行系统调用执行IO操作。

这种模型的优势在于等待数据达到期间，进程不被阻塞。只需要等待信号处理函数的通知。

异步IO

AIO的基本流程是：用户线程通过系统调用，告知内核启动某个IO操作，用户线程随即返回。内核在整个IO操作（包括数据准备、数据复制）完成后，会通知用户程序，用户执行后续的业务操作。

与信号驱动式IO的区别：信号驱动模型是由内核通知我们何时可以启动一个IO操作，而异步IO模型由内核通知我们IO操作何时完成。信号驱动IO更像半异步IO。

参考

《UNIX网络编程》

Raft论文阅读笔记

Mon, 31 Jan 2022 14:19:03 +0000

介绍

Paxos算法较为复杂，并且不易于应用到工业界，因此诞生了Raft算法，其首要目标是可理解性，Raft算法主要分解为几个部分：领导者选举、日志复制、安全性、成员变更等。Raft算法有一些独特的特性：

强领导者：日志entry只从领导者发送给其他服务器
领导者选举：Raft算法采用一个随即计时器来选举领导人
成员关系调整：Raft算法采用一种共同一致的方法来处理集群成员变换的问题，此时集群依然可以工作。

属性解释

状态

所有服务器上的持久性状态

(在响应 RPC 请求之前，已经更新到了稳定的存储设备)

参数	解释
currentTerm	服务器已知最新的任期（在服务器首次启动时初始化为0，单调递增）
votedFor	当前任期内收到选票的 candidateId，如果没有投给任何候选人则为空
log[]	日志条目；每个条目包含了用于状态机的命令，以及领导人接收到该条目时的任期（初始索引为1）

所有服务器上的易失性状态

参数	解释
commitIndex	已知已提交的最高的日志条目的索引（初始值为0，单调递增）
lastApplied	已经被应用到状态机的最高的日志条目的索引（初始值为0，单调递增）

领导人（服务器）上的易失性状态

(选举后已经重新初始化)

参数	解释
nextIndex[]	对于每一台服务器，发送到该服务器的下一个日志条目的索引（初始值为领导人最后的日志条目的索引+1）
matchIndex[]	对于每一台服务器，已知的已经复制到该服务器的最高日志条目的索引（初始值为0，单调递增）

追加条目（AppendEntries）RPC：

由leader调用，用于日志条目的复制，同时也被当做心跳使用

参数	解释
term	领导人的任期
leaderId	领导人 ID 因此跟随者可以对客户端进行重定向（译者注：跟随者根据领导人 ID 把客户端的请求重定向到领导人，比如有时客户端把请求发给了跟随者而不是领导人）
prevLogIndex	紧邻新日志条目之前的那个日志条目的索引
prevLogTerm	紧邻新日志条目之前的那个日志条目的任期
entries[]	需要被保存的日志条目（被当做心跳使用时，则日志条目内容为空；为了提高效率可能一次性发送多个）
leaderCommit	领导人的已知已提交的最高的日志条目的索引

返回值	解释
term	当前任期，对于领导人而言它会更新自己的任期
success	如果跟随者所含有的条目和 prevLogIndex 以及 prevLogTerm 匹配上了，则为 true

receiver的实现

如果term < currentTerm， return false
在接收者日志中如果能找到一个和 prevLogIndex 以及 prevLogTerm 一样的索引和任期的日志条目则继续执行下面的步骤否则return false
如果一个已经存在的条目和新条目发生了冲突，那么就删除这个已经存在的条目以及它之后的所有条目
追加的条目暂未存在日志中
如果leaderCommit > commitIndex，设置commitIndex = min(leaderCommit, index of last new entry)

请求投票（RequestVote）RPC：

由候选人负责调用用来征集选票（5.2 节）

Bitcask论文阅读笔记

Thu, 13 Jan 2022 17:45:04 +0000

简介

Bitcask是Riak分布式数据库使用的日志型存储模型，主要有以下几点特性：

读写低延迟
高吞吐量，尤其是随机写
能处理大量的数据集而不降低性能
故障时快速恢复且不丢失数据
易于备份和恢复
易于理解的代码结构和数据格式

结构

硬盘结构

在给定的一段时间内，只有一个active data file能提供append（写入）功能，当该文件大小达到指定阈值时，则会创建一个新的active data file。每一个写入到file的entry结构如下：

包括以下内容：

crc：校验值
tstamp：记录写入该数据的时间
ksz：key_size
value_sz：value_size
key：key
value：value

内存结构

在写入之后，一个被称为keydir（hash table）的内存结构将被更新，每一个键映射到固定大小的结构中，包括了以下内容：

file_id：去哪个文件查询
value_size：读取value多长的字节
value_position：value在文件中的位置

每一次写操作发生，keydir都会进行原子性的更新。

操作

read

读取value的过程：

查找keydir中的key，并读取file_id，position，size。
通过file_id找到对应的data file，再通过position和size字段找到entry中的value。

merge

由于删除操作并不会真正删除掉entry，只是将删除操作封装成entry写入文件，因此需要merge操作将所有的非active文件中entry遍历，并重组为一个新文件。同时生成一个hint file，用于存储data file的位置和大小。

Q：hint file的作用是什么？

A：每次进程重启时需要重建keydir，需要扫描所有的数据文件，因此使用hint file 加速构建keydir的速度。

Leetcode-Tree刷题记录

Fri, 02 Jul 2021 15:40:28 +0000

结构体定义

Leetcode中TreeNode结构体定义如下：

  struct TreeNode {
      int val;
      TreeNode *left;
      TreeNode *right;
      TreeNode() : val(0), left(nullptr), right(nullptr) {}
      TreeNode(int x) : val(x), left(nullptr), right(nullptr) {}
      TreeNode(int x, TreeNode *left, TreeNode *right) : val(x), left(left), right(right) {}
  };

二叉树的前序遍历

递归版本：

class Solution {
public:

    vector<int> res;
    vector<int> preorderTraversal(TreeNode* root) {
        if(!root) return res;
        res.push_back(root->val);
        preorderTraversal(root->left);
        preorderTraversal(root->right);
        return res;
    }
};

迭代版本：

class Solution {
public:

    vector<int> preorderTraversal(TreeNode* root) {
        vector<int> res;
        stack<TreeNode*> stack;
        if(root){
            stack.push(root);
        }
        while(!stack.empty()){
            TreeNode* curr = stack.top();
            stack.pop();
            res.push_back(curr->val);
            if(curr->right != nullptr){
                stack.push(curr->right);
            }
            if(curr->left != nullptr){
                stack.push(curr->left);
            }
        }
        return res;
    }
};

二叉树的中序遍历

递归版本：

Leetcode-字符串刷题记录

Thu, 18 Feb 2021 17:24:19 +0000

520. 检测大写字母

public boolean detectCapitalUse(String word) {
        int i = 0;
        char[] arr = word.toCharArray();
        int up = 0, low = 0;
        while(i < arr.length){
            if(arr[i] >= 'a'){
                low++;
            }else{
                up++;
            }
            i++;
        }
        if(up == arr.length) return true;
        if(low == arr.length) return true;
        if(up == 1 && arr[0] < 'a') return true;
        return false;
    }

125. 验证回文串

经典问题，需要过滤非字符非数字。

public boolean isPalindrome(String s) {
        if(s == null) return true;
        s = s.toLowerCase();
        StringBuilder str = new StringBuilder(s.length());
        for (char c : s.toCharArray()) {
            if ((c >= '0' && c <= '9') || (c >= 'a' && c <= 'z')) {
                str.append(c);
            }
        }
        return str.toString().equals(str.reverse().toString());
    }

14. 最长公共前缀

首先计算出最短字符串的长度，这个长度就是外层循环的遍历次数。
内层逐个比较字符串的指定位置的值。
通过StringBuilder拼接公共前缀。

public String longestCommonPrefix(String[] strs) {
        if(strs.length == 0) 
            return "";
        StringBuilder sb = new StringBuilder();
        int minLength = 1000;
        //计算最短字符串长度
        for(String str : strs){
            if(str.length() < minLength){
                minLength = str.length();
            }
        }
        String demo = strs[0];
        for(int i = 0; i< minLength; i++){
            boolean flag = true;
            char c = demo.charAt(i);
            for(int j = 1; j < strs.length; j++){
                if(strs[j].charAt(i) != c){
                    //不等于
                    flag = false;
                    break;
                }
            }
            if(flag){
                sb.append(c);
                flag = true;
            }else{
                break;
            }
        }
        return sb.toString();
    }

434. 字符串中的单词数

一轮遍历即可，判断依据是：当前值是空格，前一位非空格

分布式系统理论笔记

Sat, 23 Jan 2021 14:12:00 +0000

引言

分布式系统面临的问题：

数据一致性：数据均匀分布到多个存储节点，如何保证多个副本的数据一致性问题。
集群可用性：集群的服务是否可用。
分区容错性：当发生故障，集群如何快速恢复从而提供正常服务。

理论

拜占庭将军问题

存在恶意节点行为的场景中（数字货币的区块链技术中）：必须使用拜占庭容错算法（BFT）。常用的有PBFT算法、PoW算法。

计算机分布式系统中，最常用的是非拜占庭容错算法，即故障容错算法（CFT）。CFT解决的是分布式系统中存在故障，但不存在恶意节点的场景下的共识问题。这个场景可能会丢失信息、消息重复问题，但是不存在错误消息，或者伪造消息的情况。常见算法有Paxos算法、Raft算法、ZAB协议。

CAP理论

Q：如何设计分区容错一致性模型？

CAP三指标

一致性（Consistency）
- 强调的是数据在集群中的一致性。
- 客户端每次的读操作，无论访问哪个节点，要么读到同一份数据，要么读取失败。
可用性（Availability）
- 强调的是服务可用，但不保证数据的一致。
- 无论客户端访问哪个节点，都能得到响应数据，但是不保证数据是最新的。
分区容错性（Partition Tolerance）
- 强调的是集群对分区故障的容错能力。
- 节点出现任意数量的消息丢失或高延迟，系统仍然可以继续提供服务。

CAP不可能三角

对于一个分布式系统而言，一致性、可用性、分区容错性三个指标不可兼得，只能进行三选二。

如何使用CAP理论

节点之间的分区故障是必然发生的，因此分区容错性（P）是必须要保证的。那么只剩下两种选择：

CP：选择一致性（C）的时候，如果因为消息丢失、延迟过高发生了网络分区，部分节点无法保持一致，这时集群节点拒绝客户端的写操作。
AP：选择可用性（A）的时候，系统将始终处理客户端的查询，返回特定信息，如果发生了网络分区，一些节点无法返回最新特定信息。

ACID

单机上实现ACID可以通过锁、时间序列等机制保障操作的顺序执行。分布式系统的ACID实现需要掌握分布式事务协议，比如二阶段提交协议、TCC（Try-Confirm-Cancel）。

可以将ACID特性理解为CAP中一致性的边界（最强的一致性），但是大部分场景对一致性的要求不是特别高，如果不是必须，尽量不要实现事务，可以考虑采用强一致性或最终一致性。

二阶段提交协议

用于保证多个节点操作的原子性，也就是：要么多个节点的操作全部执行成功，要么全部失败。

节点分为：

协调者
参与者

执行过程如下：

提交请求阶段（投票阶段）
- 每一个参与者投票表决事务是放弃还是提交，一旦参与者投票要求提交事务，那么不允许中途放弃事务，这个特性需要代码实现时保障的。
提交执行阶段（完成阶段）
- 事务的每个参与者执行最终统一的决定，提交事务或者放弃事务，这个约定是为了实现ACID中的原子性。

存在的问题：

提交请求阶段，需要预留资源，在资源预留时期，其他人不能操作。
数据库是独立的系统。无法动态调整锁的粒度，并发性能下降。

TCC（Try-Confirm-Cancel）

Try（预留）：预留相关资源
Confirm（确认）：确认操作，完成分布式事务。
Cancel（撤销）：如果无法操作，则进行撤销操作。

TCC本质上是补偿事务，核心思想是针对每个操作都要注册一个与之对应的确认操作和撤销操作。它是一个业务层面的协议。在业务中实现分布式事务。对业务代码的侵入性较高。实现的复杂度更高。

BASE理论

BASE理论是CAP理论中的AP的延伸，是互联网大规模分布式系统的实践总结，强调可用性。BASE理论的核心就是：

基本可用（Basically Available）
最终一致性（Eventually Consistent）

基本可用

当分布式系统出现不可预知的故障时，允许损失部分功能的可用性，保证核心功能的可用性。例如：

延迟响应：12306购票系统出现突发流量时，会将购票请求放入队列中进行排队等待处理，通过牺牲响应时间的可用性，保障核心功能的运行。
流量削峰：在不同的时间，出售不同的票，将请求错开，削弱请求峰值。
体验降级：大流量情况，通过降低图片的清晰度和大小，提升系统的处理能力。
过载保护：请求排队时，如果请求等待时间超时，这时直接拒绝超时请求。或者队列满了之后，清除队列中一定数量的排队请求，保证系统不过载，实现系统的基本可用。

最终一致性

系统中所有的数据副本在经过一段时间的同步后，最终能达到一个一致的状态。这存在一个短暂的延迟。几乎所有的互联网系统采用的都是最终一致性，只有实在无法使用最终一致性，才使用强一致性或分布式事务。对于金融系统，需要考虑分布式事务。

如何实现最终一致性？

以最新写入的数据为准，比如AP模型的KV存储采用的是这种方式。
以第一次写入的数据为准，如果你不希望存储的数据被更改，可以以它为准。

如何实现最终一致性？

Leetcode-数组刷题记录

Fri, 08 Jan 2021 21:58:44 +0000

数组的遍历

485. 最大连续1的个数

public int findMaxConsecutiveOnes(int[] nums) {
        //res存储最长的子数组
        int res = 0;
        //count记录的是每个被0隔断的子数组
        int count = 0;
        for(int i = 0; i < nums.length; i++){
            //如果当前元素是1，更新当前子数组的长度
            if(nums[i] == 1){
                count++;
            }else {
                //遇到0，比较res, count的大小，并将count重置为0
                res = Math.max(res, count);
                count = 0;
            }
        }
        //避免最后一个子数组是最大的情况，例如：1,0,1,1,0,1,1,1,1
        return Math.max(res, count);
    }

495. 提莫攻击

public int findPoisonedDuration(int[] timeSeries, int duration) {
        int res = 0;
        for(int i = 0; i < timeSeries.length; i ++){
            //当前能持续的时间
            int time = timeSeries[i] + duration -1;
            //超过下一次攻击的时间
            if(i != timeSeries.length -1 && time >= timeSeries[i + 1]){
                res += (timeSeries[i + 1] - timeSeries[i]);
            }else{
                res += duration;
            }
        }
        return res;
    }

第三大的数

时间复杂度要求$O(n)$，也就是只能通过一趟遍历完成。

OSTEP阅读笔记-Persistence（三）

Tue, 22 Dec 2020 19:49:48 +0000

Chapter I/O设备

Q：如何将I/O集成进计算机系统中？

36.1 系统架构

典型的系统架构如图所示：CPU通过memory bus连接到系统内存。显卡或者其它高速I/O设备通过常规的IO总线（I/O bus，例如PCI）连接到系统。最后是外围总线（peripheral bus，例如SCSI、SATA、USB），他们将最慢的设备连接到系统，包括磁盘、鼠标等。

36.2 标准设备

标准设备包括两部分，分别是：

向系统其他部分展现的硬件/软件接口
内部结构，包括设备相关的特定实现，负责具体实现设备展现给系统的抽象接口。

36.3 标准协议

一个简化的设备接口包括三个寄存器：

一个状态（status）寄存器：读取并查看设备的当前状态
一个命令（command）寄存器：用于通知设备执行某个具体任务。
一个数据（data）寄存器：将数据传给设备或从设备接收数据。

通过读写这些寄存器，OS可以控制设备的行为。

因此可以将操作步骤设置为如下：

OS反复读取状态寄存器，等待设备进入可以接受命令的就绪状态。（轮询）
OS将数据发送到数据寄存器。
OS将命令写入命令寄存器。
OS再次通过不断轮询设备，等待并判断设备是否执行完成命令。

Q：如何减少频繁轮询，从而降低管理设备的CPU的开销？

36.4 利用中断减少CPU开销

设备可以抛出一个硬件中断，引发CPU跳转执行OS预先定义好的中断服务例程（ISR）或者更为简单的中断处理程序（interrupt handler）。

使用中断并非是最佳方案，假如有一个高性能的设备，在CPU第一次轮询时就可以返回结果，那么使用中断反而效率更低。如果设备的速度未知，可以考虑混合策略，先尝试轮询一小段事件，如果设备没有完成操作，此时再使用中断。

如果是网络环境中，那么不要使用中断，因为每个数据包都会发生一次中断，那么可能导致OS发生活锁（一直处理中断程序而不处理用户的请求）。

另一个基于中断的优化就是合并（coalescing），设备在抛出中断之前往往会等待一小段时间，在此期间如果有其他请求的中断，会将多次中断合并为一次中断抛出。从而降低处理中断的代价。

36.5 DMA方式

Q：如何减少Programming IO的开销？

使用DMA（Direct Memory Access）：DMA引擎是一种特殊设备，它可以协调完成内存和设备间的数据传递，不需要CPU介入。

工作过程如下：为了能够将数据传送给设备，OS通过programming告诉DMA引擎数据在内存的位置，要拷贝的大小以及拷贝到哪个设备。在此之后，OS就可以处理其他请求了。当DMA的任务完成后，DMA控制器会抛出一个中断来告诉OS自己完成了数据传输。

36.6 设备交互的方法

Q：如何与设备通信？

使用明确的I/O指令。
内存映射I/O（memory-mapped I/O）
- 通过这种方式，硬件将设备寄存器映射到指定的内存地址中。

36.7 纳入OS：设备驱动程序

每个设备都有非常具体的接口，如何将它们纳入OS，而我们希望OS尽可能通用。

Q：如何实现一个设备无关的OS？

操作系统将与IO设备交互的软件称为设备驱动程序。（封装，向上层展现接口即可）

36.8 IDE磁盘驱动程序

基本逻辑如下：

等待驱动就绪：当驱动READY，读取状态寄存器（0x1F7）
向命令寄存器写入参数：写入扇区数，待访问扇区对应的逻辑块地址（LBA），并将驱动编号（master= 0x00，slave = 0x10，因为IDE允许接入两个硬盘）写入命令寄存器（0x1F2- 0x1F6）。
开启I/O：发送读写命令到命令寄存器。向命令寄存器（0x1F7）中写入READ-WRITE命令。
数据传送（针对写请求）：等待直到驱动状态为READY和DRQ（驱动请求数据），向数据端口写入数据。
中断处理：每个扇区的数据传送结束后都会触发一次中断处理程序，可以合并中断。
错误处理：每次操作之后读取状态寄存器，如果ERROR位被置位。可以读取错误寄存器来获取详细信息。

OSTEP阅读笔记- Concurrency（二）

Thu, 17 Dec 2020 16:57:51 +0000

Chapter 26 并发介绍

本章介绍为单个运行进程提供的新抽象：thread。线程共享地址空间。

每个线程都有自己的PC与自己用于计算的register。如果有两个线程运行在同一个处理器上，发生context switch时，与进程不同的是，使用PCB保存进程状态，使用TCB保存线程状态。区别是：地址空间保持不变（不需要切换当前使用的页表）。

另一个主要区别在于栈，传统进程只有一个栈，如图26.1所示：

多线程中，每个线程拥有自己的栈，位于栈上的变量、参数、返回值是无法共享的。

26.1 实例：线程创建

示例：使用pthead_create()创建了两个线程，主程序调用pthread_join()等待指定线程执行完成。

线程的执行顺序取决于系统调度。

26.2 共享数据导致的问题

多线程对共享数据进行操作会导致非预期结果。

26.3 核心问题：不可控的调度

竞态条件（race condition）：结果取决于代码的执行顺序。运气不好会导致错误的结果。

26.4 原子性

Q：如何构建有用的同步原语？需要从硬件中获取那些支持？

26.5 等待另一个线程

需要研究多线程中的wait/signal机制。

Chapter 27 线程API

Q：如何创建和控制线程？

27.1 pthread_create

在POSIX中：

#include <pthread.h>
int pthread_create( pthread_t * thread,
					const pthread_attr_t * attr,
					void * (*start_routine)(void*),
					void * arg);

参数：

thread：指向pthread_t结构类型的指针，利用它与线程交互。
attr：用于指定该线程可能具有的任何属性，包括设置栈大小、调度优先级。属性通过调用pthread_attr_init()初始化。
start_routine：一个函数指针，指示线程应该在哪个函数上运行。
arg：传递给线程的参数

27.2 pthread_join

#include <pthread.h>
int pthread_join(pthread_t thread, void **retval);

参数：

thread：指定需要等待的线程
retval：指向你希望得到的返回值，定义为一个指向void的指针。

27.3 锁

互斥进入临界区：

int pthread_mutex_lock(pthread_mutex_t *mutex);
int pthread_mutex_unlock(pthread_mutex_t *mutex);

使用：

pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER;
pthread_mutex_lock(&lock);
x = x + 1; // or whatever your critical section is
pthread_mutex_unlock(&lock);

27.4 条件变量

当线程之间必须发生某种信号时，如果一个线程在等待另一个线程继续执行某些操作，条件变量就很有用。

OSTEP阅读笔记-Virtuallization（一）

Sat, 05 Dec 2020 14:21:23 +0000

进程虚拟化

Chapter 4 进程

Q：如何提供有许多CPU的假象？

OS通过Visualizing CPU来提供这种假象。通过让一个进程只运行一个时间片，然后切换到其它进程，这样就提供了存在多个虚拟CPU的假象。

时分共享：典型的就是时间片划分，将一小段时间分配给不同的进程。
空分共享：典型的就是磁盘空间，将空间分配给不同的文件。

Qustions：

如何实现context switch
OS如何执行scheduling policy

4.1 抽象：进程

OS为正在运行的程序提供的抽象，就是所谓的进程。

进程的machine state：

进程可访问的内存（address space）：指令和数据存储在address space。
寄存器（register）

4.2 进程API

create
destroy
wait
miscellaneous control
status

4.3 进程创建的细节

Q: 程序如何转换为进程？换而言之，OS如何启动并运行一个程序？

OS将代码和静态数据load到内存中，加载到进程的address space。如图4.1所示：

加载后，OS在运行前需要执行初始化操作。
- 为程序的**运行时栈（run-time stack）**分配一些内存。C程序使用栈存放局部变量，函数参数和返回地址。
- 为**堆（heap）**分配一些内存，C程序中，堆用于显式请求的动态分配数据（malloc & free）
- I/O相关的任务。UNIX中每个进程都会有三个打开的文件描述符（file descriptor）

4.4 进程状态

运行
就绪
阻塞

进程的状态转化图如图4.2所示：

4.5 数据结构

对于停止的进程，上下文将保存寄存器的内容，通过上下文切换可以使OS恢复运行该进程。

下图中的context就是上下文的数据结构，proc

Chapter 5 进程API

本章讨论在UNIX系统中的进程创建。

Q：如何创建并控制进程？

fork() 系统调用

fork()用于创建新进程，fork的子进程从fork处开始执行。示例代码如下：

ThreadLocal解析

Thu, 03 Dec 2020 11:17:38 +0000

简介

This class provides thread-local variables. These variables differ from their normal counterparts in that each thread that accesses one (via its get or set method) has its own, independently initialized copy of the variable. ThreadLocal instances are typically private static fields in classes that wish to associate state with a thread (e.g., a user ID or Transaction ID).

简而言之，ThreadLocal可以创建一个只能被当前线程访问或修改的变量。

分析

Q：如何实现线程隔离？

使用Thread对象中的ThreadLocalMap进行数据存储。也就是ThreadLocal将数据存储到当前的线程对象中，通过Thread.currentThread()来获取线程，再通过getMap(t)来获取ThreadLocalMap。具体内容通过阅读源码来逐步分析。

get

返回当前线程存储的ThreadLocal值，如果不存在，会进行初始化并返回。通过map.getEntry(this)。

/**
 * Returns the value in the current thread's copy of this
 * thread-local variable.  If the variable has no value for the
 * current thread, it is first initialized to the value returned
 * by an invocation of the {@link #initialValue} method.
 *
 * @return the current thread's value of this thread-local
 */
public T get() {
    //获取当前对象
    Thread t = Thread.currentThread();
    //通过getMap获取ThreadLocalMap
    ThreadLocalMap map = getMap(t);
    if (map != null) {
        //获取entry
        ThreadLocalMap.Entry e = map.getEntry(this);
        if (e != null) {
            @SuppressWarnings("unchecked")
            T result = (T)e.value;
            return result;
        }
    }
    //不存在则进行初始化
    return setInitialValue();
}

getMap

返回指定线程的ThreadLocalMap。

几个Java并发工具类解析

Sun, 29 Nov 2020 22:40:17 +0000

CountDownLatch

简介

A synchronization aid that allows one or more threads to wait until a set of operations being performed in other threads completes.

只有当N个线程执行完毕，并且进行countDown操作时，才允许await的线程继续执行。否则该线程挂起。

适用情况：一个线程需要等待其他N个线程执行完毕，再继续执行，是join的替代。

构造方法

参数count为计数值，传入AQS的实现类Sync设置成AQS的state。

public CountDownLatch(int count) {
        if (count < 0) throw new IllegalArgumentException("count < 0");
        this.sync = new Sync(count);
}

Sync

通过继承AQS从而完成同步的核心功能。

private static final class Sync extends AbstractQueuedSynchronizer {
        private static final long serialVersionUID = 4982264981922014374L;
		
    	//构造方法
        Sync(int count) {
            setState(count);
        }

        int getCount() {
            return getState();
        }

        protected int tryAcquireShared(int acquires) {
            return (getState() == 0) ? 1 : -1;
        }

        protected boolean tryReleaseShared(int releases) {
            // Decrement count; signal when transition to zero
            for (;;) {
                int c = getState();
                if (c == 0)
                    return false;
                int nextc = c-1;
                if (compareAndSetState(c, nextc))
                    return nextc == 0;
            }
        }
    }

核心方法

countDown：将count值减1
await：调用await的线程会被挂起，直到count为0才继续执行，允许中断

public void await() throws InterruptedException {
        sync.acquireSharedInterruptibly(1);
}

public void countDown() {
        sync.releaseShared(1);
}

public boolean await(long timeout, TimeUnit unit)
        throws InterruptedException {
        return sync.tryAcquireSharedNanos(1, unit.toNanos(timeout));
}

使用案例

class Driver { // ...
   void main() throws InterruptedException {
     CountDownLatch startSignal = new CountDownLatch(1);
     CountDownLatch doneSignal = new CountDownLatch(N);

     for (int i = 0; i < N; ++i) // create and start threads
       new Thread(new Worker(startSignal, doneSignal)).start();

     doSomethingElse();            // don't let run yet
     startSignal.countDown();      // let all threads proceed
     doSomethingElse();
     doneSignal.await();           // wait for all to finish
   }
 }

 class Worker implements Runnable {
   private final CountDownLatch startSignal;
   private final CountDownLatch doneSignal;
   Worker(CountDownLatch startSignal, CountDownLatch doneSignal) {
      this.startSignal = startSignal;
      this.doneSignal = doneSignal;
   }
   public void run() {
      try {
        startSignal.await();
        doWork();
        doneSignal.countDown();
      } catch (InterruptedException ex) {} // return;
   }

   void doWork() { ... }
 }

CyclicBarrier

简介

A synchronization aid that allows a set of threads to all wait for each other to reach a common barrier point. CyclicBarriers are useful in programs involving a fixed sized party of threads that must occasionally wait for each other. The barrier is called cyclic because it can be re-used after the waiting threads are released.

解析线程池ThreadPoolExecutor

Thu, 26 Nov 2020 14:05:34 +0000

什么是线程池

Thread Pool是一种基于池化思想管理线程的工具，经常出现在多线程程序中。

线程池的优点：

降低资源消耗：通过池化技术重复利用已创建线程。
提高响应速度：任务到达时，无需等待进程创建即可执行。
提高线程的可管理性：使用线程池进行统一的分配、调优和监控。
提供更多强大的功能：线程池具备可扩展性，允许开发人员向其中增加更多功能。

为什么用线程池

直接创建线程存在性能开销：

Java中线程是基于内核线程实现的，线程的创建和销毁需要进行系统调用，性能开销较高。
Java8中，每个Thread都需要有一个内核线程的支持，这意味着每个Thread都需要消耗一定的内核资源。Java8中每个线程栈大小是1M，Java11中，对创建线程操作进行优化，创建一个线程只需要40KB左右。
线程切换引起context switch。

使用线程池解决的核心问题就是资源管理问题，多线程环境下，不确定性会带来一些问题：频繁申请/销毁线程会带来额外的开销、存在资源耗尽的风险等。

使用池化思想将资源统一在一起管理的一种思想，可以最大化收益最小化风险，

ThreadPoolExecutor

继承关系

ThreadPoolExecutor类的继承关系如下：

Executor：顶层的Executor仅提供一个execute()接口，实现了提交任务与执行任务的解耦。
ExecutorService：继承自Executor，实现了添加了其他接口，例如：
- 为一个或一批异步任务生成Future的方法
- 提供了管控线程池的方法，例如停止线程池运行。
AbstractExecutorService：实现了ExecutorService，实现了除execute()以外的所有方法，将最重要的execute()交给ThreadPoolExecutor实现。

运行机制

ThreadPoolExecutor的基本运行机制如下图所示（图片来源：美团技术团队）：

线程池内部相当于一个生产者消费者模型，将线程池分成两个部分：任务管理、线程管理。

任务管理相当于生产者，任务提交后，线程池判断该任务的后续操作。
1. 直接申请线程执行该任务
2. 存放到阻塞队列中等待
3. 拒绝该任务。
线程管理部分是消费者，根据任务请求进行线程分配工作，当线程执行完任务后会继续获取新的任务去执行，最终当线程获取不到任务时，线程会进行回收。

构造方法

核心的构造方法如下，主要参数有：

corePoolSize：核心线程数量
maximumPoolSize：最大线程数量
workQueue：BlockingQueue类型，保存等待执行任务的阻塞队列，当提交一个新的任务到线程池时，线程池根据当前状态决定后续处理。可选择以下几种：
- ArrayBlockingQueue
- LinkedBlockingQueue：Executors.newFixedThreadPool使用该队列
- SynchronousQueue：同步队列，容量为0，put必须等待take，take等待put，Executors.newCachedThreadPool使用该队列。
keepAliveTime：线程池维护线程所允许的时间。当线程池中的线程数量大于corePoolSize的时候，如果这时没有新的任务提交，核心线程外的线程不会立即销毁，而是会等待，直到等待的时间超过了keepAliveTime。
threadFactory：它是ThreadFactory类型的变量，用来创建新线程。
handler：RejectedExecutionHandler类型，表示线程池的拒绝策略。如果阻塞队列满了并且没有空闲的线程，这时如果继续提交任务，就需要采取一种策略处理该任务。

public ThreadPoolExecutor(int corePoolSize,
                              int maximumPoolSize,
                              long keepAliveTime,
                              TimeUnit unit,
                              BlockingQueue<Runnable> workQueue,
                              ThreadFactory threadFactory,
                              RejectedExecutionHandler handler) {
        if (corePoolSize < 0 ||
            maximumPoolSize <= 0 ||
            maximumPoolSize < corePoolSize ||
            keepAliveTime < 0)
            throw new IllegalArgumentException();
        if (workQueue == null || threadFactory == null || handler == null)
            throw new NullPointerException();
        this.acc = System.getSecurityManager() == null ?
                null :
                AccessController.getContext();
        this.corePoolSize = corePoolSize;
        this.maximumPoolSize = maximumPoolSize;
        this.workQueue = workQueue;
        this.keepAliveTime = unit.toNanos(keepAliveTime);
        this.threadFactory = threadFactory;
        this.handler = handler;
    }

线程池的状态

线程池的运行状态，由AtomicInteger ctl维护，其中分为两个参数：runState和workerCount，高3位存储runState，低29位存储workerCount，提供了位运算的方法来获取对应的参数。线程池的运行状态，通过内部进行调整。

ReentrantReadWriteLock源码分析

Sun, 22 Nov 2020 17:00:43 +0000

简介

ReentrantReadWriteLock分为读锁和写锁两个实例，读锁是共享锁，可被多个读线程同时使用，写锁是独占锁。持有写锁的线程可以继续获取读锁，反之不行。

Doug Lea 将持有写锁的线程，去获取读锁，之后释放读锁，最后释放写锁，从写锁降级为读锁的过程称为锁降级（Lock downgrading）。

但是，锁升级是不可以的。线程持有读锁的话，在没释放的情况下不能去获取写锁，因为会发生死锁。

类的继承关系

ReentrantReadWriteLock实现了ReadWriteLock接口，该接口定义了两个方法，分别返回读锁和写锁。

public class ReentrantReadWriteLock implements ReadWriteLock, java.io.Serializable {}
    
public interface ReadWriteLock {
    /**
     * Returns the lock used for reading.
     *
     * @return the lock used for reading
     */
    Lock readLock();

    /**
     * Returns the lock used for writing.
     *
     * @return the lock used for writing
     */
    Lock writeLock();
}

类成员属性

//读锁
private final ReentrantReadWriteLock.ReadLock readerLock;

//写锁
private final ReentrantReadWriteLock.WriteLock writerLock;

//Sync是AQS的实现类
final Sync sync;

//Unsafe实例
private static final sun.misc.Unsafe UNSAFE;

//获取Thread.tid的内存偏移值
private static final long TID_OFFSET;

static {
        try {
            UNSAFE = sun.misc.Unsafe.getUnsafe();
            Class<?> tk = Thread.class;
            TID_OFFSET = UNSAFE.objectFieldOffset
                (tk.getDeclaredField("tid"));
        } catch (Exception e) {
            throw new Error(e);
        }
}

构造方法

默认的构造方法创建非公平策略的ReentrantReadWriteLock，传入true则可以创建公平策略的ReentrantReadWriteLock。

ReentrantLock源码分析

Fri, 20 Nov 2020 12:40:08 +0000

简介

相对于synchronized关键字，ReentrantLock具备以下特点：

可中断
可设置超时时间
可设置为公平锁
支持多个条件变量

源码实现

可重入锁的实现上，主要关注两点：

可重入线程的再次获取锁的处理
可重入锁的释放机制

类的继承关系

ReentrantLock实现了Lock接口，Lock接口定义了锁的通用方法。

public class ReentrantLock implements Lock, java.io.Serializable

成员变量

sync代表当前ReentrantLock使用的获取策略。

private final Sync sync;
private static final long serialVersionUID = 7373984872572414699L;

构造方法

无参构造方法
- 默认是非公平策略
有参构造方法
- 传入true使用公平策略。

/**
     * Creates an instance of {@code ReentrantLock}.
     * This is equivalent to using {@code ReentrantLock(false)}.
     */
    public ReentrantLock() {
        sync = new NonfairSync();
    }

    /**
     * Creates an instance of {@code ReentrantLock} with the
     * given fairness policy.
     *
     * @param fair {@code true} if this lock should use a fair ordering policy
     */
    public ReentrantLock(boolean fair) {
        sync = fair ? new FairSync() : new NonfairSync();
    }

获取锁的策略

ReentrantLock内部有三个内部类，其中Sync是其它两个类NonfairSync和FairSync的父类，分别代表着非公平策略和公平策略。

《程序员练级攻略》阅读总结

Tue, 17 Nov 2020 14:41:20 +0000

前言

陈皓叔叔的这个专栏之前就有所耳闻并大致过了一遍，如今重新精读本专栏，认真学习，对整体的学习方向进行把握，并且进行总结。

如何入门？

学习Python，JavaScript，学习使用操作系统Linux，编程工具VS Code，Web开发等，这些更容易获得编程的成就感。

如何成为专业的程序员？

拥有程序员的自我修养。这是反映出程序员的工程师特质和价值观，决定了这条路你到底能走多远。有修养的程序员才可能成长为真正的工程师和架构师，没有修养的程序员智能沦为码农，这是码农和工程师的关键区分点。

英文能力
提问的能力
写代码的修养
- 重构：改善既有代码的设计
- 代码整洁之道
- 程序员的职业素养
- Code Review
  - 对自我成长非常有帮助
  - 不做Code Review的公司没有必要呆
- Unit Test
安全防范意识
- 代码安全
- 防御性编程
软件工程和上线规范
- 完美软件：对软件测试的各种幻想
- Google软件测试之道
编程规范

专业基础包括哪些？

编程语言：推荐C、C++、Java这三个工业级的编程语言。
理论学科：数据结构和算法，计算机网络，计算机组成原理，操作系统，编译原理

从业方向？

如果你对操作系统、文件系统、数据库、网络等比较感兴趣，那么可以考虑从事底层方面的工作。
如果对分布式系统架构、微服务、DevOps、Cloud Native 等有热情，那么可以从事架构方面的工作。
如果是对大数据、机器学习、人工智能等比较关注，那么数据领域可以成为你一展身手的地方。
如果你对用户体验或者交互等更感兴趣，那么前端工程师也是个不错的选择。
此外，安全开发、运维开发、嵌入式开发等几大方向中，也为你提供了丰富多彩的发展空间。

两个观点：

各种技术方向不是鱼和熊掌，是可以兼得的。
很多技术都是相通的，关键是要学的深入本质。

几个问题：

理论和现实的差距：学院派的知识是成为专家的必经之路，这就是“工人”和“工程师”的差别，是“建筑工人”和“建筑架构师”的差别。
技术太多学不过来/技术能力的瓶颈：自己懒惰的借口，以绝大多数人努力的程度，和为自己不努力找借口的程度为参考，只要你坚持正常的学习就可以超过大多数人了。

学习建议？

一定要坚持，要保持长时间学习，甚至终身学习的态度。
一定要动手，不管例子多么简单，建议至少自己动手敲一遍看看是否理解了里面的细枝末节。
一定要学会思考，思考为什么会这样，要学会举一反三。
不要乱买书，不要乱追新技术新名词，基础的东西经过很长时间积累，会在未来至少十年通用。

编程入门

入门语言Python
入门语言JavaScript
操作系统LInux
编程工具VS Code
Web入门

正式入门

编程技能
- 如何快速提升自己的编程能力
编程技巧
- 代码大全
编程语言
- Java
操作系统
- 鸟哥的Linux私房菜
网络协议
- 系统了解HTTP协议
数据库设计
- 基本的设计知识
- MySQL必知必会
前端
- Vue
字符编码方面
- Wikipedia

为什么转成Java语言？

秒杀系统设计总结

Mon, 09 Nov 2020 13:29:50 +0000

简介

秒杀从规模上可以分为以下两类：

大秒：类似双十一，商品数量规模大，价格低，流量超大的活动。
小秒：商家自己配置的一些时段类型的活动，由商家自己指定时间上架。

秒杀系统面对的问题

秒杀系统本质上就是一个满足大并发、高性能和高可用的分布式系统。

高并发环境下的系统稳定性：如何保证系统在面对巨大的流量情况下，不被打崩？
- 两个问题
  - 并发读
    - 核心优化理念：减少用户到服务端来读数据。或者让他们读取更少的数据。
  - 并发写
    - 核心优化理念：在数据库层面独立出来一个库，做特殊的处理。
- 大流量会产生以下实际待解决问题
  - Redis缓存击穿/雪崩/穿透等问题
  - 关系型数据库性能问题，锁竞争对性能的消耗
保证数据的最终一致性：库存不能超卖。
大数据分析功能：分析本次秒杀活动的商业效益。
需要有一个兜底方案，以防最坏的情况发生。

设计

架构原则： “4要1不要”

架构是一种平衡的艺术，最好的架构一旦脱离了它所适应的场景，一切都将是空谈。

数据要尽量少
- 用户请求的数据能少就少，包括上传给系统的数据和系统返回给用户的数据。
HTTP请求数尽量少
- 合并CSS，JS文件
路径要尽量短
- 用户发出请求到返回数据的过程中，经过的节点要尽量短
  - 通常，每经过一个节点，都会产生一个新的Socket连接。
- 会减少时延
- 可以选择将多个相互强依赖的引用部署在一起，将RPC变成JVM内部的方法调用
依赖要尽量少
- 完成一次用户请求必须依赖的系统或服务要少（指的是强依赖）
  - 比如展示秒杀页面，它强依赖商品信息，用户信息，但是优惠券，成交列表等非必要模块是可以在紧急情况下去掉。
- 对系统模块进行分级，0级，1级，2级等
不要有单点
- 系统中的单点是系统架构上的一个大忌，单点意味着没有备份，风险不可控。
  - 如何避免单点？
    - 避免将服务的状态和机器绑定（服务无状态化）
      - 把服务的配置动态化（使用配置中心Nacos等）
      - 存储服务不好实现，因为数据持久化存储在机器的磁盘里面。文件存储可以通过冗余多个备份的方式来解决单点问题。

流量过滤

本质：逐级过滤掉无效的流量。基本有以下一些解决方案：

活动开始前前端页面的Button无法点击，防止活动尚未开始时，用户进行点击产生流量。
- 同时后端需要做相关校验。避免用户直接请求秒杀接口。
- 秒杀url实现动态化，可以选择进行md5加密随机字符串，然后通过另一个接口校验秒杀接口的合法性
错峰：前端添加验证码或者答题，防止瞬间产生超高的流量，增加题目辨别难度，避免以图像识别等技术进行破解。
校验：对参与活动的用户进行校验拦截。主要从以下几个方面进行判断
- 用户白名单
- 用户终端校验：对用户终端类型进行判断
- IP、MAC、ID校验
- 参与次数校验：避免多次参与活动
- 用户黑名单：避免羊毛党等
限流：通过接口限流策略判断请求是否放行
- 令牌桶算法

性能优化

前面的流量过滤基本过滤掉大部分流量，但是系统性能还需进行优化，主要有以下的解决方案：

动静分离
活动预热：将参加活动的商品独立出来，不和普通的商品库存共享服务，提前将数据缓存到Redis，查询全部走缓存，扣减库存视情况而定。
选择Nginx
采用微服务架构部署，提高部署量，均摊请求。
秒杀是典型的读多写少的场景，考虑到单体redis的性能问题，可以考虑：
- Redis集群
- 主从同步
- 读写分离
- 如果使用Redis集群，同时需要考虑保证多节点的数据一致性
异步处理：采用消息队列
- 异步，削峰，解耦

动静分离

“动态数据”和“静态数据”的主要区别就是看页面中输出的数据是否和 URL、浏览者、时间、地域相关，以及是否含有 Cookie 等私密数据。

LockSupport源码分析

Sun, 08 Nov 2020 12:46:28 +0000

简介

Basic thread blocking primitives for creating locks and other synchronization classes. – Java Doc

LockSupport是用来创建锁和其它同步类的基本线程阻塞原语。底层依赖Unsafe实现，我们可以在其它的并发同步工具类的实现中看到该类的使用。LockSupport提供了park()和unpark()方法来分别实现阻塞线程和唤醒线程，每个使用LockSupport的线程都有一个permit，该值默认为0，取值0,1。

unpark()：如果permit当前值为0，将其自增1。
park()：如果当前permit为1，将其自减1并立即返回，如果为0，直接阻塞。

这两个方法不会有Thread.suspend 和Thread.resume所可能引发的死锁问题，因为permit存在，调用 park 的线程和另一个试图将其 unpark 的线程之间的竞争将保持活性。

如果调用线程被中断，那么park将会返回。park方法可能在任何时间no reason地返回，因此通常在重新检查返回条件地循环里调用此方法。在某种意义上，park是busy wait（忙则等待）的一种优化，减少了自旋对性能的消耗。当时必须与unpark配合使用才会更加高效。

park还提供了支持blocker参数的方法，blocker对象在线程受阻塞时被记录，用于允许监视和诊断工具确定线程被阻塞的原因。提供了getBlocker(Thread t)来访问blocker。

下面是Java Docs中的示例用法：一个先进先出非重入锁类的基本框架：

class FIFOMutex {
    private final AtomicBoolean locked = new AtomicBoolean(false);
    private final Queue<Thread> waiters
      = new ConcurrentLinkedQueue<Thread>();
 
    public void lock() {
      boolean wasInterrupted = false;
      Thread current = Thread.currentThread();
      waiters.add(current);
 
      // Block while not first in queue or cannot acquire lock
      while (waiters.peek() != current ||
             !locked.compareAndSet(false, true)) {
        LockSupport.park(this);
        if (Thread.interrupted()) // ignore interrupts while waiting
          wasInterrupted = true;
      }

      waiters.remove();
      if (wasInterrupted)          // reassert interrupt status on exit
        current.interrupt();
    }
 
    public void unlock() {
      locked.set(false);
      LockSupport.unpark(waiters.peek());
    }
  }}

源码解读

成员变量

UNSAFE：用于进行内存级别操作的工具类。
parkBlockerOffset：存储Thread.parkBlocker的内存偏移地址，记录线程被谁阻塞的。用于线程监控和分析工具用来定位原因的。可以通过getBlocker获取到阻塞的对象。
SEED：存储Thread.threadLocalRandomSeed的内存偏移地址
PROBE：存储Thread.threadLocalRandomProbe的内存偏移地址
SECONDARY：存储Thread.threadLocalRandomSecondarySeed的内存偏移地址

private static final sun.misc.Unsafe UNSAFE;
private static final long parkBlockerOffset;
private static final long SEED;
private static final long PROBE;
private static final long SECONDARY;

构造方法

不允许实例化，只能通过调用静态方法来完成操作。

Java原子类的使用与实现

Thu, 29 Oct 2020 19:39:23 +0000

简介

通常情况下，在Java中，++i这类自增/自减运算符在并发环境中不能保证并发安全。需要通过加锁才能解决并发环境下的原子性问题。Atomic原子类通过CAS方式来解决线程安全问题，CAS是一种无锁算法（乐观锁），乐观锁多用于“读多写少“的环境，避免频繁加锁影响性能；而悲观锁多用于”写多读少“的环境，避免频繁失败和重试影响性能。

Atomic原子类分为以下几类：

基本类型：AtomicInteger，AtomicLong，AtomicBoolean
数组类型：AtomicIntegerArray，AtomicLongArray，AtomicReferenceArray
引用类型：AtomicReference，AtomicStampedRerence，AtomicMarkableReference
更新字段类：AtomicIntegerFieldUpdater、AtomicLongFieldUpdater、AtomicReferenceFieldUpdater
Java8 新增类：DoubleAccumulator，DoubleAdder，LongAccumulator，LongAdder

使用

原子基本类型

使用原子的方式更新基本类型。

AtomicBoolean: 原子布尔类型。
AtomicInteger: 原子整型。
AtomicLong: 原子长整型。

以下以AtomInteger举例：

//以原子方式将给定值与当前值相加，线程安全的i = i + delta
int addAndGet(int delta);
//如果当前值== except，则以原子方式将当前值设置为update，成功返回true
boolean compareAndSet(int expect, int update);
//以原子方式将当前值减1，相当于线程安全的i--
int decrementAndGet();
//以原子方式将当前值加1，相当于线程安全的i++
int incrementAndGet()


private static final Unsafe unsafe = Unsafe.getUnsafe();
    private static final long valueOffset;

    static {
        try {
            valueOffset = unsafe.objectFieldOffset
                (AtomicInteger.class.getDeclaredField("value"));
        } catch (Exception ex) { throw new Error(ex); }
    }

    private volatile int value;

/**
     * Atomically increments by one the current value.
     *
     * @return the updated value
     */
    public final int incrementAndGet() {
        return unsafe.getAndAddInt(this, valueOffset, 1) + 1;
    }

    /**
     * Atomically decrements by one the current value.
     *
     * @return the updated value
     */
    public final int decrementAndGet() {
        return unsafe.getAndAddInt(this, valueOffset, -1) - 1;
    }

从上面代码可以看出，AtomicInteger底层使用volatile关键字和CAS来保证线程安全。其中：

volatile关键字剖析

Sat, 24 Oct 2020 21:59:36 +0000

定义

The Java programming language allows threads to access shared variables (§17.1).As a rule, to ensure that shared variables are consistently and reliably updated, a thread should ensure that it has exclusive use of such variables by obtaining a lock that, conventionally, enforces mutual exclusion for those shared variables.The Java programming language provides a second mechanism, volatile fields,that is more convenient than locking for some purposes.A field may be declared volatile, in which case the Java Memory Model ensures that all threads see a consistent value for the variable (§17.4).

synchronized关键字剖析

Sun, 11 Oct 2020 22:59:39 +0000

使用

在使用Synchronized关键字需要把握以下注意点：

一把锁只能同时被一个线程获取，没有获得锁的线程只能等待。
每一个实例都有自己的一个锁资源，存放于对象头中（2bit表示锁信息）

对象锁

同步代码块锁（可以指定锁定对象）
方法锁（默认锁定对象为this（当前实例对象））

public void test() {
   synchronized (obj){
   System.out.println("hello");
   }
}

public synchronized void test() {
   System.out.println("hello");
}

类锁

synchronized修饰静态方法或指定锁对象为Class对象。

public static synchronized void method() {
    //do something
}
synchronized(ObjectDemo.class){
    
}

理论基础

在操作系统进程管理中，对进程并发问题主要提供了两种解决方法：信号量和管程。在Java 1.5之前，提供的唯一并发原语就是管程，Java 1.5之后提供的JUC包也是以管程技术为基础的。

管程定义

一个管程定义了一个数据结构和能为并发进程所执行的一组操作，这组操作能同步进程和改变管程中的数据。

通俗而言：管程（Monitor）是管理共享变量以及对共享变量的操作过程，让他们支持并发。在OS领域一般称为管程，Java中可以称为监视器（monitor）。

MESA模型

MESA模型是当今广泛使用的MESA模型，Java管程的实现参考的也是MESA模型。并对其进行了精简。Java内置的管程只有一个条件变量。

如下图所示：管程X将共享变量queue、入队操作于出队操作封装起来。如果线程A和线程B访问共享变量queue，只能通过调用管程提供的enq()和deq()来实现。两个方法保证互斥性，，只允许一个线程进入管程并操作。该模型能实现并发编程中的互斥问题。

下图为MESA管程模型示意图，框中即是封装的管程，所有线程通过入口等待队列进入管程。管程还引入了条件变量的概念，每一个条件变量都对应一个等待队列。管程的同步主要通过Condition（条件变量）实现。Condition可以执行wait()和signal()。

假设线程T1执行出队操作，同时有个前提条件：队列不为空，这是条件变量。如果T1进入管程发现队列为空，则会在条件变量的等待队列进行等待。调用wait()实现。此刻允许其它线程进入管程。

此时线程T2执行入队操作，入队成功后，队列不空条件对于T1已经满足，T2调用notify()来通知T1。通知他条件已满足。

两个操作

wait

MESA模型提供了一个特有的编程范式，通过循环检查条件调用wait()。管程模型中：条件满足后，如何通知相关线程。管程要求同一时刻只能有一个线程能执行，那么上述问题中T1，T2谁执行呢？

在MESA中，T2通过notify()通知完后，继续执行，T1从条件变量的等待队列进入入口等待队列中。

while(条件不满足) {
	wait();
}

signal

尽量使用notifyAll()，如果满足以下三个条件则可以使用notify()：

所有等待线程拥有相同的等待条件
所有等待线程被唤醒后，执行相同的操作
只需要唤醒一个线程

实现

JVM字节码层面

从JVM层面来看，主要通过两个字节码指令实现，monitorenter与monitorexit。这两个字节码需要指定一个对象引用作为参数。这个对象引用就是monitor object。它就是synchronized传入的对象实例，该对象充当着维护了mutex以及顶层父类Object提供的wait/notify机制。

public class wang.l1n.volatile1.Demo02 {
  public wang.l1n.volatile1.Demo02();
    Code:
       0: aload_0
       1: invokespecial #1                  // Method java/lang/Object."<init>":()V
       4: return

  public static void main(java.lang.String[]);
    Code:
       0: getstatic     #2                  // Field object:Ljava/lang/Object;
       3: dup
       4: astore_1
       5: monitorenter
       6: getstatic     #3                  // Field java/lang/System.out:Ljava/io/PrintStream;
       9: ldc           #4                  // String hello world
      11: invokevirtual #5                  // Method java/io/PrintStream.println:(Ljava/lang/String;)V
      14: aload_1
      15: monitorexit
      16: goto          24
      19: astore_2
      20: aload_1
      21: monitorexit
      22: aload_2
      23: athrow
      24: return
    Exception table:
       from    to  target type
           6    16    19   any
          19    22    19   any

  static {};
    Code:
       0: new           #6                  // class java/lang/Object
       3: dup
       4: invokespecial #1                  // Method java/lang/Object."<init>":()V
       7: putstatic     #2                  // Field object:Ljava/lang/Object;
      10: return
}

JVM实现层面

每个Java对象都关联一个Monitor对象，如果使用synchronized给对象上锁，该对象的MarkWord中就被设置指向Monitor对象的指针。

Java8特性

Thu, 13 Aug 2020 13:31:02 +0000

Lambda表达式

函数式编程简介

函数式编程（英语：functional programming）或称函数程序设计、泛函编程，是一种编程范式，它将电脑运算视为函数运算，并且避免使用程序状态以及易变对象。其中，λ演算（lambda calculus）为该语言最重要的基础。而且，λ演算的函数可以接受函数当作输入（引数）和输出（传出值）。（摘自Wikipedia）

面向对象编程是对数据进行抽象；函数式编程是对行为进行抽象。

核心思想: 使用不可变值和函数，函数对一个值进行处理，映射成另一个值。

Lambda语法格式

		//无参数，无返回值
        Runnable runnable = ()-> System.out.println("Hello world");
        runnable.run();

        //有一个参数，无返回值
        Consumer<String> consumer = (e) -> System.out.println(e);
        consumer.accept("Hello world");

        //两个参数，多条语句
        Comparator<Integer> comparator = (a, b) -> {
            System.out.println("Hello world");
            return Integer.compare(a, b);
        };

        //lambda中只有一条语句，可简写
        Comparator<Integer> comparator1 = (a, b) -> Integer.compare(a, b);

        //省略参数类型
        Comparator<Integer> comparator2 = (Integer a, Integer b) -> Integer.compare(a, b);
        Comparator<Integer> comparator3 = (a, b) -> Integer.compare(a, b);

函数式接口

接口中只有一个抽象方法的接口（不包括默认方法），称为函数式接口。使用@FunctionInterface注解修饰，用来检查是否满足条件。

Integer小细节

Thu, 06 Aug 2020 21:55:21 +0000

Integer

IntegerCache

在Java中，创建的对象会存储在堆内存，·IntegerCache·主要用来做缓存，减少内存的重复消耗。但是IntegerCache缓存的数据范围在-128到127之间。可以通过 -XX:AutoBoxCacheMax=high 来指定这个缓冲池的大小，JVM通过 java.lang.IntegerCache.high 系统属性来存储该值，IntegerCache初始化的时候就会读取该系统属性来决定大小。以下为源码：

private static class IntegerCache {
        static final int low = -128;
        static final int high;
        static final Integer cache[];

        static {
            // high value may be configured by property
            int h = 127;
            //读取JVM参数值
            String integerCacheHighPropValue =
                sun.misc.VM.getSavedProperty("java.lang.Integer.IntegerCache.high");
            //初始化high
            if (integerCacheHighPropValue != null) {
                try {
                    int i = parseInt(integerCacheHighPropValue);
                    i = Math.max(i, 127);
                    // Maximum array size is Integer.MAX_VALUE
                    h = Math.min(i, Integer.MAX_VALUE - (-low) -1);
                } catch( NumberFormatException nfe) {
                    // If the property cannot be parsed into an int, ignore it.
                }
            }
            high = h;
            //127 - (-128) + 1为数组容量
            cache = new Integer[(high - low) + 1];
            //初始化Cache数组
            int j = low;
            for(int k = 0; k < cache.length; k++)
                cache[k] = new Integer(j++);

            // range [-128, 127] must be interned (JLS7 5.1.7)
            assert IntegerCache.high >= 127;
        }

        private IntegerCache() {}
    }

Integer.valueOf()

首先看一下关于该方法的实现：

TreeMap源码分析

Wed, 05 Aug 2020 09:17:29 +0000

简介

TreeMap底层通过红黑树实现，在查询性能上能达到O(logn)，由于使用红黑树结构进行存储，所以TreeMap的元素都是有序的。同时，这也是一个非线程安全的Map，无法在并发环境下使用。

TreeMap继承自AbstractMap，该类Map接口的抽象实现。实现了 NavigableMap、Cloneable和 Serializable接口。其中NavigableMap继承自SortedMap，这保证了TreeMap的有序性。

public class TreeMap<K,V>
    extends AbstractMap<K,V>
    implements NavigableMap<K,V>, Cloneable, java.io.Serializable

数据结构

TreeMap采用红黑树进行构建，红黑树是一种自平衡二叉查找树。插入、删除、查找的时间复杂度为O(logn)。与另一个自平衡二叉查找树AVL Tree相比，红黑树以减少旋转操作牺牲部分平衡性，但是其整体性能优于AVL Tree。

有关红黑树的定义如下（摘自wikipedia）：

节点是红色或黑色。
根是黑色。
所有叶子都是黑色（叶子是NIL节点）。
每个红色节点必须有两个黑色的子节点。（从每个叶子到根的所有路径上不能有两个连续的红色节点。）
从任一节点到其每个叶子的所有简单路径都包含相同数目的黑色节点。

TreeMap中树节点的定义如下：

static final class Entry<K,V> implements Map.Entry<K,V> {
        K key;
        V value;
        Entry<K,V> left;
        Entry<K,V> right;
        Entry<K,V> parent;
        boolean color = BLACK;

        
        Entry(K key, V value, Entry<K,V> parent) {
            this.key = key;
            this.value = value;
            this.parent = parent;
        }

        
        public K getKey() {
            return key;
        }

        
        public V getValue() {
            return value;
        }

    
        public V setValue(V value) {
            V oldValue = this.value;
            this.value = value;
            return oldValue;
        }

        public boolean equals(Object o) {
            if (!(o instanceof Map.Entry))
                return false;
            Map.Entry<?,?> e = (Map.Entry<?,?>)o;

            return valEquals(key,e.getKey()) && valEquals(value,e.getValue());
        }

        public int hashCode() {
            int keyHash = (key==null ? 0 : key.hashCode());
            int valueHash = (value==null ? 0 : value.hashCode());
            return keyHash ^ valueHash;
        }

        public String toString() {
            return key + "=" + value;
        }
    }

成员变量

	//TreeMap中用来确定顺序的comparator
	private final Comparator<? super K> comparator;

	//树的根节点
    private transient Entry<K,V> root;

    //树的大小
    private transient int size = 0;

    //结构变化计数器
    private transient int modCount = 0;

	//EntrySet
	private transient EntrySet entrySet;
    private transient KeySet<K> navigableKeySet;
    private transient NavigableMap<K,V> descendingMap;

	//SubMapIterator中fence == null时，key的值
	private static final Object UNBOUNDED = new Object();

	//RB Tree的颜色变量
	private static final boolean RED   = false;
    private static final boolean BLACK = true;

构造方法

共有四个构造方法：

HashMap源码分析

Sun, 02 Aug 2020 17:15:18 +0000

概述

Java中对于Map数据结构，提供了java.util.Map接口，该接口下主要有四个常见的实现类，分别是：

HashMap：根据key.hashCode计算存储位置，能在$O(1)$完成查询，但是遍历顺序是不确定的，HashMap最多存储一个键为null，允许多条entry的值为null。HashMap非线程安全。
HashTable：线程安全的Map，常用方法全部通过synchronized保证线程安全，可以使用ConcurrentHashMap达到目的，此类不建议使用。
LinkedHashMap：继承自HashMap，内部通过双向链表将所有entry连接起来，保证了迭代顺序和插入顺序相同。
TreeMap：实现了SortedMap接口，能够将保存的记录按照键排序。内部通过红黑树进行存储。

HashMap在JDK 7中采用了数组+链表的数据结构，在JDK 8后，底层数据结构转变为：数组+链表+红黑树，也就是当出现Hash冲突时，当链表长度大于阈值(或者红黑树的边界值，默认为8)并且当前数组的长度大于64，链表会转为红黑树存储节点提高搜索效率。

public class HashMap<K,V> extends AbstractMap<K,V> implements Map<K,V>, Cloneable, Serializable

HashMap 继承了 AbstractMap ，该类提供了Map接口的抽象实现，并提供了一些方法的基本实现。实现了 Map、Cloneable和 Serializable接口。

成员变量

loadFactor：该变量控制table数组存放数据的疏密程度，越趋向1时，数组中存放的数据越多越密。链表的长度会增加，因此会导致查找效率变低。该值越小，则数组中存放的数据越少，越稀疏，则会导致空间利用率下降。默认值0.75是较好的默认值，可以最大程度减少rehash的次数，避免过多的性能消耗。
threshold：当前 HashMap所能容纳键值对数量的最大值，超过这个值，则需扩容。threshold = capacity * loadFactor
- 默认容量为16，默认负载因子为0.75，当size达到16 * 0.75 = 12时，需要进行扩容(resize)，即默认扩容阈值为12。
- 扩容倍数为：2倍
DEFAULT_INITIAL_CAPACITY：默认初始容量为16
table：存储Node的数组，链表状态下的节点。
- length大小必须为2的n次方，减少hash冲突的现象。
entrySet：存储entry的set集合
size：实际存储的键值对数量
modCount：对map结构操作的次数。
TREEIFY_THRESHOLD：转为红黑树的链表节点阈值（条件之一）。
MIN_TREEIFY_CAPACITY：树化的数组长度阈值（条件之一）。
UNTREEIFY_THRESHOLD：树退化成链表的阈值。

	//存储元素的数组，大小为2的幂次
	transient Node<K,V>[] table;

	//存放具体元素的集合
    transient Set<Map.Entry<K,V>> entrySet;

	//已经存放了的数组大小
    transient int size;

	//结构修改的计数器
    transient int modCount;

	//临界值，实际大小超过该值，则进行扩容
    int threshold;

	//负载因子
    final float loadFactor;

	//默认初始容量：16
	static final int DEFAULT_INITIAL_CAPACITY = 1 << 4; // aka 16

	//最大容量
    static final int MAXIMUM_CAPACITY = 1 << 30;

    //默认的负载因子
    static final float DEFAULT_LOAD_FACTOR = 0.75f;

    //链表节点数大于该阈值，转为红黑树存储
    static final int TREEIFY_THRESHOLD = 8;

    //红黑树节点数小于该值，转为链表存储
    static final int UNTREEIFY_THRESHOLD = 6;
	
	//树化时，检查table数组长度是否大于该值，小于则扩容
    static final int MIN_TREEIFY_CAPACITY = 64;

数据结构

链表状态下的节点，继承自Map.Entry<K,V>。

LinkedList源码分析

Sat, 01 Aug 2020 13:59:58 +0000

简介

LinkedList底层采用双向链表结构实现，所以在存储元素功能上，并不需要扩容机制，但是需要额外的空间存储指针，头插和尾插的时间复杂度为O(1)，指定位置插入的时间复杂度为O(n)，LinkedList是非线程安全的集合。

public class LinkedList<E>
    extends AbstractSequentialList<E>
    implements List<E>, Deque<E>, Cloneable, java.io.Serializable
{

LinkedList继承了AbstractSequentialList。该类提供了一套基于顺序访问的接口。

实现了List接口和Deque接口，使得LinkedList同时具备了List和双端队列的特性。

LinkedList实现了Serializable接口，表明ArrayList支持序列化。

LinkedList实现了Cloneable接口，能被克隆。

数据结构

Node节点包括数据，前驱节点和后继节点。

private static class Node<E> {
        E item;
        Node<E> next;
        Node<E> prev;

        Node(Node<E> prev, E element, Node<E> next) {
            this.item = element;
            this.next = next;
            this.prev = prev;
        }
    }

成员变量

分别是链表长度，头节点，尾节点。

transient int size = 0;

transient Node<E> first;

transient Node<E> last;

构造方法

构造方法有两种，注释如下：

	//空构造方法
	public LinkedList() {
    }

    //传入集合，调用addAll进行添加
    public LinkedList(Collection<? extends E> c) {
        this();
        addAll(c);
    }

API

linkFirst

将元素添加到头部。

ArrayList源码分析

Thu, 30 Jul 2020 17:59:58 +0000

简介

ArrayList是List接口的实现类，其底层通过数组实现。当空间不够会通过内部的扩容机制进行扩容。时间复杂度与数组类似，ArrayList是非线程安全的集合，在并发环境下使用会产生错误。

public class ArrayList<E> extends AbstractList<E>
        implements List<E>, RandomAccess, Cloneable, java.io.Serializable

ArrayList继承了AbstractList，实现了List接口，提供了添加、删除、修改、遍历等功能

ArrayList实现了RandomAccess接口，实现该接口表明ArrayList支持快速随机访问。

ArrayList实现了Serializable接口，表明ArrayList支持序列化。

ArrayList实现了Cloneable接口，能被克隆。

成员变量

	//默认初始化大小
    private static final int DEFAULT_CAPACITY = 10;
	
	//传入initialCapacity为0时，elementData指向该变量
    private static final Object[] EMPTY_ELEMENTDATA = {};
	
	//不传initialCapacity时，elementData指向该变量
    private static final Object[] DEFAULTCAPACITY_EMPTY_ELEMENTDATA = {};
	
	//存放数据的数组
    transient Object[] elementData;

    //list大小
    private int size;

构造方法

ArrayList共有三个构造方法。注释如下：

//传递了长度的构造方法
public ArrayList(int initialCapacity) {
    	//边界检查
        if (initialCapacity > 0) {
            this.elementData = new Object[initialCapacity];
        } else if (initialCapacity == 0) {
            this.elementData = EMPTY_ELEMENTDATA;
        } else {
            throw new IllegalArgumentException("Illegal Capacity: "+
                                               initialCapacity);
        }
    }

    //无参构造
    public ArrayList() {
        this.elementData = DEFAULTCAPACITY_EMPTY_ELEMENTDATA;
    }

    //传递集合
    public ArrayList(Collection<? extends E> c) {
        //获取初始值数组
        elementData = c.toArray();
        //如果传入的为非空集合
        if ((size = elementData.length) != 0) {
            // c.toArray可能返回的不是Object[]类型
            if (elementData.getClass() != Object[].class)
                elementData = Arrays.copyOf(elementData, size, Object[].class);
        } else {
            //传递空集合，将elementData指向空数组
            this.elementData = EMPTY_ELEMENTDATA;
        }
    }

API

get

获取对应下标的元素，时间复杂度O(1)

缓存更新策略总结

Sat, 25 Jul 2020 18:12:10 +0000

Cache Aside

具体逻辑如下：

写策略：更DB数据，再删除cache数据
读策略：
- cache hit：直接返回命中数据。
- cache miss：从数据库中读取，然后将数据写入cache，并返回。

适用场景：

适合读多写少的场景，不适合写多的场景。

Read/Write Through

具体逻辑如下：

Read Through：写入时先查询cache是否hit，hit直接返回，miss则有cache组件负责去DB查，并写入cache，再返回。
Write Through：更新先查询cache是否hit，hit则更新缓存中数据，然后有cache组件更新到DB，完成后通知更新完成。若miss则直接更新数据库

Write Back

具体逻辑如下：

只更新缓存，立即返回，持久层更新采用异步更新方式。

广泛用于OS，比如CPU Cache、文件系统Cache，数据非强一致性，存在丢数据的问题。

适用场景：写多场景

Redis内存优化

Mon, 20 Jul 2020 18:12:10 +0000

查看内存使用情况

info memory

used_memory:701520                      redis分配器分配的内存量，也就是实际存储数据的内润使用总量
used_memory_human:685.08K               以可读格式返回redis使用的内存总量
used_memory_rss:664584                  从操作系统角度，redis进程占用的总物理内存
used_memory_rss_human:649.01K          
used_memory_peak:778480                  内存分配器分配的最大内存，代表`used_memory`的历史峰值
used_memory_peak_human:760.23K          以可读的格式显示内存的消耗峰值
total_system_memory:0
total_system_memory_human:0B
used_memory_lua:37888                   Lua引擎消耗的内存
used_memory_lua_human:37.00K
maxmemory:0
maxmemory_human:0B
maxmemory_policy:noeviction
mem_fragmentation_ratio:0.95            内存碎片率，used_memory_rss/used_memory
mem_allocator:jemalloc-3.6.0            redis使用的内存分配器

内存划分

Redis中使用的内存可分为如下几类：

自身内存：自身维护的数据字典等元数据，占用较少
对象内存：存储的所有entry对象
缓存：客户端缓冲区+AOF缓冲区等
Lua内存：用于加载Lua脚本
子进程内存：一般是持久化时fork出来的子进程占用的内存
运行内存：运行时消耗的内存
内存碎片：Redis使用jemalloc来分配内存，按照固定大小划分，当删除数据后，释放的内存不会立即返回给OS，Redis无法有效利用，因此形成碎片。

内存优化方案

对象内存

Redis中对象大多有两种存储方案，尽量将大小控制在较为节省的存储阈值之内。

客户端缓冲区

客户端缓冲区占用内存较大的原因如下：

client访问大key，导致client输出缓存异常增长。
client使用monitor命令，它会将所有访问redis的命令持续放到输出缓冲区，导致输出缓冲区异常增长。
clinet使用pipeline封装了大量命令
从节点复制慢，导致主节点输出缓冲区积压。

优化方案:

大key需要进行拆分
尽量避免使用monitor等指令
使用pipeline设置最大阈值
主从复制区设置阈值

内存碎片

手动执行memory purge命令
通过配置参数进行控制

activedefrag yes：启用自动碎片清理开关
active-defrag-ignore-bytes 100mb：内存碎片空间达到多少才开启碎片整理
active-defrag-threshold-lower 10：碎片率达到百分之多少才开启碎片整理
active-defrag-threshold-upper 100：内存碎片率超过多少，则尽最大努力整理（占用最大资源去做碎片整理）
active-defrag-cycle-min 25：内存自动整理占用资源最小百分比
active-defrag-cycle-max 75：内存自动整理占用资源最大百分比

子进程优化

Linux中的fork使用了copy on write机制，fork之后与父进程共享内存空间，只有发生写操作修改内存数据时，才会真正分配内存空间。

其他注意事项

键值生命周期

周期数据需要设置过期时间，object idle time可以找垃圾key-value
过期时间不宜集中，会导致缓存穿透和雪崩等问题

命令使用技巧

O(n)以上命令关注n的数量
- hgetall,lrange,smembers,zrange,sinter等
禁用命令
- 禁止线上使用keys,flushall,flushdb，通过redis的rename机制禁用掉命令，或者使用scan的方式渐进式处理
合理使用select
- redis的多数据库较弱，使用数字进行区分
- 很多客户端支持较差
- 同时多业务用多数据库实际上还是单线程处理，会有干扰
redis的事务功能较弱，不建议过多使用
- 不支持回滚
redis集群版本在使用Lua上有特殊要求
- 所有的key，必须爱一个slot上，否则返回error
必要情况下使用monitor命令时，注意不要长时间使用

Redis集群机制分析

Mon, 13 Jul 2020 18:12:10 +0000

主从复制模式

Redis集群实现数据同步，保证服务高可用。

一主多从
数据流向是单向的，master->slave

开启指令：

slaveof 192.168.1.10 6379		//当前服务节点称为指定IP的从节点
slaveof no one                  //取消从属关系

配置文件：

slaveof ip port
slave-read-only yes             //从节点只读

全量复制的开销：

bgsave的时间
RDB文件网络传输时间
从节点清空数据时间
从节点加载RDB的时间
可能的AOF重写时间

实现

Redis复制分为同步和命令传播两个操作：

同步：将从服务器的数据库状态更新为主库状态
命令传播：同步完后，主库状态又发生变化，此时使用命令传播完成状态同步。

Redis使用PSYNC可以同时解决全量复制和部分复制两种情况。

需要维护的变量包括：

runID：每个Redis实例启动生成的随机ID
offset：复制进度

执行slaveof时，slave节点会将master的地址保存在：

struct redisServer {
    char *masterhost;
    int masterport;
}

slave节点会将该命令封装成通信协议并发给master，完成socket建立，并发送PING检查socket是否正常。

心跳检测

命令传播的阶段，slave默认每秒一次的频率，向master发送心跳：

REPLCONF ACK <replication_offset>

replication_offset为slave当前的复制偏移量

心跳主要有三个作用：

检测主从之间连接状态：节点保活机制
辅助实现min-slaves：防止master在不安全的情况下执行写命令。
- min-slaves-to-write
- min-slaves-max-log
检测命令丢失：如果因为网络原因产生命令丢失，master发现slave的offset小于自己当前offset，则认为产生命令丢失，并按照slave的offset传递数据。

sentinel机制

主从复制存在的问题

手动故障转移：master发生宕机，需要手动切换
写能力和存储能力受限

Sentinel（机制）是Redis官方推荐的高可用性(HA)解决方案，由一个或多个sentinel组成的sentinel system，可以监视主从集群的状态，当master发生宕机，自动将master下面的某个slave升级为新的master。

启动

./redis-sentinel /path/to/sentinel.conf

启动流程会执行以下步骤：

初始化server：sentinel本质上是一个运行在特殊模式的Redis服务器。
代码：sentinel使用sentinel.c/REDIS_SENTINEL_PORT作为默认端口，使用sentinel.c/sentinelcmds作为命令表
初始化sentinel状态：sentinel.c/sentinelState结构
根据配置文件，初始化sentinel监视的主服务器列表：上面的结构使用dict保存master信息，key为master的名称，value为master对应的sentinel.c/sentinelRedisInstance，每个被监视的Redis服务器实例都被使用该结构存储。master的IP端口信息使用struct sentinelAddr进行存储。该数据sentinel初始化时从sentinel.conf完成加载。
创建连向master的socket连接：sentinel节点对master创建两个异步连接：
- 命令连接：专门向master发送命令，并接收回复
- 订阅连接：订阅master的__sentinel__:hello频道，用于sentinel发现其他sentinel节点

获取信息

每10s每个sentinel会对master发送info命令，sentinel主要获取两方面信息：

Redis持久化机制分析

Sun, 12 Jul 2020 17:54:10 +0000

简介

Redis数据保存在内存中，为了防止进程异常退出而导致数据丢失，可以考虑将数据保存到磁盘上。

Redis提供的两种持久化方案：

RDB：直接将数据库状态写到文件，既可以手动执行，也可以配置为定期执行。
AOF：将写命令append到AOF文件中。

RDB

两种方案：

save：直接执行
bgsave：fork一个子进程执行

rdbSave是save的具体实现函数，bgsave与其区别是通过fork子进程完成备份，并在完成后给父进程发送信号。

int rdbSave(char *filename) {
    dictIterator *di = NULL;
    dictEntry *de;
    char tmpfile[256];
    char magic[10];
    int j;
    long long now = mstime();
    FILE *fp;
    rio rdb;
    uint64_t cksum;

    // 创建临时文件
    snprintf(tmpfile,256,"temp-%d.rdb", (int) getpid());
    fp = fopen(tmpfile,"w");
    if (!fp) {
        redisLog(REDIS_WARNING, "Failed opening .rdb for saving: %s",
            strerror(errno));
        return REDIS_ERR;
    }

    // 初始化 I/O
    rioInitWithFile(&rdb,fp);

    // 设置校验和函数
    if (server.rdb_checksum)
        rdb.update_cksum = rioGenericUpdateChecksum;

    // 写入 RDB 版本号
    snprintf(magic,sizeof(magic),"REDIS%04d",REDIS_RDB_VERSION);
    if (rdbWriteRaw(&rdb,magic,9) == -1) goto werr;

    // 遍历所有数据库
    for (j = 0; j < server.dbnum; j++) {

        // 指向数据库
        redisDb *db = server.db+j;

        // 指向数据库键空间
        dict *d = db->dict;

        // 跳过空数据库
        if (dictSize(d) == 0) continue;

        // 创建键空间迭代器
        di = dictGetSafeIterator(d);
        if (!di) {
            fclose(fp);
            return REDIS_ERR;
        }

        /* Write the SELECT DB opcode 
         *
         * 写入 DB 选择器
         */
        if (rdbSaveType(&rdb,REDIS_RDB_OPCODE_SELECTDB) == -1) goto werr;
        if (rdbSaveLen(&rdb,j) == -1) goto werr;

        /* Iterate this DB writing every entry 
         *
         * 遍历数据库，并写入每个键值对的数据
         */
        while((de = dictNext(di)) != NULL) {
            sds keystr = dictGetKey(de);
            robj key, *o = dictGetVal(de);
            long long expire;
            
            // 根据 keystr ，在栈中创建一个 key 对象
            initStaticStringObject(key,keystr);

            // 获取键的过期时间
            expire = getExpire(db,&key);

            // 保存键值对数据
            if (rdbSaveKeyValuePair(&rdb,&key,o,expire,now) == -1) goto werr;
        }
        dictReleaseIterator(di);
    }
    di = NULL; /* So that we don't release it again on error. */

    /* EOF opcode 
     *
     * 写入 EOF 代码
     */
    if (rdbSaveType(&rdb,REDIS_RDB_OPCODE_EOF) == -1) goto werr;

    /* CRC64 checksum. It will be zero if checksum computation is disabled, the
     * loading code skips the check in this case. 
     *
     * CRC64 校验和。
     *
     * 如果校验和功能已关闭，那么 rdb.cksum 将为 0 ，
     * 在这种情况下， RDB 载入时会跳过校验和检查。
     */
    cksum = rdb.cksum;
    memrev64ifbe(&cksum);
    rioWrite(&rdb,&cksum,8);

    /* Make sure data will not remain on the OS's output buffers */
    // 冲洗缓存，确保数据已写入磁盘
    if (fflush(fp) == EOF) goto werr;
    if (fsync(fileno(fp)) == -1) goto werr;
    if (fclose(fp) == EOF) goto werr;

    /* Use RENAME to make sure the DB file is changed atomically only
     * if the generate DB file is ok. 
     *
     * 使用 RENAME ，原子性地对临时文件进行改名，覆盖原来的 RDB 文件。
     */
    if (rename(tmpfile,filename) == -1) {
        redisLog(REDIS_WARNING,"Error moving temp DB file on the final destination: %s", strerror(errno));
        unlink(tmpfile);
        return REDIS_ERR;
    }

    // 写入完成，打印日志
    redisLog(REDIS_NOTICE,"DB saved on disk");

    // 清零数据库脏状态
    server.dirty = 0;

    // 记录最后一次完成 SAVE 的时间
    server.lastsave = time(NULL);

    // 记录最后一次执行 SAVE 的状态
    server.lastbgsave_status = REDIS_OK;

    return REDIS_OK;

werr:
    // 关闭文件
    fclose(fp);
    // 删除文件
    unlink(tmpfile);

    redisLog(REDIS_WARNING,"Write error saving DB on disk: %s", strerror(errno));

    if (di) dictReleaseIterator(di);

    return REDIS_ERR;
}

RDB载入还原

Redis对RDB文件的载入还原步骤如下：

MySQL体系结构和存储引擎

Sat, 11 Jul 2020 16:25:46 +0000

体系结构

MySQL体系结构如图所示：

分别由Client Connectors层、MySQL Server层以及存储引擎层组成。

Client Connectors层：负责处理客户端的连接请求，与客户端创建连接。
MySQL Server层：
- Connection Pool：负责处理和存储数据库与客户端创建的连接，一个线程负责管理一个连接，包括了用户认证模块，就是用户登录身份的认证和鉴权以及安全管理
- Service & utilities：管理服务&工具集，包括备份恢复、安全管理、集群管理、工具
- SQL interface：负责接受客户端发送的各种语句
- Parser：对SQL语句进行语法解析生成解析树
- Optimizer：查询优化器会根据解析树生成执行计划，并选择合适的索引，然后按照执行计划执行SQL并与各个存储引擎交互
- Caches：包括各个存储引擎的缓存部分，例如InnoDB的Buffer Pool
存储引擎层：包括InnoDB，MyISAM以及支持归档的Archive和内存的Memory
存储引擎底部是物理存储层，包括二进制日志，数据文件，错误日志，慢查询日志，全日志，redo/undo日志

一条SQL语句的执行过程可以参照如下图示：

与MySQL建立连接。
查询缓存，如果开启了Query。 Cache并且查询缓存中存在该查询语句，则直接将结果返回到客户端，没有开启或缓存未命中则由解析器进行语法语义解析，并生成解析树。
预处理器生成新的解析树。
查询优化器进行优化。
查询执行引擎执行SQL，通过API接口查询物理存储层的数据，并返回结果。

其中，查询缓存于MySQL 8.0中移除，具体原因：查询缓存往往弊大于利。查询缓存的失效非常频繁，只要有对一个表的更新，这个表上的所有的查询缓存都会被清空。

MySQL官方博客关于该技术移除的解释https://mysqlserverteam.com/mysql-8-0-retiring-support-for-the-query-cache/

存储引擎

在 MySQL 5.6 版本之前，默认的存储引擎都是 MyISAM，但 5.6 版本以后默认的存储引擎就是 InnoDB。

InnoDB上半部分是实例层，位于内存中，下半部分是物理层，位于文件系统中。其中实例层分为线程和内存，InnoDB中重要的线程有Master Thread（主线程），其优先级最高，主要负责调度其他线程，其内部有几个循环：主循环，后台循环，刷新循环，暂停循环，Master Thread 会根据其内部运行的相关状态在各循环间进行切换。

大部分操作在主循环中完成，其包含1s和10s两种操作：

1s操作
- 日志缓冲刷新到磁盘（即使事务未提交，也被执行）
- 最多可以刷100个新脏页到磁盘
- 执行并改变缓冲的操作
- 若当前没有用户活动，可以切换到后台循环
10s操作
- 最多可以刷新100个脏页到磁盘
- 合并至多5个被改变的缓冲
- 日志缓冲刷新到磁盘
- 删除无用的Undo页
- 刷新100个或10个脏页到磁盘，产生一个检查点
- buf_dump_thread 负责将 buffer pool 中的内容 dump 到物理文件中，以便再次启动 MySQL 时，可以快速加热数据。
- page_cleaner_thread 负责将 buffer pool 中的脏页刷新到磁盘，在 5.6 版本之前没有这个线程，刷新操作都是由主线程完成的，所以在刷新脏页时会非常影响 MySQL 的处理能力，在5.7 版本之后可以通过参数设置开启多个 page_cleaner_thread。
- purge_thread 负责将不再使用的 Undo 日志进行回收。
- read_thread 处理用户的读请求，并负责将数据页从磁盘上读取出来，可以通过参数设置线程数量。
- write_thread 负责将数据页从缓冲区写入磁盘，也可以通过参数设置线程数量，page_cleaner 线程发起刷脏页操作后 write_thread 就开始工作了。
- redo_log_thread 负责把日志缓冲中的内容刷新到 Redo log 文件中。
- insert_buffer_thread 负责把 Insert Buffer 中的内容刷新到磁盘。实例层的内存部分主要包含 InnoDB Buffer Pool，这里包含 InnoDB 最重要的缓存内容。数据和索引页、undo 页、insert buffer 页、自适应 Hash 索引页、数据字典页和锁信息等。additional memory pool 后续已不再使用。Redo buffer 里存储数据修改所产生的 Redo log。double write buffer 是 double write 所需的 buffer，主要解决由于宕机引起的物理写入操作中断，数据页不完整的问题。

物理层在逻辑上分为系统表空间、用户表空间和Redo日志。

Redis对象机制分析

Sat, 11 Jul 2020 08:12:54 +0000

简介

Redis中提供的数据结构都使用了下面的redisObject进行包装，通过包装可以提供不同场景下使用不同的数据结构的实现。Redis的对象机制还使用了引用计数方式的内存回收机制。

typedef struct redisObject {

    // 类型
    unsigned type:4;

    // 编码
    unsigned encoding:4;

    // 对象最后一次被访问的时间
    unsigned lru:REDIS_LRU_BITS; /* lru time (relative to server.lruclock) */

    // 引用计数
    int refcount;

    // 指向实际值的指针
    void *ptr;

} robj;

type值可选：

#define REDIS_STRING 0
#define REDIS_LIST 1
#define REDIS_SET 2
#define REDIS_ZSET 3
#define REDIS_HASH 4

encoding可选：

#define REDIS_ENCODING_RAW 0     /* Raw representation */
#define REDIS_ENCODING_INT 1     /* Encoded as integer */
#define REDIS_ENCODING_HT 2      /* Encoded as hash table */
#define REDIS_ENCODING_ZIPMAP 3  /* Encoded as zipmap */
#define REDIS_ENCODING_LINKEDLIST 4 /* Encoded as regular linked list */
#define REDIS_ENCODING_ZIPLIST 5 /* Encoded as ziplist */
#define REDIS_ENCODING_INTSET 6  /* Encoded as intset */
#define REDIS_ENCODING_SKIPLIST 7  /* Encoded as skiplist */
#define REDIS_ENCODING_EMBSTR 8  /* Embedded sds string encoding */

结构的编码方案

String

编码策略如下：

Redis过期删除策略与内存淘汰机制

Fri, 10 Jul 2020 13:12:24 +0000

过期删除策略

过期删除策略主要有以下三种：

定时删除：设置过期时间的同时，创建一个定时器，当到达过期时间后，执行删除操作。
- 优点：对内存友好，不会长时间占用内存
- 缺点：对CPU不友好，当过期entry过多会占用大量CPU时间，并且创建定时器存在性能消耗。
惰性删除：每次查询到该entry时，检查是否过期，若过期就删除，否则返回。
- 优点：对CPU友好
- 缺点：无用数据占用大量内存空间，依赖于客户端请求对过期数据进行删除。有内存泄漏的风险。
定期删除：每隔一段时间对数据库进行检查，删除其中的过期entry。
- 综合考虑上述策略的优缺点，可以合理设置执行时长和频率。

Redis中主要配合使用惰性删除和定期删除两种策略，在内存和CPU性能中取得平衡。使用过期字典存储所有key的过期时间。key是一个指针，指向key对象，value是一个long long类型的整数，保存key的过期时间。

实现：

惰性删除：db.c/expireIfNeeded在读写之前对key进行检查.
定期删除：redis.c/activeExpireCycle实现，每当Redis的serverCron执行时，都会主动清除过期数据。
- activeExpireCycle的工作流程如下：
  - 每次取出一定数量的随机key进行检查，并删除其中的过期数据
  - 全局变量current_db存储当前的检查进度（db编号），并且下次activeExpireCycle执行会接着上次进度进行处理。全部检查完毕后该变量置为0。

内存淘汰策略

当Redis的运行内存已经超过设置的最大内存时，会使用内存淘汰策略删除符合相关条件的key。最大内存通过设置maxmemory <bytes>即可。默认为0，表示没有内存大小的限制。

Redis的内存淘汰策略如下：

不淘汰
- noeviction：不淘汰任何数据、直接返回错误。
对设置了过期时间的数据进行淘汰
- volatile-random：随意淘汰设置了过期时间的任意entry。
- volatile-ttl：优先淘汰更早过期的entry。
- volatile-lru：淘汰所有设置了过期时间的entry中最近最久未使用的entry。
- volatile-lfu：淘汰所有设置了过期时间的entry中最少使用的entry。
对全部数据进行淘汰
- allkeys-random：随即淘汰任意entry。
- allkeys-lru：使用LRU策略淘汰任意entry。
- allkeys-lfu：使用LFU策略淘汰任意entry。

修改redis.conf中的maxmemory-policy <策略>即可。

Redis基础知识总结

Thu, 09 Jul 2020 17:06:33 +0000

Redis简介

Redis特性

速度快（内存，10w QPS, C , 单线程）
持久化（将内存数据异步更新到磁盘,RDB&AOF）
多种数据结构（string list set zset hash BitMaps HyperLogLog GEO）
支持多语言
功能丰富（发布订阅事务 Lua脚本 pipeline）
简单（23000 lines of code 不依赖外部库单线程模型）
主从复制

单线程为什么这么快？

纯内存
非阻塞IO，使用多路复用机制，提升连接并发度。
避免多线程切换和竞态消耗

Redis典型应用场景

缓存系统（缓存）
计数器（微博转发和评论）
消息队列系统
排行榜
社交网络
实时系统（垃圾邮件–布隆过滤器）

Redis可执行文件说明

redis-server      --->    Redis服务器
redis-cli         --->    Redis客户端
redis-benchmark   --->    Redis性能测试
redis-check-aof   --->    AOF文件修复
redis-check-dump  --->    RDB文件检查
redis-sentinel    --->    Sentinel服务器

Redis 通用API

keys                --->    遍历所有key，热备从节点         O(n)
dbsize              --->    计算key的总数                   O(1)
exist key           --->    检查key是否存在，返回0或1       O(1)
del key             --->    删除指定的key                   O(1)
expire key seconds  --->    key在seconds秒后过期            O(1)         
ttl key             --->    查看key的剩余过期时间           O(1) 
persist key         --->    去掉key的过期时间               O(1) 
type key            --->    查看当前key的类型               O(1)

常见数据结构

String应用场景：字符串缓存、计数器、分布式锁

Redis底层数据结构-Stream源码分析

Sat, 27 Jun 2020 14:21:30 +0000

简介

Redis在5.0.0版本中引进了消息队列的功能，该功能由Stream实现，本文主要介绍Stream的相关实现。

数据结构

stream

Stream的实现依赖于Rax树与listpack结构，每个消息流都包含一个Rax树，以消息ID为key，listpack为value存储在Rax树中。其基本结构如下：

rax：rax存储生产者生产的具体消息，每个消息有唯一ID为键
length：代表当前stream中消息个数。
last_id：为当前stream中最后插入的消息ID，stream为空时，该值为0。
cgroups：存储了当前stream相关的消费组，以消费组组名为键，streamCG为值存储在rax中。

typedef struct stream {
    rax *rax;               /* The radix tree holding the stream. */
    uint64_t length;        /* Number of elements inside this stream. */
    streamID last_id;       /* Zero if there are yet no items. */
    rax *cgroups;           /* Consumer groups dictionary: name -> streamCG */
} stream;

一个Stream的基本结构如图所示：

每一个listpack都有一个master entry，该结构存储了该listpack待插入消息的所有field。

streamID

消息ID的基本结构如下：

ms：消息创建时的时间
seq：序号

typedef struct streamID {
    uint64_t ms;        /* Unix time in milliseconds. */
    uint64_t seq;       /* Sequence number. */
} streamID;

streamCG

每个stream会有多个消费组，每个消费组通过组名称进行唯一标识，同时关联一个streamCG结构。该结构如下：

Redis底层数据结构-Quicklist源码分析

Thu, 25 Jun 2020 10:34:21 +0000

简介

quicklist是Redis 3.2中引入的数据结构，其本质是一个双向链表，链表的节点类型是ziplist，当ziplist节点过多，quicklist会退化成双向链表，以提高效率。

数据结构

quicklistNode

该结构为节点类型。

prev：指向前驱节点
next：指向后继节点
zl：指向对应的压缩列表
sz：压缩列表的大小
encoding：采用的编码方式，1为原生，2代表使用LZF进行压缩
container：为节点指向的容器类型，1代表none，2代表ziplist存储数据
recompress：代表这个节点是否是压缩节点，如果是，则使用压缩节点前先进行解压缩，使用后重新压缩
attempted_compress：测试时使用

typedef struct quicklistNode {
    struct quicklistNode *prev;
    struct quicklistNode *next;
    unsigned char *zl;
    unsigned int sz;             /* ziplist size in bytes */
    unsigned int count : 16;     /* count of items in ziplist */
    unsigned int encoding : 2;   /* RAW==1 or LZF==2 */
    unsigned int container : 2;  /* NONE==1 or ZIPLIST==2 */
    unsigned int recompress : 1; /* was this node previous compressed? */
    unsigned int attempted_compress : 1; /* node can't compress; too small */
    unsigned int extra : 10; /* more bits to steal for future usage */
} quicklistNode;

quicklistLZF

如果使用LZF算法进行压缩，节点指向的结构为quicklistLZF，其中sz表示compressed数组所占用字节大小。

Redis底层数据结构-Intset源码分析

Sat, 20 Jun 2020 15:28:27 +0000

简介

Intset是一个有序的，存储Integer类型数据的结构，当元素为64位有符号整数范围之内时，它是Redis数据结构中有序集合ZSET的底层实现，但是当元素个数超过一定数量时（默认为512），会转为hashtable进行存储，由配置项set-max-intset-entries 512决定。如果向有序集合中添加非整型变量，底层实现也会装欢为hashtable。

数据结构

intset结构如下：


#define INTSET_ENC_INT16 (sizeof(int16_t))
#define INTSET_ENC_INT32： (sizeof(int32_t))
#define INTSET_ENC_INT64 (sizeof(int64_t))

typedef struct intset {
    uint32_t encoding;
    uint32_t length;
    int8_t contents[];
} intset;

各字段含义：

encoding：编码类型，决定每个元素占用几个字节
- INTSET_ENC_INT16：当元素大小位于INT16_MIN和INT16_MAX之间使用，每个元素占用两个字节。
- INTSET_ENC_INT32：元素大小位于INT16_MAX和INT32_MAX之间或INT32_MIN到INT16_MIN之间，该编码方式占用四个字节。
- INTSET_ENC_INT64：元素大小位于INT32_MAX到INT64_MAX或INT64_MIN到INT32_MIN之间，该编码方式每个元素占用八个字节。
length：元素个数
contents：存储具体元素的数组，从小到大排序，并且不包含任何重复项

当添加的新元素比集合里面所有元素类型都长时，集合需要整体进行upgrade，然后完成添加。

接口

intsetFind

查找算法主要通过二分查找实现。

/* Determine whether a value belongs to this set */
uint8_t intsetFind(intset *is, int64_t value) {
    //判断编码方式
    uint8_t valenc = _intsetValueEncoding(value);
    //编码方式如果当前intset的编码方式，直接返回0
    //否则调用intsetSearch函数进行查找
    return valenc <= intrev32ifbe(is->encoding) && intsetSearch(is,value,NULL);
}


static uint8_t intsetSearch(intset *is, int64_t value, uint32_t *pos) {
    int min = 0, max = intrev32ifbe(is->length)-1, mid = -1;
    int64_t cur = -1;

    /* The value can never be found when the set is empty */
    //intset如果为空，直接返回0
    if (intrev32ifbe(is->length) == 0) {
        if (pos) *pos = 0;
        return 0;
    } else {
        当前元素如果大于当前有序集合最大值或者小于最小值，直接返回0
        if (value > _intsetGet(is,max)) {
            if (pos) *pos = intrev32ifbe(is->length);
            return 0;
        } else if (value < _intsetGet(is,0)) {
            if (pos) *pos = 0;
            return 0;
        }
    }
    //由于集合有序，采用二分查找
    while(max >= min) {
        mid = ((unsigned int)min + (unsigned int)max) >> 1;
        cur = _intsetGet(is,mid);
        if (value > cur) {
            min = mid+1;
        } else if (value < cur) {
            max = mid-1;
        } else {
            break;
        }
    }

    if (value == cur) {
        if (pos) *pos = mid;
        return 1;
    } else {
        if (pos) *pos = min;
        return 0;
    }
}

intsetAdd

主要逻辑如下：

Redis底层数据结构-Dict源码分析

Fri, 29 May 2020 18:30:20 +0000

简介

字典是一种用来存储键值对的数据结构。Redis本身就是KV型数据库，整个数据库就是用字典进行存储的，对Redis的增删改查操作，实际上就是对字典中的数据进行增删改查操作。

数据结构

HashTable

table：指针数组，用于存储键值对，指向的是dictEntry结构体，每个dictEntry存有键值对
size：table数组的大小
sizemask：掩码，用来计算键的索引值。值恒为size -1
used：table数组已存键值对个数

Hash表的数组容量初始值为4，扩容倍数为当前一倍，所以sizemask大小为3,7,11,31，二进制表示为111111...，在计算索引值时，首先计算hash值，通过hash = dict-> type->hashFunction(k0)得到对应hash。再通过idx = hash & d->dt[table].sizemask计算entry存储的索引位置，位运算速度快于取余运算，Redis使用链地址法来解决hash冲突问题。

typedef struct dictht {
    dictEntry **table;
    unsigned long size;
    unsigned long sizemask;
    unsigned long used;
} dictht;

rehash

hashtable一般需要将负载因子维护在一个合理的范围，使得其达到最大的操作效率，当键值对数量太多或太少时，都需要对hashtable进行相应的扩展或缩容。rehash动作是分批次、渐进式完成的，这是为了避免rehash对server性能造成影响。

Redis进行rehash的执行步骤如下：

为ht[1]分配空间，空间大小取决于ht[0]包含的键值对数量。
将所有保存在ht[0]的键值对rehash到ht[1]上，即重新计算对应hash和index，并存储在ht[1]
释放ht[0]空间，将ht[1]设置为ht[0]，并在ht[1]新建一个空白hashtable，为下一次rehash服务。

在渐进式rehash过程中，查询等操作同时使用两个hashtable。

dictEntry

键值对节点，存放键值对数据。

typedef struct dictEntry {
    //键
    void *key;
    union {
        //存储值
        void *val;
        uint64_t u64;
        //存储过期时间
        int64_t s64;
        double d;
    } v;//值，联合体
    //next指针，Hash冲突时的单链表法
    struct dictEntry *next;
} dictEntry;

dictType

存放的是对字典操作的函数指针

typedef struct dictType {
    //Hash函数，默认使用MurmurHash2算法来计算hash值
    uint64_t (*hashFunction)(const void *key);
    //键对应的复制函数
    void *(*keyDup)(void *privdata, const void *key);
    //值对应的复制函数
    void *(*valDup)(void *privdata, const void *obj);
    //键的比对函数
    int (*keyCompare)(void *privdata, const void *key1, const void *key2);
    //键的销毁函数
    void (*keyDestructor)(void *privdata, void *key);
    //值得销毁函数
    void (*valDestructor)(void *privdata, void *obj);
} dictType;

dict

type：字典操作函数指针，指向一个dictType结构的指针
privdata：私有数据，配合tyoe指针指向的函数一起使用
ht：大小为2的数组，默认使用ht[0]，当字典扩容缩容时进行rehash时，才会用到ht[1]
rehashidx：标记该字典是否在进行rehash，没进行为-1，用来记录rehash到了哪个元素，值为下标值
iterators：用来记录当前运行的安全迭代器数，当有安全迭代器，会暂停rehash

基本结构图如图所示：

Redis底层数据结构-ZipList源码分析

Tue, 26 May 2020 16:58:29 +0000

简介

压缩列表（ziplist）的本质是一个字节数组，主要是Redis为了节省内存而设计的数据结构。在Redis的list和hash都使用了ziplist，当list或hash的元素个数比较少，并且元素都是短字符串或小整数值时，使用ziplist作为其底层数据结构。

压缩列表的基本结构基本如下所示：

<zlbytes> <zltail> <zllen> <entry> <entry> ... <entry> <zlend>

uint32_t zlbytes：压缩列表的字节长度，占4个字节
uint32_t zltail：压缩列表尾元素相对于起始地址的偏移量，占4个字节，方便从列表尾部进行操作
uint16_t zllen：元素个数，占2个字节，元素个数无法超过2^16-1，只能通过遍历整个列表才能获取到个数
uint8_t zlend：列表的结尾元素，占1个字节，值为255（0xff）
entry：列表的元素，可以是字节数组或者整数
- prevlen：表示前一个元素的字节长度，1~5个字节表示，当前一个元素长度小于254字节，用1个字节表示，大于或等于254字节时，用5个字节表示，该情况下，第一个字节为0xFE，剩余4个字节表示真正长度
- encoding：表示当前元素的编码，编码表示当前存储的是字节数组还是整数
- entry：存储数据内容

encoding选项：

#define ZIP_STR_06B (0 << 6)
#define ZIP_STR_14B (1 << 6)
#define ZIP_STR_32B (2 << 6)
#define ZIP_INT_16B (0xc0 | 0<<4)
#define ZIP_INT_32B (0xc0 | 1<<4)
#define ZIP_INT_64B (0xc0 | 2<<4)
#define ZIP_INT_24B (0xc0 | 3<<4)
#define ZIP_INT_8B 0xfe

下面是一个包含两个元素的ziplist，存储的数据为字符串“2”和“5”。它由15个字节组成

   [0f 00 00 00] [0c 00 00 00] [02 00] [00 f3] [02 f6] [ff]
         |             |          |       |       |     |
      zlbytes        zltail    entries   "2"     "5"   end

Redis通过宏定义来对以上部分进行快速定位，zl为压缩列表首地址指针。

Redis底层数据结构-SkipList源码分析

Mon, 25 May 2020 21:31:00 +0000

简介

跳表(SkipList)通过对有序链表添加多级索引，从而实现类似于二分查找效果的有序链表，它的插入/删除/搜索的平均时间复杂度为O(log n)，该数据结构可以用来代替平衡树以提高效率。其基本结构如下图所示：

如果此时查找51的节点，步骤基本如下：

从第二层开始查找，1比51小，向后比较
21比51小，21后面为NULL，下降到第一层的21先后比较
第一层中21的next节点为41，41比51小，41的next节点61比51大，下降到第0层比较
41的next节点为51，查找完成。

数据结构

zskiplistNode：

ele：存储SDS类型的数据
score：排序用的分值
backward：后退指针，指向当前节点最底层的前驱节点，第一个指向NULL
level：数组，它的长度在生成时随机生成一个1 ~ 64的值，值越大出现概率越低
- forward：指向本层的下一个节点，尾节点指向NULL
- span：指向的节点与本节点之间的元素个数

zskiplist：

header：指向跳表的头节点
tail：指向跳表的尾节点
length：跳表的长度
level：跳表的高度

/* ZSETs use a specialized version of Skiplists */
typedef struct zskiplistNode {
    sds ele;
    double score;
    struct zskiplistNode *backward;
    struct zskiplistLevel {
        struct zskiplistNode *forward;
        unsigned long span;
    } level[];
} zskiplistNode;

typedef struct zskiplist {
    struct zskiplistNode *header, *tail;
    unsigned long length;
    int level;
} zskiplist;

typedef struct zset {
    dict *dict;
    zskiplist *zsl;
} zset;

接口

zslCreate

zslCreateNode

/* Create a skiplist node with the specified number of levels.
 * The SDS string 'ele' is referenced by the node after the call. */
zskiplistNode *zslCreateNode(int level, double score, sds ele) {
    //申请内存空间
    zskiplistNode *zn =
        zmalloc(sizeof(*zn)+level*sizeof(struct zskiplistLevel));
    //初始化
    zn->score = score;
    zn->ele = ele;
    return zn;
}

zslCreate

/* Create a new skiplist. */
zskiplist *zslCreate(void) {
    int j;
    //指向跳表的指针
    zskiplist *zsl;
	//申请内存空间
    zsl = zmalloc(sizeof(*zsl));
    //设置默认值
    zsl->level = 1;
    zsl->length = 0;
    //创建头节点
    zsl->header = zslCreateNode(ZSKIPLIST_MAXLEVEL,0,NULL);
    //将头节点的level数组的forward设置为NULL，span设置为0
    for (j = 0; j < ZSKIPLIST_MAXLEVEL; j++) {
        zsl->header->level[j].forward = NULL;
        zsl->header->level[j].span = 0;
    }
    //设置头尾节点
    zsl->header->backward = NULL;
    zsl->tail = NULL;
    return zsl;
}

zslRandomLevel

level最小值为1，最大值为64，该方法随机生成1 ~ 64的值。

Redis底层数据结构-SDS

Sun, 24 May 2020 18:59:27 +0000

简介

简单动态字符串(Simple Dynamic Strings)是Redis的基本数据结构之一，主要用于存储字符串和整型数据。SDS兼容C语言标准字符串处理函数，同时保证了二进制安全。

数据结构

原始版本

在Redis 3.2之前，SDS基本结构如下：

struct {
    //buf中已使用字节数
    int len;
    //buf中剩余字节数
    int free;
    //数据
    char buf[];
}

该结构有如下几个优点：

有单独的变量存储字符串长度，由于有长度，不会依赖于\0终止符，保证二进制安全。
杜绝了缓冲区溢出问题。
获取字符串长度为O(1)
字符串存储在buf数组中，兼容C处理字符串的函数。
减少修改字符串时带来的内存分配次数。
- SDS的空间是预先分配的
- 惰性空间释放：当SDS保存的字符串缩短后，并不会立即将内存空间free

改进

Redis 3.2之后，采用如下结构进行存储。

struct __attribute__ ((__packed__)) sdshdr5 {
    unsigned char flags; /* 3 lsb of type, and 5 msb of string length */
    char buf[];
};
struct __attribute__ ((__packed__)) sdshdr8 {
    uint8_t len; /* used */
    uint8_t alloc; /* excluding the header and null terminator */
    unsigned char flags; /* 3 lsb of type, 5 unused bits */
    char buf[];
};
struct __attribute__ ((__packed__)) sdshdr16 {
    uint16_t len; /* used */
    uint16_t alloc; /* excluding the header and null terminator */
    unsigned char flags; /* 3 lsb of type, 5 unused bits */
    char buf[];
};
struct __attribute__ ((__packed__)) sdshdr32 {
    uint32_t len; /* used */
    uint32_t alloc; /* excluding the header and null terminator */
    unsigned char flags; /* 3 lsb of type, 5 unused bits */
    char buf[];
};
struct __attribute__ ((__packed__)) sdshdr64 {
    uint64_t len; /* used */
    uint64_t alloc; /* excluding the header and null terminator */
    unsigned char flags; /* 3 lsb of type, 5 unused bits */
    char buf[];
};

sdshdr5中采用位来存储相关信息，其中flags占1字节，其中低3位用来表示type，高5位表示长度，所以长度区间为（0 ~ 31），所以长度大于31的字符串需要采用sdshdr8及以上存储。sdshdr8中flags低3位存储类型，剩余5位闲置。以下是字符串类型的宏定义：

设计模式之行为型模式（四）

Sat, 23 May 2020 19:12:51 +0000

模板方法模式

定义一个操作中的算法的框架，而将一些步骤延迟到子类中。使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。

模板方法模式涉及两个角色：

抽象模板角色（Abstract Template）：该角色定义多个抽象操作，以便让子类实现。
具体模板角色（Concrete Template）：该角色实现抽象模板中的抽象方法

public abstract class AbstractClass {
    protected abstract void operation();

    public void templateMethod(){
        this.operation();
    }
}

public class ConcreteClass extends AbstractClass {
    @Override
    protected void operation() {
        //业务
    }
}

public class Client {

    public static void main(String[] args) {
        AbstractClass ac = new ConcreteClass();
        ac.templateMethod();
    }
}

优点：

封装不变的部分，扩展可变部分。不变的部分封装到父类去实现，可变的通过继承进行扩展。
提取公共代码，便于维护，将公共部分的代码抽取出来放在父类中，维护时只需要修改父类中的代码。
行为由父类控制，子类实现。

命令模式

将一个请求封装成一个对象，从而让你使用不同的请求把客户端参数化，对请求排队或者记录请求日志，可以提供命令的撤销和恢复功能。

该模式有四个角色：

命令角色：该角色声明抽象接口
具体命令角色：定义一个接收者和行为之间的弱耦合，实现命令方法，并调用接收者的相应操作。
调用者：负责调用命令对象执行请求。
接收者：该角色负责具体实施和执行一个请求。

public interface Command {

    public void execute();
}

public class ConcreteCommand implements Command {

    private Receiver receiver;

    public ConcreteCommand(Receiver receiver) {
        this.receiver = receiver;
    }

    @Override
    public void execute() {
        this.receiver.action();
    }
}

public class Receiver {

    public void action(){
        System.out.println("执行动作");
    }
}

public class Invoker {

    private Command command;

    public void setCommand(Command command) {
        this.command = command;
    }

    public void action() {
        this.command.execute();
    }
}

优点：

设计模式之结构型模式（三）

Thu, 21 May 2020 17:51:48 +0000

适配器模式

适配器模式将某个类的接口转换成客户端期望的另一个接口表示，主要目的是兼容性，让原本因接口不匹配不能在一起工作的两个类可以协同工作，别名为包装器（Wrapper）。

类适配器

注意：

类适配器需要继承src类，这要求dst必须是接口，有一定的局限性
src类的方法在Adapter中会被暴露出来
Adapter需要重写src的方法

/**
 * @author ：L1nker4
 * @date ： 创建于  2020/5/19 11:40
 * @description： 被适配的类
 */
public class Voltage220V {

    public int output220V(){
        int src = 220;
        System.out.println("电压："+ src + "伏");
        return src;
    }
}

/**
 * 适配接口
 */
public interface IVoltage5V {
    public int output5V();
}

/**
 * @author ：L1nker4
 * @date ： 创建于  2020/5/19 11:42
 * @description： 适配器类
 */
public class VoltageAdapter extends Voltage220V implements IVoltage5V{
    @Override
    public int output5V() {
        int src = output220V();
        return src / 44;
    }
}

/**
 * @author ：L1nker4
 * @date ： 创建于  2020/5/19 11:44
 * @description： 手机类
 */
public class Phone {

    public void charging(IVoltage5V iVoltage5V){
        if (iVoltage5V.output5V() == 5){
            System.out.println("电压为：5V，可以充电");
        }else {
            System.out.println("电压不正常，无法充电");
        }
    }
}

对象适配器

基本思路和类适配器模式相同，只是将Adapter类作修改，不是继承src类，而是持有src类的实例，以解决兼容性的问题，即：持有src类，实现dst接口，完成src->dst的适配。
根据合成复用原则，在系统中使用关联关系替代继承关系。

/**
 * @author ：L1nker4
 * @date ： 创建于  2020/5/19 11:42
 * @description： 适配器类
 */
public class VoltageAdapter implements IVoltage5V {

    private Voltage220V voltage220V;

    public VoltageAdapter(Voltage220V voltage220V) {
        this.voltage220V = voltage220V;
    }

    @Override
    public int output5V() {
        if(null != voltage220V){
            int src = voltage220V.output220V();
            System.out.println("适配完成");
            return src / 44;
        }
        System.out.println("适配失败");
        return 0;
    }
}

应用

Spring MVC - HandlerAdapter

设计模式之创建型模式（二）

Sun, 17 May 2020 16:39:24 +0000

单例模式

采取一定的方法保证在整个软件系统中，对某个类只能存在一个对象实例，并且该类只提供一个取得其对象实例的方法（静态方法）。

比如Hibernate的SessionFactory，它充当数据存储源的代理，并负责创建Session对象。

饿汉式

静态常量方法

demo：

class Singleton{

    /**
     * 构造器私有化，外部不能new
     */
    private Singleton(){

    }

    private final static Singleton INSTANCE = new Singleton();

    public static Singleton getInstance(){
        return INSTANCE;
    }
}

优点
- 写法简单，在类装载的时候就完成实例化，避免了线程安全问题。
缺点
- 没有达到lazy loading的效果，如果一直没有使用，就会造成内存浪费。

静态代码块

demo：

class Singleton{

    /**
     * 构造器私有化，外部不能new
     */
    private Singleton(){
        INSTANCE = new Singleton();
    }

    private static Singleton INSTANCE ;

    public static Singleton getInstance(){
        return INSTANCE;
    }
}

懒汉式

线程不安全

demo：

class Singleton{

    /**
     * 构造器私有化，外部不能new
     */
    private Singleton(){
    }

    private static Singleton INSTANCE ;

    public static Singleton getInstance(){
        if (INSTANCE == null){
            INSTANCE = new Singleton();
        }
        return INSTANCE;
    }
}

优点
- 起到了lazy loading的效果，当时只能在单线程下使用
缺点
- 多线程下会出现线程安全问题。

线程安全

加上synchronized关键字。

设计模式之设计原则（一）

Sun, 03 May 2020 18:55:28 +0000

简介

什么是设计模式？

每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的解决方案的核心，这样，你就能不必一次又一次地使用该方案而不必重复劳动。

深入理解面向对象

向下：三大面向对象机制

封装：隐藏内部实现
继承：复用现有代码
多态：改写对象行为

现上：深刻把握面向对象机制带来的抽象意义，理解如何使用这些机制来表达现实世界，掌握什么是“好的面向对象设计”

软件设计复杂的根本原因

变化：

客户需求的变化
技术平台的变化
开发团队的变化
市场环境的变化

如何解决复杂性？

分解

人们面对复杂性有一个常见的作法：分而治之，将大问题分解为多个小问题，将复杂问题分解为多个简单问题。

抽象

更高层次来讲，人们处理复杂性有一个通用的计数，即抽象。由于不能掌握全部的复杂对象，我们选择忽视它的非本质细节，而去处理泛化和理想化了的对象模型。

设计原则

单一职责原则（SRP）

一个接口仅负责一个职责，一个类只能由一个原因引起变化。

优点：

类的复杂性降低，实现什么职责都有清晰明确的定义
可读性提高
可维护性提高
变更引起的风险降低，变更时必不可少的，如果接口的单一职责做好，一个接口的修改只对相对应的实现类有影响。

里氏替换原则（LSP）

所有引用基类的地方必须能透明的使用其子类的对象。

只要父类能出现的地方子类就可以出现，而且替换为子类也不会产生任何错误或异常。

子类必须完全实现父类的方法
子类可以有自己的方法和属性
覆盖或实现父类的方法时输入参数可以被放大
覆写或实现父类的方法时输出结果可以被缩小

依赖倒置原则（DIP）

高层模块不应该依赖低层模块，两者都应该依赖其抽象

抽象不应该依赖细节

细节应该依赖抽象

在Java语言中的表现：

模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的
接口或抽象类不依赖于实现类
实现类依赖接口或抽象类

对象的依赖关系有三种方式来传递：

构造函数传递依赖对象
Setter方法传递依赖对象
接口声明依赖对象

如何实践？

每个类尽量都有接口或抽象类，或者抽象类与接口两者都具备
变量的表面类型尽量是接口或者抽象类
任何类都不应该从具体类派生
尽量不要覆写基类的方法
结合里氏替换原则使用：接口负责定义public属性和方法，并且声明与其他对象的依赖关系，抽象类负责公共内部构造部分的实现，实现类准确的实现业务逻辑，统统实在适当的时候对父类进行细化。

接口隔离原则（ISP）

客户端不应该依赖它不需要的接口

类间的依赖关系应该建立在最小的接口上

接口分为两种：

实例接口：在Java中声明一个类，然后用new关键字产生一个实例，它就是对一个类型的事物的描述，这是一种接口
类接口：interface关键字定义的接口

接口隔离原则对接口进行规范约束，包含以下四个含义：

接口要尽量小
接口要高内聚，减少对外的交互（尽量少公布public方法）
定制服务（只提供访问者需要的方法）
接口设计是有限度的（粒度越小，系统越灵活，结构越复杂，开发难度增加，可维护性降低）

如何实践？

深入MySQL索引细节

Fri, 01 May 2020 11:23:33 +0000

索引基本概念

维基百科对索引的定义：数据库索引是一种数据结构，它以额外的写入和存储空间为代价来提高数据库表上数据索引操作的速度。

MySQL官方对索引的定义是用于快速查找记录的一种数据结构。

索引是一个以空间换时间的经典案例。

索引是物理数据页，数据页大小决定了一个页可以存储多少个索引行，以及需要多少页来存储指定大小的索引。
索引可以加快检索速度，也可以降低索引列插入、删除、更新的速度，索引维护需要代价。

有两种基本的索引类型：

顺序索引：基于值的顺序排序
散列索引：基于将值平均分布到若干bucket中，一个值所属的bucket是由一个散列函数决定。

索引的数据结构

B Tree

查询的时间主要依赖于磁盘I/O的次数，每次节点访问需要进行一次磁盘IO操作。 B Tree取代平衡二叉树主要是降低了树的高度，减少了磁盘IO的次数。其基本结构如下：

B Tree别称平衡的多路搜索树，每个节点最多包括M个子节点，M称为B树的阶。

M阶的B树（M > 2）有以下的特性：

根节点的儿子数的范围是 [2,M]。
每个中间节点包含 k-1 个关键字和 k 个孩子，孩子的数量 = 关键字的数量 +1，k 的取值范围为 [ceil(M/2), M]。
叶子节点包括 k-1 个关键字（叶子节点没有孩子），k 的取值范围为 [ceil(M/2), M]。
假设中间节点节点的关键字为：Key[1], Key[2], …, Key[k-1]，且关键字按照升序排序，即 Key[i]<Key[i+1]。此时 k-1 个关键字相当于划分了 k 个范围，也就是对应着 k 个指针，即为：P[1], P[2], …, P[k]，其中 P[1] 指向关键字小于 Key[1] 的子树，P[i] 指向关键字属于 (Key[i-1], Key[i]) 的子树，P[k] 指向关键字大于 Key[k-1] 的子树。
所有叶子节点位于同一层。

B+ Tree

B+ Tree与B Tree的差异主要有以下几点：

探索MySQL的事务与锁机制

Wed, 29 Apr 2020 09:47:16 +0000

事务概念

简单来说，事务就是要保证一组数据库操作，要么全部成功，要么全部失败。MySQL中事务支持是在存储引擎层实现的。事务拥有四个重要的特性：原子性、一致性、隔离性、持久性，简称为ACID特性，下文将逐一解释。

ACID特性

原子性（Atomicity）
- 事务开始后所有操作步骤，要么全部完成，要么全部不做，不存在只执行一部分的情况。
一致性（Consistency）
- 事务执行前后，数据从一个合法性状态变换到另一个合法性状态。
  - A、B转账业务，总金额不变。
- 分为数据一致性和约束一致性。
隔离性（Isolation）
- 在一个事务未执行完毕时，其它事务无法读取该事务的数据。
- MySQL通过锁机制来保证事务的隔离性。
持久性（Durability）
- 事务一旦提交，数据将被保存下来，即使发生宕机等故障，数据库也能将数据恢复。
- MySQL使用redo log来保证事务的持久性。当通过事务对数据进行修改时，首先会将操作记录到redo log中，然后对数据库对应行进行修改，这样即使数据库宕机，也能通过redo log进行恢复。

ACID关系如下图所示：

显式事务

开始事务：

BEGIN;  
或
START TRANSACTION;

两者区别：

START TRANSACTION后面可以跟随几个修饰符：
- READ ONLY：标识为只读事务，该事务只能读取数据。
- READ WRITE：标识为读写事务，该事务可以读写数据。
- WITH CONSISTENT SNAPSHOT ：启动一致性读。

完成事务：

# 提交事务
COMMIT;

#回滚事务
ROLLBACK;

#将事务回滚到某个保存点。
ROLLBACK TO [SAVEPOINT]

隐式事务

SHOW VARIABLES LIKE 'autocommit';

隐式提交数据的情况：

数据定义语言：CREATE、ALTER、DROP
隐式修改mysql数据库中的表
事务控制（连续两次BEGIN，第一个BEGIN后面的语句会自动提交）或关于锁定的语句
加载数据的语句
MySQL复制的语句

completion_type

set @@completion_type = 1;

该变量有三种取值：

0：默认值，当我们执行COMMIT时会提交事务，再执行下一个事务时，还需要使用BEGIN来开启。
1：提交事务后，相当于执行了COMMIT AND CHAIN，开启链式事务，当我们提交事务后会开启一个相同隔离级别的事务。
2：相当于COMMIT AND RELEASE，提交事务后，与服务器断开连接。

事务分类

扁平事务：最简单的一种，使用BEGIN开启，由COMMIT或ROLLBACK结束。
带有保存点的扁平事务：支持回滚到指定保存点的事务。
链式事务：一个事务由多个子事务构成，提交前一个事务，触发下一个事务。
嵌套事务：由顶层事务控制下面各个层次的事务。
分布式事务：分布式系统中的扁平事务。

并发事务问题

脏写

事务A覆盖了事务B未提交的更新数据。

ThreadLocalRondom原理剖析

Tue, 28 Apr 2020 17:31:07 +0000

ThreadLocalRondom是JDK 7在并发包中新增的随机数生成器，该类弥补了Random类在并发环境下的缺陷。

Random的局限性

Random生成随机数的方法如下：

public int nextInt(int bound) {
    	//参数校验
        if (bound <= 0)
            throw new IllegalArgumentException(BadBound);
		//根据老的种子生成新的种子
        int r = next(31);
        int m = bound - 1;
    	//根据新种子计算随机数
        if ((bound & m) == 0)
            r = (int)((bound * (long)r) >> 31);
        else {
            for (int u = r;
                 u - (r = u % bound) + m < 0;
                 u = next(31))
                ;
        }
        return r;
    }

next方法通过计算生成新的种子。用原子变量来存放种子，多线程的情况下，CAS操作会保证只有一个线程可以更新老的种子为新种子，更新失败的线程进行自旋，这降低了并发性能，所以产生了ThreadLocalRandom。

protected int next(int bits) {
        long oldseed, nextseed;
        AtomicLong seed = this.seed;
        do {
            oldseed = seed.get();
            //seed计算公式，通过CAS操作进行更新
            nextseed = (oldseed * multiplier + addend) & mask;
        } while (!seed.compareAndSet(oldseed, nextseed));
    	//将得到的值进行逻辑右移
        return (int)(nextseed >>> (48 - bits));
    }

ThreadLocalRandom简介

ThreadLocalRandom和ThreadLocal的原理相似，ThreadLocalRandom使得每个线程都维护自己独有的种子变量，这样就不存在竞争问题，大大提高并发性能。

MySQL数据存储结构

Fri, 17 Apr 2020 13:25:04 +0000

索引组织表

在InnoDB存储引擎中，表是根据主键顺序组织存放的，这种存储方式的表称为索引组织表，每张表都有一个主键，如果创建时没有显式定义主键，InnoDB存储引擎会按照如下方式进行创建主键：

判断表中是否有非空的唯一索引，如果有，则该列为主键。
如果不符合上列条件，InnoDB存储引擎会自动创建一个6字节大小的指针。
当表中有多个非空唯一索引，InnoDB会选择第一个定义的非空唯一索引作为主键。

InnoDB逻辑存储结构

所有的数据被逻辑存放在表空间，表空间又由段，区，页（块）组成。存储结构如图所示：

表空间

表空间是InnoDB存储引擎逻辑结构的最高层，所有的数据都存放在表空间中。如果开启了innodb_file_per_table，每张表的数据可以单独放到一个表空间中。但是每张表的表空间存放的只是数据、索引和插入缓冲Bitmap页。其他类的数据，例如回滚信息，插入缓冲索引页，系统事务信息，二次写缓冲等还是存放在原来的共享表空间中。

段

表空间由各个段构成，常见的段有：数据段、索引段、回滚段等。InnoDB存储引擎表是索引组织的，因此数据即索引，索引即数据，数据段即为B+树的叶子节点，索引段即为B+树的非索引节点。在InnoDB存储引擎中，对段的管理都是由引擎自身完成，DBA不能也没有必要对其进行控制。

引入段的目的：对于范围查询，会对B+ Tree节点进行顺序扫描，如果不区分叶子节点和非叶子节点，如果将两者放到同一个区当中，查询效率大打折扣，因此引入段来区分不同类型的页面。

区

区是由连续页组成的空间，在任何情况下每个区的大小都为1MB，为了保证区的连续性，InnoDB一次从磁盘申请4~5个区，在默认情况下，页的大小为16KB，即一个区中共有64个连续页。

引入区的目的：B+ Tree底层通过页存储数据，相邻的两个页物理地址可能离得非常远（产生随机IO），因此分配空间时，直接按区进行分配，这样会将相邻的页在物理上也是连续的，可以消除很多次随机IO，同时会造成空间浪费，整体利远大于弊。

为了考虑以完整的区为单位分配给某个段对于数据量较小的表而浪费存储空间的情况，InnoDB提出了碎片区的概念，碎片区中的页属于不同段。

页

页是InnoDB磁盘管理的最小单位，默认每个页大小为16KB，可以通过参数innodb_page_size将页的大小设置为4K，8K、16K。

常见的页类型有：

数据页
undo页
系统页
事务数据页
插入缓冲位图页
插入缓冲空闲列表页
未压缩的二进制大对象页
压缩的二进制大对象页

行

InnoDB存储引擎是面向行（row-oriented）的，每个页最多存放16K/2~200行的记录（7992行）。

InnoDB行记录格式

Compact行记录格式

该格式在MySQL5.0中引入，其设计目的是高效地存储数据。简单说，一个页存放的行数据越多，其性能就越高。它的存储方式如图所示：

变长字段长度列表：对于变长字段的真实数据占用的字节长度都存放这里。
- 逆序排放，非NULL
- 如果变长列的长度小于255 bytes，则用1 byte表示，否则用2 byte表示。
NULL标志位：如果该数据行存在NULL值，使用1表示，该部分占用1 byte。
头信息固定5字节（40位），每位的含义如下：

设置deleted_flag的原因：如果物理删除的话，记录在磁盘上需要重新排列，导致性能消耗，被删除掉的记录会形成一个垃圾链表（可重用空间），如果之后有新纪录插入到表中，这部分空间将被覆盖掉。

最后的部分就是实际存储每个列的数据，NULL不占用任何空间，除了之前的标志位，每行数据除了用户定义的列之外，还有两个隐藏列，事务ID列（6字节）和回滚指针列（7字节）。如果没有定义主键，还会增加一个rowid列做为主键（6字节）。

行溢出

行溢出概念：在Compact行格式中，当列长度（例如varchar、BLOB等）达到768 byte后，会将该列的前768byte当作prefix存放在行中，多出来的数据溢出存放到溢出页中，然后通过一个偏移量指针将两者关联起来。

Dynamic和Compressed行格式不会存储prefix数据，直接全部溢出，只存储页地址。

InnoDB数据页结构

InnoDB数据页由以下七个部分构成，如图所示：

其中File Header、Page Header、File Trailer的大小是固定的，这些空间是用来标记该页的一些信息，如Checksum，数据页所在的B+树索引的层数。

File Header

该部分用来记录各种页的通用信息，共由八个部分组成，占用38字节。

该部分用来记录数据页的状态信息，由14个部分组成，占用56字节，如图所示：

Infimun和Supremum Records

Infimun用来记录是比该页中任何主键值都要小的值，Supremum Records指比任何值都大的值。这两个值在页创建时被建立。

User Record和Free Space

User Record是实际存储行记录的内容。Free Space指的是空闲空间（暂未被使用的空间），是一个链表数据结构，在一条记录被删除后，该空间会被加入到空闲链表中。

MySQL文件种类分析

Wed, 15 Apr 2020 18:48:38 +0000

参数文件

当MySQL实例启动，数据库会先去读一个配置参数文件，用来寻找数据库的各种文件所在位置以及部分初始化参数。

可以通过SHOW VARIABLES查看数据库中所有参数，可以通过LIKE过滤参数名。

参数类型

MySQL中参数分为两类：

动态参数
- 在MySQL实例运行中进行更改。
静态参数
- 在实例的整个生命周期内都不得进行更改。

可以通过set命令对动态参数进行修改，例如SET read_buffer_size=524288。对变量的修改，在这次的实例生命周期内有效，下次此洞MySQL实例还是会读取参数文件。

日志

错误日志

错误日志对MySQL的启动、运行、关闭过程进行了记录，该文件不仅记录了所有的错误信息，也记录了一些警告信息或正确的信息。

可以在配置文件中设置存储位置：

[mysqld]
log-error=[path/[filename]]

或通过查询变量来获取错误日志信息：

SHOW VARIABLES LIKE 'log_err%';

2020-04-13T03:04:23.391925Z 75 [Note] Aborted connection 75 to db: 'dev' user: 'root' host: 'localhost' (Got an error reading communication packets)
2020-04-13T03:04:23.391954Z 76 [Note] Aborted connection 76 to db: 'dev' user: 'root' host: 'localhost' (Got an error reading communication packets)
2020-04-13T03:08:39.802373Z 77 [Note] Aborted connection 77 to db: 'dev' user: 'root' host: 'localhost' (Got an error reading communication packets)
2020-04-13T03:08:39.802390Z 82 [Note] Aborted connection 82 to db: 'dev' user: 'root' host: 'localhost' (Got an error reading communication packets)
2020-04-13T03:08:39.809111Z 79 [Note] Aborted connection 79 to db: 'dev' user: 'root' host: 'localhost' (Got an error reading communication packets)
2020-04-13T03:08:39.809298Z 81 [Note] Aborted connection 81 to db: 'dev' user: 'root' host: 'localhost' (Got an error reading communication packets)
2020-04-13T03:08:39.809495Z 80 [Note] Aborted connection 80 to db: 'dev' user: 'root' host: 'localhost' (Got an error reading communication packets)
2020-04-13T03:08:39.809647Z 83 [Note] Aborted connection 83 to db: 'dev' user: 'root' host: 'localhost' (Got an error reading communication packets)
2020-04-13T03:08:39.818503Z 84 [Note] Aborted connection 84 to db: 'dev' user: 'root' host: 'localhost' (Got an error reading communication packets)
2020-04-13T03:08:39.820436Z 85 [Note] Aborted connection 85 to db: 'dev' user: 'root' host: 'localhost' (Got an error reading communication packets)
2020-04-13T03:08:39.822052Z 86 [Note] Aborted connection 86 to db: 'dev' user: 'root' host: 'localhost' (Got an error reading communication packets)
2020-04-13T03:08:39.809996Z 78 [Note] Aborted connection 78 to db: 'dev' user: 'root' host: 'localhost' (Got an error reading communication packets)
2020-04-13T03:17:12.627802Z 87 [Note] Aborted connection 87 to db: 'dev' user: 'root' host: 'localhost' (Got an error reading communication packets)
2020-04-13T03:17:12.627848Z 88 [Note] Aborted connection 88 to db: 'dev' user: 'root' host: 'localhost' (Got an error reading communication packets)
2020-04-13T03:17:12.627864Z 89 [Note] Aborted connection 89 to db: 'dev' user: 'root' host: 'localhost' (Got an error reading communication packets)
2020-04-13T03:17:12.627891Z 90 [Note] Aborted connection 90 to db: 'dev' user: 'root' host: 'localhost' (Got an error reading communication packets)
2020-04-13T03:17:12.627917Z 91 [Note] Aborted connection 91 to db: 'dev' user: 'root' host: 'localhost' (Got an error reading communication packets)
2020-04-13T03:17:12.627949Z 92 [Note] Aborted connection 92 to db: 'dev' user: 'root' host: 'localhost' (Got an error reading communication packets)
2020-04-13T03:17:12.627994Z 93 [Note] Aborted connection 93 to db: 'dev' user: 'root' host: 'localhost' (Got an error reading communication packets)
2020-04-13T03:17:12.628018Z 94 [Note] Aborted connection 94 to db: 'dev' user: 'root' host: 'localhost' (Got an error reading communication packets)
2020-04-13T03:17:12.628034Z 95 [Note] Aborted connection 95 to db: 'dev' user: 'root' host: 'localhost' (Got an error reading communication packets)
2020-04-13T03:17:12.628055Z 96 [Note] Aborted connection 96 to db: 'dev' user: 'root' host: 'localhost' (Got an error reading communication packets)
2020-04-13T05:29:24.573237Z 34 [Note] Aborted connection 34 to db: 'dev' user: 'root' host: 'localhost' (Got an error reading communication packets)
2020-04-13T05:29:24.573406Z 35 [Note] Aborted connection 35 to db: 'dev' user: 'root' host: 'localhost' (Got an error reading communication packets)
2020-04-13T09:49:37.346162Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 4528ms. The settings might not be optimal. (flushed=0 and evicted=0, during the time.)
2020-04-14T01:35:39.190069Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 43183898ms. The settings might not be optimal. (flushed=0 and evicted=0, during the time.)
2020-04-14T07:30:03.500507Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 9873804ms. The settings might not be optimal. (flushed=0 and evicted=0, during the time.)
2020-04-15T02:39:20.019686Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 46274005ms. The settings might not be optimal. (flushed=0 and evicted=0, during the time.)

慢查询日志

慢查询日志可以帮助DBA定位存在查询较慢的SQL语句，从而实现SQL语句层面的优化。可以通过long_query_time来设置慢查询阈值。默认值为10s. 默认情况下，MySQL不开启慢查询日志，需要手动将log_slow_queries设置为ON。另一个和慢查询相关的参数log_queries_not_using_indexes，这个参数如果是ON，就会将运行的SQL语句没有使用索引的，记录到慢查询日志中。 MySQL 5.6.5中新增一个参数log_throttle_queries_not_using_indexes，用来表示每分钟允许记录到慢查询日志且未使用索引的SQL语句次数。默认为0，表示没有限制。

AQS原理与源码分析

Mon, 13 Apr 2020 15:07:10 +0000

简介

队列同步器AbstractQueuedSynchronizer，是用来构建锁或者其他同步组键的基础框架，它使用了一个int成员变量state表示同步状态，通过CLH队列完成获取资源的线程排队工作。

AQS的主要使用方式是继承，字类通过继承同步器并实现它的抽象方法来管理同步状态。AQS本身只是定义若干同步状态获取和释放的方法提供给字类来实现。

锁是面向使用者的，它定义了使用者与锁交互的接口，隐藏了实现细节。AQS是面向锁的实现者，它简化了锁的实现方式，屏蔽了同步状态管理，线程的排队，等待与唤醒等底层操作。

AQS定义了两种资源共享的方式：

Exclusive（独占）：只有一个线程能执行，如ReentrantLock，其中又可分为公平锁和非公平锁：
- 公平锁：线程按照队列的顺序获取锁
- 非公平锁：线程无视顺序，去抢锁
Share（共享）：多个线程可同时执行，如Semaphore/CountDownLatch。

AQS的设计是基于模板方法模式的，使用者继承AbstractQueuedSynchronizer并重写指定方法，重写的方法是对同步状态state的获取释放等操作。

可重写方法如下，arg参数为获取锁的次数。

名称	描述
protected boolean tryAcquire(int arg)	独占方式，尝试获取同步状态，实现该方法需要查询当前状态并判断同步状态是否符合预期，然后通过CAS设置同步状态，成功返回true，失败返回false
protected boolean tryRelease(int arg)	独占方式，尝试释放同步状态，成功返回true，失败则返回false
protected int tryAcquireShared(int arg)	共享方式，尝试获取同步状态，返回0表示成功，但是没有剩余可用资源，负数表示失败，正数表示成功，并且有剩余资源。
protected boolean tryReleaseShared(int arg)	共享方式，尝试释放同步状态，成功返回true，失败返回false
protected boolean isHeldExclusively()	判断当前线程是否正在独占资源

模板方法：

方法名称	描述
void acquire(int arg)	独占锁获取同步状态，如果当前线程获取同步状态成功，则由该方法返回，否则，将会进入同步队列等待，该方法会调用重写的tryAcquire()方法
void acquireInterruptibly(int arg)	与acquire相同，但是该方法响应中断，当前线程未获取到同步状态而进入同步队列，如果当前线程被中断，该方法会抛出`InterruptedException`并返回。
boolean tryAcquireNanos(int arg, long nanosTimeout)	在acquireInterruptibly的基础上增加了超时限制，如果当前线程在超时时间之内没有获取同步状态，那么将会返回false，获取到了返回true
void acquireShared(int arg)	共享式的获取同步状态，如果当前线程未获取到同步状态，将会进入同步队列等待，与独占锁获取的主要区别式同一时刻可以有多个线程获取同步状态
void acquireSharedInterruptibly(int arg)	与acquireShared相同，响应中断
boolean tryAcquireSharedNanos(int arg, long nanosTimeout)	加了超时限制
boolean release(int arg)	独占式的释放同步状态，该方法会在释放同步状态之后，将同步队列中的第一个节点线程唤醒
boolean releaseShared(int arg)	共享式的释放同步状态
Collection getQueuedThreads()	获取等待在同步队列上的线程集合

模板方法基本分成3类：独占式获取与释放，共享式获取与释放，查询同步队列中的情况。

解析Java中的锁

Fri, 10 Apr 2020 12:07:01 +0000

简介

锁是用来控制多个线程访问共享资源的方式，在Lock接口出现之前，Java是靠synchronized关键字实现锁功能的。而Java 1.5之后，并发包中新增了Lock接口与其实现类用来实现锁功能，只是需要手动获取释放锁，虽然它缺少了同步关键字隐式获取释放的便捷性，但却拥有了可操作性，可中断的获取锁以及超时获取锁等功能。

分类

Java中会按照是否有某一特性来定义锁，下图通过各种特性对锁进行分类：

悲观锁 / 乐观锁

这两种锁不是具体类型的锁，体现了看待线程同步的角度，再Java和数据库中都有此概念对应的实际应用。

对于同一个数据的并发操作，悲观锁认为自己在使用数据的时候，一定有别的线程来修改数据，因此在获取数据的时候会先加锁，确保数据不会被别的线程修改，在Java中，synchronized关键字和Lock的实现类都是悲观锁。

而乐观锁认为自己在使用数据的时候，不会有其他线程修改数据，所以不会添加锁，只是在更新数据的时候，去判断之前有没有别的线程更新了数据，如果没有被更新，当前线程将自己修改的数据成功写入。如果数据已被其他线程更新。则根据不同的实现方式执行不同的操作（报错或自动重试）。

乐观锁在Java中是通过无锁编程来实现，最常采用是CAS算法，Java原子类中的递增就是通过CAS自旋来实现的。

悲观锁适合写操作多的场景，先加锁可以保证数据准确性。

乐观锁适合读操作多的场景，不加锁能够提高性能。

自旋锁 / 适应性自旋锁

在Java中，自旋锁是指尝试获取锁的线程不会立即阻塞，而实采用循环的方式去获取锁，这样做的好处是减少线程上下文切换的消耗。

但是自旋锁本身是有缺点的，它不能代替阻塞，自旋虽然避免了上下文切换的开销，但它要占用处理器时间，如果锁被占用的时间很短，自旋等待的效果很好，但是如果锁占用时间过长，自旋只会白白浪费处理器资源。所以自旋等待的时间必须要有一定的限度，如果自旋超过了限定次数（默认是10次，通过**-XX:PreBlockSpin**修改）没有成功获得锁，就挂起线程，停止自旋。

自旋锁的实现原理是CAS算法。自旋锁在JDK 1.4.2引入，使用**-XX:UseSpinning**开启，JDK 6开始默认开启，并且引入了自适应的自旋锁。

自适应意味着自旋的时间不再固定，而实由前一次在同一个锁上的自旋时间以及锁的拥有者的状态来决定。如果在同一个锁对象上，自旋等待刚刚成功获得过锁，并且持有锁的线程正在运行中，那么JVM会认为这次自选也是很有可能再次成功，进而它将自旋等待持续更长的时间。如果某个锁自旋很少成功获得，那么就会直接省略掉自旋过程，直接阻塞线程。

在自旋锁中，有三种常见的锁形式：TicketLock、CLHlock、MCSlock

无锁 / 偏向锁 / 轻量级锁 / 重量级锁

这四种指锁的状态，并且是针对Synchronized关键字，是通过Mark Word中的字段表明的。

无锁

无锁没有对资源进行锁定，所有线程都能访问并修改同一个资源，但同时只有一个线程能修改成功。

无锁的特点是修改操作在循环内进行，线程会不断尝试修改共享资源。如果没有冲突就修改成功并退出，否则就会继续循环尝试。CAS原理就是无锁的实现。

偏向锁

偏向锁是指一段同步代码一直被一个线程所访问，那么该线程就会自动获得锁，降低获得锁的代价。

当一个线程通过同步代码块获得锁的时候，会在Mark Word中存储锁偏向的线程ID。在线程进入或退出同步代码块时不再通过CAS操作来加锁解锁，而是检查Mark Word中是否存储着指向当前线程的偏向锁，引入偏向锁是为了在无多线程竞争的情况下尽量减少不必要的轻量级锁的执行，因为轻量级锁较偏向锁消耗性能。

偏向锁只有遇到其他线程竞争偏向锁时，持有偏向锁的线程才会释放偏向锁，线程不会主动释放偏向锁。

偏向锁在JDK 6以后是默认启用的，可以通过-XX:UseBiasedLocking=false关闭，关闭之后，程序默认进入轻量级锁状态。

轻量级锁

轻量级锁是指当锁是偏向锁的时候，被另一个线程访问，偏向锁就会升级为轻量级锁，其他线程通过自旋的方式尝试获取锁，不会阻塞。从而提高性能。

重量级锁

若当前只有一个等待线程，则该线程通过自旋进行等待，但是当自旋超过一定次数，或是一个线程在持有锁，一个在自旋，又有第三个线程访问时，轻量级锁升级为重量级锁。

综上，偏向锁通过对比Mark Word解决加锁问题，避免执行CAS操作，而轻量级锁通过CAS操作和自旋来解决加锁问题，避免线程阻塞和唤醒影响性能。重量级锁将除了拥有锁的线程以外所有线程都阻塞。

公平锁 / 非公平锁

公平锁是指多个线程按照申请锁的顺序来获取锁，线程直接进入队列进行排序，队列中第一个线程才能获得锁。

公平锁的优点时等待的线程不会饿死，缺点是整体吞吐效率相对非公平锁较低，等待队列中除第一个线程以外所有线程都阻塞，CPU唤醒阻塞线程的开销较非公平锁大。

非公平锁是多个线程加锁时直接尝试获得锁，获得不到才会进入等待队列中等待。如果此时锁刚好可用，那么线程可以无需阻塞直接获取到锁。非公平锁的优点是可以减少唤醒线程的开销，整体吞吐效率高，因为线程有几率不阻塞直接获得锁，缺点是处于等待队列的线程可能会饿死，或者等待很久才能获得锁。

可重入锁

可重入锁又称为递归锁，是指同一个线程在外层方法获取锁的时候，在进入内层方法会自当获得锁（前提是锁对象是同一个对象），不会因为之前获取过还没释放而阻塞，Java中ReentrantLock和Synchronized都是可重入锁，可重入锁的一个优点就是可一定程度避免死锁。

下面是一个可重入锁的一个案例。

synchronized void setA() throws Exception{
	Thread.sleep(1000);
	setB();
}

synchronized void setB() throws Exception{
	Thread.sleep(1000);
}

独享锁 / 共享锁

独享锁也叫排他锁，是指该锁一次只能被一个线程所持有，如果线程T对数据A加上独享锁之后，则其他线程不再对A加任何类型的锁，获得独享锁的数据即能读数据又能修改数据。

Java内存模型解析

Thu, 09 Apr 2020 13:16:52 +0000

定义

并发编程中，需要处理两个关键问题：

线程之间如何通信
线程之间如何同步

通信指线程之间以何种机制来交换信息，线程之间的通信机制有两种：共享内存和消息传递。

同步指程序中用于控制不同线程间操作发生相对顺序的机制。

Java采用的是共享内存模型，Java线程之间的通信由Java内存模型（JMM）控制。Java内存模型的主要目的是定义程序中各种变量的访问规则。

主内存和本地内存

JMM规定了线程之间共享变量存储在主内存中，每个线程都有私有的本地内存，本地内存存储了共享变量的副本，Java内存模型的示意图如图所示：

从图来看，线程A和线程B之间要通信的话，会进行以下操作：

线程A把本地内存中更新过的共享变量刷新到主内存中。
线程B去主内存中读取线程A之前更新的变量。

内存间的交互操作

关于如何将一个变量从主内存拷贝到本地内存中，JMM定义了以下八种操作来完成，JVM必须保证每种操作是原子性的。

lock：作用于主内存的变量，将一个变量标识为一个线程独占状态。
unlock：作用于主内存的变量，将处于线程独占状态的变量释放出来。
read：作用于主内存的变量，将一个变量的值从主内存传输到线程的本地内存中。
load：作用于本地内存的变量，将read操作得到的变量放入本地内存的变量副本中。
use：作用于本地内存的变量，将本地内存的一个变量值传递给执行引擎。
assign：作用于本地内存的变量，它把一个从执行引擎接收到的值赋值给本地内存中的变量。
store：作用于本地内存的变量，将本地内存的值传送到主内存中
write：作用于主内存的变量，将store操作得到的变量值放入主内存的变量中。

重排序

重排序时指编译器和处理器为了优化程序性能而对指令序列进行重新排序的一种手段，重排序分为三种类型：

编译器优化的重排序
指令并行的重排序，处理器使用指令级并行技术来将多条指令重叠执行。
内存系统的重排序，由于处理器使用了缓存技术和读/写缓冲区技术。

重排序会导致多线程程序出现内存可见性问题，对于编译器，JMM的编译器重排序规则会禁止特定类型的编译器重排序。对于处理器，JMM要求编译器生成指令序列的时候，插入内存屏障指令来禁止重排序。

数据依赖性

如果两个操作访问同一个变量，且两个操作中有一个为写操作，此时这两个操作之间就存在数据依赖性。数据依赖性分三种类型，如下表所示：

名称	代码实例
写后读	a = 1; b = a;
写后写	a = 1; a = 2;
读后写	a = b; b = 1;

上述现象如果执行顺序发生改变，执行结果就会被改变。

编译器和处理器在重排序时，会遵守数据依赖性原则，不会改变存在依赖关系的两个操作的执行顺序。

Happens-Before

JSR-133使用Happens-Before的概念来阐述操作之间的内存可见性。在JMM中，如果一个操作执行的结果需要对另一个操作可见，那么这两个操作之间必须存在Happens-Before关系。A Happens-Before B 意味着：A操作的结果对B是可见的。

通俗而言，即：A运行完成后数据结果，B都能读取到。

Happens-Before原则如下：

程序顺序规则：在一个线程内，在程序前面的操作先行发生于后面的操作。
管程锁规则：一个unlock操作先行发生于后面对同一个锁的lock操作。
volatile变量规则：对一个volatile变量的写，先行发生于任意后续对这个volatile变量的读。
传递性
线程start()规则：start()方法调用先行发生于此线程的每一个动作。
线程join()规则：线程的结束先行发生于join()方法返回。
线程interrupt()规则：对线程的interrupt()方法的调用先行发生于被中断线程代码检测到中断事件的发生
对象终结规则：一个对象的初始化完成先行发生于它的finalize()方法的开始。

线程安全

共享资源的安全程度按照强弱顺序分为以下五类：

Java并发机制底层实现原理

Tue, 07 Apr 2020 17:09:22 +0000

Volatile

定义

Java语言规范第3版中对volatile的定义如下：Java编程语言允许线程访问共享变量，为了能确保共享变量能被准确和一致的更新，线程应该确保通过排他锁单独获取这个变量。Java语言提供了volatile关键字，在某些情况下比锁要更加方便，如果一个变量被声明成volatile，Java线程内存模型确保所有线程看到的这个变量的值是一致的。

实现原理

先看下面的CPU术语定义：

术语	描述
内存屏障	是一组处理器指令，用于实现对内存操作的顺序限制
缓冲行	缓存这两个可以分配的最小存储单位，处理器填写缓存线时会加载整个缓存线，需要使用多个主内存读周期
原子操作	不可中断的一个或一系列操作
缓存行填充	当处理器识别到内存中读取操作数是可缓存的，处理器读取整个缓存行到合适的缓存
缓存命中	如果进行高速缓存行填充操作的内存位置仍然是下次处理器访问的地址时，处理器从缓存中读取操作数，而不是从内存读取
写命中	当处理器将操作数写回到一个内存缓存中的区域中，它首先会检查这个缓存的内存地址是否在缓存行中，如果存在一个有效的缓存行，则处理器将这个操作数回写到缓存，而不是回写到内存，这个操作数被称为写命中
写缺失	一个有效的缓存行被写入到不存在的内存区域

/**
 * @author ：L1nker4
 * @date ： 创建于  2020/4/7 20:34
 * @description： volatile测试
 */
public class Demo01 {

    private static volatile boolean stop = false;
    
    public static void main(String[] args) {
        stop = true;
        boolean b = stop;
    }
}

通过添加VM options打印程序汇编代码：

-XX:+UnlockDiagnosticVMOptions -XX:+LogCompilation -XX:+PrintAssembly -Xcomp -XX:CompileCommand=dontinline,*Demo01.main -XX:CompileCommand=compileonly,*Demo01.main

如果提示以下内容，需要将hedis-amd64.dll放在jre/bin/server目录下。

Java HotSpot(TM) 64-Bit Server VM warning: PrintAssembly is enabled; turning on DebugNonSafepoints to gain additional output

截取部分的汇编代码

Spring Cloud Alibaba Nacos

Mon, 06 Apr 2020 14:19:33 +0000

什么是Nacos

Nacos 致力于帮助您发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据及流量管理。 Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。 Nacos 是构建以“服务”为中心的现代应用架构 (例如微服务范式、云原生范式) 的服务基础设施。

Nacos的关键特性包括：

服务发现和服务健康监测
动态配置服务
动态 DNS 服务
服务及其元数据管理

Nacos架构

其中Nacos整体分为两大块，分别是Nacos Server和Nacos Console，Nacos Server为核心，其中包括Naming Service，Config Service，Naming Service主要提供服务发现和DNS功能，Config Service相当于Netflix时期的Spring Cloud Config提供的分布式配置中心的功能，使得配置信息在线读取。

Nacos安装

这里笔者使用Docker方式安装，具体安装流程可以参照如下：

git clone https://github.com/nacos-group/nacos-docker.git
cd nacos-docker/example
docker-compose -f standalone-mysql-5.7.yaml up -d

Nacos 控制台：http://192.168.252.128:8848/nacos

服务注册功能案例

引入Nacos Discovery Starter依赖

 <dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
    <version>2.2.0.RELEASE</version>
 </dependency>

配置Nacos Server地址与其他信息

spring.application.name=service-provider
server.port=8081
spring.cloud.nacos.discovery.server-addr=192.168.252.128:8848

使用 @EnableDiscoveryClient 注解开启服务注册与发现功能

@SpringBootApplication
@EnableDiscoveryClient
public class SpringCloudAlibabaNacosExampleApplication {

    public static void main(String[] args) {
        SpringApplication.run(SpringCloudAlibabaNacosExampleApplication.class, args);
    }

}

启动应用后，通过Nacos控制台可以看到服务已注册。

Java线程基础知识

Fri, 03 Apr 2020 20:27:03 +0000

进程与线程

什么是进程

操作系统在运行一个程序时，会为其创建一个进程，操作系统调度的最小单元是线程，也叫轻量级进程，在一个进程里可以创建多个线程，多个线程共享进程的堆和方法区两块内存空间。

进程和线程的区别

进程是操作系统进行资源分配的基本单位，而线程是操作系统进行调度的基本单位。
进程单独占有一定的内存地址空间，所以进程间存在内存隔离，数据是分开的，数据共享复杂但是同步简单，各个进程之间互不干扰；而线程共享所属进程占有的内存地址空间和资源，数据共享简单，但是同步复杂。
进程单独占有一定的内存地址空间，一个进程出现问题不会影响其他进程，不影响主程序的稳定性，可靠性高；一个线程崩溃可能影响整个程序的稳定性，可靠性较低。
进程单独占有一定的内存地址空间，进程的创建和销毁不仅需要保存寄存器和栈信息，还需要资源的分配回收以及页调度，开销较大；线程只需要保存寄存器和栈信息，开销较小。

上下文切换

上下文切换是指CPU从一个进程（线程）切换到另一个进程（线程）。上下文是指某一个时间点CPU寄存器和PC的数据。

并发和并行

并发：同一时刻有多个任务在运行。
并行：同一时间有多个任务在运行。

线程的创建

线程创建方式争议较多，在Oracle官方文档给出的创建方式为两种，分别是继承Thread类和实现Runnable接口。

There are two ways to create a new thread of execution. One is to declare a class to be a subclass of Thread. This subclass should override the run method of class Thread. An instance of the subclass can then be allocated and started.

The other way to create a thread is to declare a class that implements the Runnable interface. That class then implements the run method. An instance of the class can then be allocated, passed as an argument when creating Thread, and started.

JVM之字节码执行引擎（九）

Fri, 03 Apr 2020 19:56:23 +0000

字节码执行引擎

执行引擎是JVM核心的组成部分之一，虚拟机是一个相对于物理机的概念，物理机的执行引擎是直接建立在存储器、缓存、指令集和操作系统上的，而虚拟机的执行引擎完全由软件自行实现。因此可以不受物理条件制约地定制指令集与执行引擎地结构体系。

执行引擎在执行字节码地时候，通常会有解释执行和编译执行两种选择。

运行时栈帧结构

JVM以方法为最基本地执行单元，栈帧是用于支持JVM进行方法调用和方法执行背后地数据结构，它是JVM运行时数据区中虚拟机栈地栈元素，每一个方法从调用开始至执行结束的过程，都对应着一个栈帧在虚拟机栈里面的入栈到出栈的过程。

对于执行引擎来说，在活动线程中，只有位于栈顶的方法才是在运行的，只有位于栈顶的栈帧才是在运行的，被称为当前栈帧，与这个栈帧相关联的方法被称为当前方法。

局部变量表

局部变量表是一组变量值的存储空间，用于存放方法参数和方法内部定义的局部变量。局部变量表的容量以变量槽为最小单位。

当一个方法被调用时，JVM会使用局部变量表完成参数值到参数变量列表的传递过程，即实参到形参的传递。如果执行的是实例方法（没有被static修饰的方法），那局部变量表中第0位索引的变量槽默认是用于传递方法所属对象实例的引用，在方法中可以通过this来访问到这个参数，其余参数按照参数表顺序排列，占用从1开始的局部变量槽。

操作数栈

操作数栈也被称为操作栈，它是一个后入先出栈，操作数栈的最大深度在编译时写入到Code属性的max_stacks数据项之中，操作数栈的每一个元素都可以是包括long和double在内的任何Java数据类型，32位数据类型所占的栈容量为1，64位数据类型栈容量为2.

当一个方法刚刚开始执行时，这个方法的操作数栈是空的，在方法的执行过程中，会有各种字节码指令往操作数栈中写入和提取内容，也就是出栈和入栈操作。

操作数栈中的数据类型必须与字节码指令的序列严格匹配，在编译程序代码时，编译器需要严格保证这一点，在类校验阶段的数据流分析中还要再次验证这一点。

在概念模型中，两个不同栈帧作为不同方法的虚拟机栈的元素，是完全相互独立的。但在大多数JVM实现里会进行一些优化操作，令两个栈帧出现一部分重叠，让下面栈帧的部分操作数栈与上面栈帧的部分局部变量表重叠在一起。不仅可以节约空间，更重要的是在方法调用时可以直接共用一部分数据，无需进行额外的参数复制传递了。

方法返回地址

当一个方法开始执行后，只有两种方式退出这个方法，第一种方式是执行引擎遇到任意一个方法返回的字节码指令，这时可能会有返回值传递给上层的方法调用者，方法是否有返回之以及返回值的类型将根据遇到何种方法返回指令来决定，这种退出方法的方式称为正常调用完成。

另一种方式是在方法执行的过程中遇到了异常，并且这个异常没有在方法体内得到妥善处理。无论是JVM内部异常，还是代码中使用了athrow指令产生的异常，只要在笨方法的异常表中没有搜索到匹配的异常处理器，就会导致方法退出，这种退出方法的方式称为异常调用完成，异常调用完成的方式退出，不会给它的调用者提供任何返回值。

方法退出的过程实际上等同于当前栈帧出栈，因此退出时可能执行饿操作有：恢复上层方法的局部变量表和操作数栈，把返回值压入调用者栈帧的操作数栈，调整PC计数器的值以指向方法调用指令后面的一条指令等。

方法调用

一切方法调用在Class文件里面存储的都只是符号引用，而不是方法在实际运行时内存布局中的入口地址。

解析

在类加载的解析阶段，会将其中的一部分符号引用转换成直接引用，这种解析能成立的前提是：方法在程序运行之前就有一个可确定的调用版本，并且方法的调用版本在运行期不可改变的。

在Java语言中符合“编译期可知，运行期不可知”的方法，主要有静态方法和私有方法两大类，前者与类型直接关联，后者在外部不可被访问。这两种方法各自的特点决定了都不可能通过继承或别的方式重写出其他版本，因此都适合在类加载阶段进行解析。

调用不同种类的方法有不同的字节码指令，分别是：

invokestatic：调用静态方法
invokespecial：用于调用实例构造器()方法、私有方法和父类中的方法
invokevirtual：用于调用所有的虚方法
invokeinterface：用于调用接口方法，会在运行时再确定一个实现该接口的对象
invokedynamic：先在运行时动态解析出调用点限定符所引用的方法，然后执行该方法

只要能被invokestatic和invokespecial指令调用的方法，都可以在解析阶段中确定唯一的调用版本，Java语言中符合这个条件的有静态方法、私有方法、实例构造器、父类方法，被final修饰的方法，这五种方法调用会在类加载的时候就可以把符号引用解析为该方法的直接引用。这些方法统称为非虚方法。

分派

另一种主要的方法调用形式：分派调用则复杂许多，他可能是静态的，可能是动态的，按照分派依据的宗量数可分为单分派和多分派，这两种分派方式两两组合可以得到四种分派组合情况。

静态分派

public class StaticDispatch {
	static abstract class Human{
	}
	static class Man extends Human{
	}
	static class Woman extends Human{
	}
	public static void sayHello(Human guy){
		System.out.println("hello,guy!");
	}
	public static void sayHello(Man guy){
		System.out.println("hello,gentlemen!");
	}
	public static void sayHello(Woman guy){
		System.out.println("hello,lady!");
	}
	
	public static void main(String[] args) {
		Human man=new Man();
		Human woman=new Woman();
		sayHello(man);
		sayHello(woman);
	}
}

运行结果为：

JVM之类加载机制（八）

Sat, 28 Mar 2020 19:51:37 +0000

类加载机制

JVM把Class描述类的数据从Class文件加载到内存，并对数据进行校验，转换解析和初始化，最终形成可以被虚拟机直接使用的Java类型，这个过程被称为类加载机制。

类加载的时机

类加载机制的整个生命周期将经历：

加载
验证
准备
解析
初始化
使用
卸载

其中验证，准备，解析三部分统称为连接。加载，验证，准备，初始化，卸载这五个阶段的顺序是确定的，而解析阶段则不一定，他在某些情况下可以在初始化阶段之后再开始，这是为了支持Java语言的运行时绑定特性（也称为动态绑定或者晚期绑定）。

关于在什么情况下进行类加载的第一个过程，JVM规范并没有强制约束，这点交给虚拟机的具体实现来自由把握，但是对于初始化阶段，JVM严格规定了有且仅有六种情况必须立即对类进行初始化（加载验证准备自然在此之前）：

遇到new，getstatic，putstatic或invokestatic四条字节码指令时，如果类型没有进行初始化，则需要先出发其初始化阶段，主要场景有：
- 使用new关键字实例化对象的时候
- 读取或设置一个类型的静态字段（被final修饰，已在编译期把结果放入常量池的静态字段除外）
- 调用一个类型的静态方法的时候
使用java.lang.reflect包的方法对类型进行反射调用的时候，如果类型没有进行过初始化，则需要触发初始化
当初始化类的时候，如果发现其父类没有进行初始化，则需要先对父类进行初始化
当虚拟机启动时，用户需要指定一个要执行的主类，虚拟机会先初始化这个主类
当使用JDK 7新加入的动态语言支持时，如果使用一个java.lang.invoke.MethodHandle实例最后的解析结果为REF_getStatic、REF_putStatic、REF_invokeStatic 的方法句柄，并且这个方法句柄所对应的类还没初始化，则需要先触发其初始化。
当一个接口定义了JDK 8新加入的默认方法（被default关键字修饰的接口方法）时，如果有这个接口的实现类发生了初始化，那么该接口要在其之前被初始化

这六种场景中的行为被称为对一个类型的主动引用，除此之外，所有引用类型的方式不会触发初始化，称为被动引用。

被动引用的Demo

/**
 * 被动引用 Demo1:
 * 通过子类引用父类的静态字段，不会导致子类初始化。
 */
 
class SuperClass {
    static {
        System.out.println("SuperClass init!");
    }

    public static int value = 123;
}

class SubClass extends SuperClass {
    static {
        System.out.println("SubClass init!");
    }
}

public class NotInitialization {

    public static void main(String[] args) {
        System.out.println(SubClass.value);
        // SuperClass init!
    }

}

对于静态字段，只有直接定义这个字段的类才会被初始化，因此通过其子类来引用父类中定义的静态字段，只会触发父类的初始化而不会触发子类的初始化。

JVM之字节码指令（七）

Fri, 27 Mar 2020 13:32:16 +0000

字节码指令

Java虚拟机的指令是由一个字节长度的，代表某种特定操作含义的数字（称为操作码，Opcode），以及跟随其后的零至多个代表此操作的参数，称为操作数（Operand）构成。由于Java虚拟机面向操作数栈而不是寄存器的架构，所以大多数指令都不包含操作数，只有一个操作码。指令参数存放在操作数栈中。

由于Java虚拟机操作码的长度为一个字节（0-255），这意味着指令集的操作码总数不能超过256条。

加载和存储指令

将一个局部变量加载到操作数栈：iload、iload_、lload、lload_、fload、fload_、dload、dload_、aload、aload_
将一个数值从操作数栈存储到局部变量表：istore、istore_、lstore、lstore_、fstore、fstore_、dstore、dstore_、astore、astore_
将一个常量加载到操作数栈：bipush、sipush、ldc、ldc_w、ldc2_w、aconst_null、iconst_m1、iconst_

扩充局部变量表的访问索引的指令

运算指令

加法指令：iadd、ladd、fadd、dadd

减法指令：isub、lsub、fsub、dsub

乘法指令：imul、lmul、fmul、dmul

除法指令：idiv、ldiv、fdiv、ddiv

求余指令：irem、lrem、frem、drem

取反指令：ineg、lneg、fneg、dneg

位移指令：ishl、ishr、iushr、lshl、lshr、lushr

按位或指令：ior、lor

按位与指令：iand、land

按位异或指令：ixor、lxor

局部变量自增指令：iinc

比较指令：dcmpg、dcmpl、fcmpg、fcmpl、lcmp

类型转换指令

JVM直接支持小范围类型向大范围类型的安全转换：

int -> long/float/double

long -> float/double

float -> double

处理窄化类型转换时，要用转换指令来完成。包括i2b、i2c、i2s、l2i、f2i、f2l、d2i、d2l、d2f.

在将int或long类型窄化转换成整数类型T的时候，转换过程仅仅是简单丢弃除最低位N字节以外的内容，N是类型T的数据类型长度。这将可能导致转换结果与输入值的正负号不同。

对象创建与访问指令

虽然类实例和数组都是对象，但是JVM对类实例和数组的创建使用不同的字节码指令，对象创建后，可以通过对象访问指令获取对象实例或者数组实例中的字段或者数组元素，包括：

创建类实例指令：new

创建数组的指令：newarray，anewarray，multianewarray

访问类字段（static字段）和实例字段（非static字段）的指令：getfield、putfield、getstatic、putstatic

把一个数组元素加载到操作数栈的指令：baload、caload、saload、iaload、laload、faload、daload、aaload

将一个操作数栈的值存储到数组元素中的指令：bastore、castore、sastore、iastore、fastore、dastore、aastore

取数组长度的指令：arraylength

检查类实例类型的指令：instanceof、checkcast

操作数栈管理指令

将操作数栈的栈顶一个或者两个元素出栈：pop、pop2

复制栈顶一个或两个数值并将复制值或双份的复制值重新压入栈顶：dup、dup2、dup_x1、dup2_x1、dup_x2、dup2_x2

将栈最顶端的两个数值交换：swap

控制转移指令

可以认为控制指令就是在有条件或者无条件地修改PC寄存器地值，控制指令包括：

条件分支：ifeq、iflt、ifle、ifne、ifgt、ifge、ifnull、ifnonnull、if_icmpeq、if_icmpne、if_icmplt、if_icmpgt、if_icmple、if_icmpge、if_acmpeq、if_acmpne

复合条件分支：tableswitch、lookupswitch

无条件分支：goto、goto_w、jsr、jsr_w，ret

方法调用和返回指令

方法调用指令包括：

invokevirtual：用于调用对象地实例方法，根据对象地实际类型进行分派

invokeinterface：用于调用接口方法，他会在运行时搜索一个实现了这个接口地方法地对象，找出合适地方法进行调用

invokespecial：用于调用一些需要特殊处理的实例方法，包括实例初始化方法，私有方法和父类方法

invokestatic：用于调用类静态方法

invokedynamic：用于在运行时动态解析出调用点限定符所引用的方法，并执行该方法。

方法返回指令包括

ireturn（返回值为Boolean，char，short，int时使用）

lreturn

freturn

dreturn

areturn

return（void）

异常处理指令

Java程序中显式抛出异常的操作（throw）都由athrow指令来实现。JVM规范规定许多运行时异常会在其他Java虚拟机指令检测到异常状态时自动抛出。处理异常不是由字节码实现的，而是采用异常表实现的。

同步指令

Java虚拟机可以支持方法级的同步和方法内部一段指令序列的同步，这两种同步结构都是使用管程（Monitor，也被称为锁）来实现的。

JVM之类文件结构（六）

Thu, 26 Mar 2020 17:30:40 +0000

前言

实现语言无关性的基础是虚拟机和字节码存储格式。Java虚拟机不与任何程序语言绑定，它只与Class文件这种特定的二进制文件格式所关联。Class文件中包含了Java虚拟机指令集，符号表以及若干其他辅助信息。

Class文件结构

任何一个Class文件对应着唯一的一个类或者接口的定义信息，Class文件是一组以八个字节为基础单位的二进制流，各个数据项目严格按照顺序紧凑的排列，中间没有任何分隔符，Class文件只有两种类型：无符号数、表。

无符号数属于基本数据类型，以u1,u2,u4,u8分别代表1/2/4/8个字节的无符号数，无符号数用来描述数字，索引引用，数量值。

表：由多个无符号数或者其他表作为数据项构成的复合数据类型。

魔数

Class文件的头4个字节被称为魔数，它的唯一作用就是确定这个文件是否为一个能被JVM接受的Class文件，魔数的十六进制表示为0xCAFEBABE。

版本信息

紧接着魔数的4个字节的是版本信息，第5-6字节是次版本号，7-8字节是主版本号，表示Class文件使用的JDK版本。高版本的JDK能向下兼容，但是不能向上兼容。

常量池

版本信息之后是常量池入口，常量池主要存放两大类常量：字面量、符号引用。

常量池中常量的数量是不固定的，所以在入口需要放置一项u2类型的数据，代表常量池容量计数值。

字面量接近于常量概念，如字符串、被声明为final的值。符号引用属于编译原理方面的概念：主要包括：

被模块导出或开放的包

类和接口的全限定名

字段的名称和描述符

方法的名称和描述符

方法句柄和方法类型

动态调用点和动态产量

常量池的每个常量都是一个表，共有17钟不同类型的常量。表开始的第一位是个u1类型的标志位，代表当前常量属于哪种常量类型。

17种常量类型：

类型 tag 描述

CONSTANT_utf8_info 1 UTF-8编码的字符串

CONSTANT_Integer_info 3 整型字面量

CONSTANT_Float_info 4 浮点型字面量

CONSTANT_Long_info 5 长整型字面量

CONSTANT_Double_info 6 双精度浮点型字面量

CONSTANT_Class_info 7 类或接口的符号引用

CONSTANT_String_info 8 字符串类型字面量

CONSTANT_Fieldref_info 9 字段的符号引用

CONSTANT_Methodref_info 10 类中方法的符号引用

CONSTANT_InterfaceMethodref_info 11 接口中方法的符号引用

CONSTANT_NameAndType_info 12 字段或方法的符号引用

CONSTANT_MethodHandle_info 15 表示方法句柄

CONSTANT_MethodType_info 16 标识方法类型

CONSTANT_InvokeDynamic_info 18 表示一个动态方法调用点

对于 CONSTANT_Class_info（此类型的常量代表一个类或者接口的符号引用），它的二维表结构如下：

类型名称数量

u1 tag 1

u2 name_index 1

tag 是标志位，用于区分常量类型；name_index 是一个索引值，它指向常量池中一个 CONSTANT_Utf8_info 类型常量，此常量代表这个类（或接口）的全限定名，这里 name_index 值若为 0x0002，也即是指向了常量池中的第二项常量。

JVM之内存分配策略（五）

Wed, 25 Mar 2020 19:53:08 +0000

内存分配与回收策略

Java技术体系的自动内存管理，最根本性的目标是自动化解决两个问题：自动给对象分配内存，以及自动回收分配给对象的内存。

对象的内存分配，就是在堆上分配（也有可能经过JIT编译后被拆散为标量空间类型间接地在栈上分配），新生对象主要分配在新生代中，少数情况（大小超过阈值）会被分配在老年代，分配规则不固定，取决于当前使用的垃圾收集器与JVM参数设置。

对象优先在Eden分配

大多数情况下，对象在新生代Eden去中分配，当Eden区没有足够的空间进行分配时，虚拟机将发起一次Minor GC。

Minor GC：回收新生代（包括 Eden 和 Survivor 区域），因为 Java 对象大多都具备朝生夕灭的特性，所以 Minor GC 非常频繁，一般回收速度也比较快。

Major GC / Full GC: 回收老年代，出现了 Major GC，经常会伴随至少一次的 Minor GC，但这并非绝对。Major GC 的速度一般会比 Minor GC 慢 10 倍以上。

大对象直接进入老年代

大对象就是需要大量连续内存空间的Java对象，最典型的大对象就是那种很长的字符串，或者元素数量很庞大的数组。

JVM提供了一个-XX:PretenureSizeThreshold，指定大于该设置值的对象直接在老年代分配，这样做的目的是避免在Eden区和两个Survivor区之间来回复制，产生大量内存复制操作。

长期存活的对象进入老年代

为了决策哪些存活对象存储在新生代，哪些对象存储在老年代，，JVM给每个对象定义了一个对象年龄计数器，存储在对象头中，对象通常在Eden区诞生，如果经历一次Miror GC后仍然存活，并且能被Survivor容纳，该对象就会被移动到Survivor，并将该对象年龄设为1岁，对象每经历一次Miror GC，年龄就增加1岁，当年龄达到一定程度（默认15），就会被移动到老年代，对象年龄阈值可以通过-XX:MaxTenuringThreshold设置。

动态对象年龄判定

如果当前新生代的Survivor中，相同年龄的所有对象大小的综合大于Survivor空间的一半，年龄大于或等于该年龄的对象可以进入老年代，无需等到MaxTenuringThreshold 中要求的年龄。

空间分配担保

JDK 6 Update 24 之前，在发生Miror GC之前，虚拟机会先检查老年代最大可用的连续空间是否大于新生代所有对象总空间，如果这个条件成立，那这一次的Miror GC可以确保是安全的，如果不成立，则虚拟机会查看 HandlePromotionFailure 值是否设置为允许担保失败，如果允许，那么会继续检查老年代最大可用的连续空间是否大于历次晋升到老年代对象的平均大小，如果大于，将尝试进行一次 Minor GC,尽管这次 Minor GC 是有风险的；如果小于，或者 HandlePromotionFailure 设置不允许冒险，那此时也要改为进行一次 Full GC。

JDK 6 Update 24 之后的规则变为：
只要老年代的连续空间大于新生代对象总大小或者历次晋升的平均大小，就会进行 Minor GC，否则将进行 Full GC。

JVM之垃圾收集算法与垃圾收集器（四）

Tue, 24 Mar 2020 21:05:57 +0000

垃圾收集算法

从如何判定对象消亡的角度出发，垃圾收集算法可以划分为引用计数式垃圾收集和追踪式垃圾收集，由于引用计数式垃圾收集在主流JVM并未涉及，所以追踪式垃圾收集为主。

当前的JVM大多数遵循了分代收集理论进行设计，它主要建立在两个分代假说上面：弱分代假说和强分代假说。分代假说奠定了收集器的设计原则：收集器应该将Java堆划分出不同的区域，然后将回收对象依据其年龄分配到不同的区域之中存储。

标记-清除算法

标记过程：遍历所有的GC Roots，然后将GC Roots可达对象标记为存活的对象。

清除过程：将没有标记的对象全部清除。

主要缺点：

执行效率不稳定

内存空间碎片化问题

标记-复制算法

也被简称为复制算法，它将可用内存划分成大小相等的两块，每次只使用其中的一块，当这一块的内存用完，就把还存活的对象复制到另外一块上面，然后再把这一块内存全部清除。这种算法有优有劣。

优点：不会出现内存碎片的问题

缺点：可用内存缩为原来的一半，浪费空间

为了提高空间利用率的问题，可以将新生代分为一块较大的Eden区，和两块较小的Survivor区，比例为8:1:1,每次分配内存只使用Eden和其中一块Survivor，发生垃圾收集时，将Eden和Survivor中仍然存活的对象一次性复制到另外一块Survivor区，然后清理掉Eden和已用过的Survivor区，这样只有10%的内存被浪费掉。但是不能保证每次回收都只有不多于10%的对象存活，当Survivor空间不够时，需要依赖其他内存区域（老年代）进行分配担保。

标记-整理算法

标记过程：与标记-清除算法一样，将存活的对象标记。整理过程：让所有存活的对象都向内存空间一端移动，然后直接清理掉边界之外的内存。

这是一种老年代的垃圾收集算法，老年代对象的生命周期较长，因此每次垃圾回收会有大量对象存活，如果采用复制算法，每次效率很低。

经典垃圾收集器

新生代垃圾收集器

Serial收集器（单线程）

Serial收集器是一个新生代垃圾收集器，它在垃圾收集时，必须暂停其它所有工作线程,知道它收集结束（Stop the World）。对于内存资源受限的环境，它时所有收集器里面额外内存消耗最小的，对于单核处理器或者处理器核心数较少的环境来说，Serial收集器由于没有线程交互的开销，壮美做垃圾收集自然可以获得最高的单线程手机效率。

ParNew收集器（多线程）

ParNew收集器实质上时Serial收集器的多线程并行版本，由多条GC线程并行的进行垃圾清理，清理过程仍需Stop The World。在多 CPU 环境下性能比 Serial 会有一定程度的提升；但线程切换需要额外的开销，因此在单 CPU 环境中表现不如 Serial。

Parallel Scavenge收集器（多线程）

Parallel Scavenge 和 ParNew 一样，都是多线程、新生代垃圾收集器。但是两者有巨大的不同点：

Parallel Scavenge：追求 CPU 吞吐量，能够在较短时间内完成指定任务，因此适合没有交互的后台计算。

ParNew：追求降低用户停顿时间，适合交互式应用。

吞吐量 = 运行用户代码时间 / (运行用户代码时间 + 垃圾收集时间)

老年代垃圾收集器

Serial Old收集器（单线程）

Serial Old 收集器是 Serial 的老年代版本，都是单线程收集器，只启用一条 GC 线程，都适合客户端应用。它们唯一的区别就是：Serial Old 工作在老年代，使用标记-整理算法；Serial 工作在新生代，使用标记-复制算法。

JVM之垃圾收集策略（三）

Mon, 23 Mar 2020 22:00:18 +0000

垃圾收集策略

程序计数器，虚拟机栈，本地方法栈随线程而生，随线程而灭，栈中的栈帧随着方法的进入和退出而执行入栈和出栈操作，每个栈帧分配多少内存基本上是在类结构确定下来时就已知的，因此这几个区域的分配和回收具备确定性。在这几个区域不需要过多考虑如何回收的问题，当方法执行结束或者线程结束，内存自然就跟随着回收。而Java堆和方法区，只有程序运行期间才知道会创建多少对象，这部分内存的分配和回收都是动态的，GC关注的正是这部分内存。

判断对象是否存活

如果一个对象不被任何对象或变量引用，那么他就是无效对象，需要被回收。判断是存活主要有以下几种算法。

引用计数算法

在对象中添加一个引用计数器，每当有一个对地方引用它时，计数器值就加一，当引用失效时，计数器值就减一，任何时刻计数器为零的对象就是不可能再被使用的。引用计数原理简单，判定效率也高，但是主流的JVM并没有选用引用计数来管理内存，主要原因是这个算法有很多例外情况需要考虑，比如对象之间相互循环引用。

对象 objA 和 objB 都有字段 instance，令 objA.instance = objB 并且 objB.instance = objA，由于它们互相引用着对方，导致它们的引用计数都不为 0，于是引用计数算法无法通知 GC 收集器回收它们。

可达性分析算法

所有和 GC Roots 直接或间接关联的对象都是有效对象，和 GC Roots 没有关联的对象就是无效对象。

从GC Roots作为起始节点，根据引用关系向下搜索，搜索过程所走过的路径称为引用链，如果某个对象到GC Roots之间没有任何引用链相连，就证明此对象不可能在被使用的。

在Java技术体系里面，固定可作为GC Roots的对象包括：

在虚拟机栈（栈帧的本地变量表）中引用的对象，比如各个线程被调用的方法堆栈中使用到的参数，局部变量，临时变量等

在方法区中常量引用的对象，比如字符串常量池里面的引用

在本地方法栈中JNI（Native）引用的对象

Java虚拟机内部的引用，如基本数据类型对应的Class对象，一些常驻的异常对象，比如NullPointerException，OutofMemoryError等，还有系统类加载器

所有被同步锁（synchronized）持有的对象

反映Java虚拟机内部情况的JMXBean，JVMTI中注册的回调，本地代码缓存等

引用

判定对象是否存活与“引用”有关。在 JDK 1.2 以前，Java 中的引用定义很传统，一个对象只有被引用或者没有被引用两种状态，我们希望能描述这一类对象：当内存空间还足够时，则保留在内存中；如果内存空间在进行垃圾手收集后还是非常紧张，则可以抛弃这些对象。很多系统的缓存功能都符合这样的应用场景。

在 JDK 1.2 之后，Java 对引用的概念进行了扩充，将引用分为了以下四种。不同的引用类型，主要体现的是对象不同的可达性状态reachable和垃圾收集的影响。

强引用

类似Object object = new Object()这类的引用，只要强引用还存在，垃圾收集器就永远不会回收掉被引用的对象。

软引用

软引用是用来描述一些还有用，但非必须的对象，只被软引用关联着的对象，在系统将要发生内存溢出异常前，会把这些对象列进回收范围之中进行第二次回收。即如果还有空闲内存，即暂时保存，当内存不足时清理掉。JDK1.2之后提供了SoftReference来实现软引用。

弱引用

弱引用用来描述那些非必须对象，它的强度比软引用更弱一些，被弱引用关联的对象只能生存到下一次垃圾收集发生为止。JDK 1.2之后提供WeakReference类来实现弱引用

虚引用

虚引用也成为幽灵引用或者幻影引用，他是最弱的一种引用关系。一个对象是否有虚引用的存在，完全不会对其生存空间构成影响。也无法通过虚引用来获取一个对象实例，为一个对象设置虚引用关联的唯一目的只是为了能在这个对象被收集器回收时收到一个系统通知，在JDK1.2之后提供PhantomReference类来实现虚引用。

回收过程

对于可达性分析中不可达的对象，那么它将会被第一次标记，随后进行一次筛选，筛选的条件是此对象是否有必要执行finalize()方法，假如对象没有覆盖finalize()方法，或者finalize()方法已被虚拟机调用过，那么虚拟机将这两种情况都视为“没有必要执行”，那么对象基本上就真的被回收了。

JVM之HotSpot VM对象（二）

Sun, 22 Mar 2020 18:14:15 +0000

对象的创建过程

类加载检查

当JVM遇到一条字节码new指令时，首先去检查这个指令的参数是否能在常量池中定位到一个类的符号引用，并检查这个符号引用代表的类是否已被加载，解析和初始化过。如果没有，那么先执行相应的类加载过程。

为新生对象分配内存

对象所需内存的大小再类加载完成后便可完全确定（对象的字段存储的时基本类型值，对象和数组的引用），接下来从Java堆中划分出对应大小的内存块给新的对象，分配方式有两种：

指针碰撞

假设Java堆中内存时绝对规整的，所有被使用的内存都被放在一边，空闲的内存放在另一边，中间放着一个指针作为分界点的指示器，那么所分配内存就仅仅是把那个指针向空闲空间方向挪动一段所需大小的距离。

空闲列表

如果Java堆中内存并不是规整的，使用的内存和未使用的内存交错在一起，此时无法使用指针碰撞方法，JVM需要维护一个列表，记录哪些内存块空闲可用，再分配的时候，从列表中找出一块足够大的空间划分给对象实例，并更新列表上的记录。

Java堆是否规整，取决于采用的垃圾收集器是否具有空间压缩整理（Compact）的能力决定。使用Serial、ParNew等收集器时，采取指针碰撞方法，当使用CMS这种基于清除（Sweep）算法的收集器时，采用较为复杂的空闲列表来分配内存。

如何保证并发情况下的线程安全问题？

对分配内存空间的动作进行同步处理，实际上JVM是采用CAS配上失败重试的方式保证更新操作的原子性

把内存分配的动作按照线程划分再不同的空间之中进行，即每个线程在Java堆预先分配一小块内存，称为本地线程分配缓冲（TLAB）。哪个线程要分配内存，在哪个本地缓冲区进行分配。本地缓冲区用完了，分配新的缓存区才需要同步锁定。

初始化

分配完内存之后，JVM将内存空间都初始化为零值，这步操作保证了对象的实例字段在Java代码中可以不赋初始值就直接使用。

设置信息

设置对象头信息：

对象是哪个类的实例

如何才能找到类的元数据信息

对象的哈希码（真正调用Object::hashCode()时才计算）

对象的GC分代年龄

执行构造函数

执行之前，对象的所有字段都为默认的零值，通过Class文件中的<init>()完成对象的创建过程。

虚拟机层面完成对象创建工作时，Java程序刚开始执行构造函数，此时别的线程读取该对象不为Null（引用存了地址），但是内部无值。如果在并发环境下，由于指令重排序的存在，可能还未读到初始化变量。可以使用volitale配合Double Check完成工作。

对象的内存布局

对象头

对象头存储两类信息，第一类用于存储对象自身的运行时数据，称为Mark Word，包括以下信息：

哈希码

GC分代年龄

锁状态标志

线程持有的锁

偏向线程ID

偏向时间戳

Mark Word在32位，64位下分别为32bit和64bit，32位HotSpot虚拟机中，对象未被同步锁锁定的状态下，Mark Word的32bit中25bit用于存储对象哈希码，4bit用于存储对象分代年龄，2bit用于存储锁标志位,1bit固定为0。

类型指针即对象指向它的类型元数据的指针，JVM通过这个指针来确定对象是哪个类的实例。但类型指针并不是一定存在的。

实例数据

实例数据部分是对象成员变量的值，包括父类继承下来的成员变量和本类的成员变量。

对齐填充

不是必然存在的，起到占位符的作用，因为HotSpot VM的自动内存管理系统要求对象起始地址必须是8字节的整数倍，对象头部分正好是整数倍，当实例数据部分没有对齐时，通过对齐填充来补全。

对象的访问定位

对象的存储空间在堆上分配，对象的引用在栈上分配，通过这个引用找到具体的对象，主流的访问方式有使用句柄和直接指针两种。

句柄访问方式

堆中需要划分一块内存来作为句柄池，reference中存储的就是对象的句柄地址，而句柄中包含了对象实例数据与类型数据各自具体的地址信息。句柄访问的最大好处就是引用中存放的是稳定句柄地址，在对象被移动时只会改变句柄中的实例数据指针。

直接指针访问方式

直接指针访问的最大好处就是速度更快，节省了一次指针定位的时间开销。

JVM之Java内存结构（一）

Sat, 21 Mar 2020 17:33:06 +0000

Java运行时数据区域

数据区域主要分为五个部分：

程序计数器

虚拟机栈

本地方法栈

堆

方法区

其中所有线程共享区域有：方法区和堆。

每个线程独享区域有：虚拟机栈，本地方法栈，程序计数器

线程独享的区域

程序计数器

程序计数器是一块较小的内存空间，它可以看作是当前线程所执行的字节码的行号指示器，如果当前线程执行的是一个本地方法，那么此时计数器的值为undefined，是唯一一个不会出现OutOfMemoryError的内存区域。

Java虚拟机栈

虚拟机栈描述的是Java方法执行的线程内存模型，每个方法被执行的时候，Java虚拟机都会同步创建一个栈帧，用于存放以下内容：

局部变量表

操作数栈

动态链接

方法出口

其中局部变量表包括以下内容：

八大基本数据类型

对象引用

returnAddress类型（保存的是return后要执行的字节码的指令地址）

这些数据类型在局部变量表中的存储空间以局部变量槽来表示，64位长度的long和double类型占用两个变量槽，其余的占用一个。局部变量表所需的内存空间在编译期间完成分配，方法运行期间不会改变局部变量表的大小。

Java 虚拟机栈会出现两种异常：StackOverFlowError 和 OutOfMemoryError。

如果线程请求的栈深度大于虚拟机所允许的深度，将抛出StackOverFlowError

如果Java虚拟机栈容量可以动态扩展，当栈扩展时无法申请到足够内存会抛出OutOfMemoryError

本地方法栈

本地方法栈是为JVM使用到的Native方法准备的空间。

线程共享的区域

堆

主要特点：

堆是被所有线程共享的一块内存区域

在虚拟机启动时创建

堆的唯一目的就是存放对象实例

堆是垃圾回收管理的内存区域

可分为新生代，老年代，永久代等（一部分垃圾收集器的共同特性或者设计风格，不是具体实现的固有内存布局）

从分配内存的角度看，所有线程共享的Java堆可以划分出多个线程私有的分配缓冲区（TLAB）以提升对象分配的效率，这样做可以更好地回收内存或者更快的分配内存。

堆的大小可以通过-Xmx和-Xms设定。

方法区

Java 虚拟机规范中定义方法区是堆的一个逻辑部分。用于存储以下内容：

已被虚拟机加载的类信息

常量

静态变量

即时编译器编译后的代码

方法区内的主要回收目标是对常量池的回收和对类型的卸载。

运行时常量池

运行时常量池是方法区的一部分。主要存放以下内容：

类信息（版本，字段，方法，接口等描述信息）

常量池表（用于存放编译期生成的各种字面量与符号引用）

Java并不要求常量一定在编译期间产生，并非Class文件中常量池的内容才能进入运行时常量池，运行期间产生的新的常量也能放入池中。比如String类的intern()方法。当常量池无法再申请到内存会抛出OutOfMemoryError

直接内存（堆外内存）

直接内存并不是虚拟机运行时数据区的一部分，也不是虚拟机规范中定义的内存区域，但是会被频繁地使用，也可能导致OutOfMemoryError 直接内存的分配不受JVM控制，但是会受到本机总内存（物理内存，SWAP分区，分页文件）以及处理器寻址空间的限制。

排序算法总结

Tue, 10 Mar 2020 20:19:19 +0000

性质

稳定性

稳定性指相等的元素经过排序之后相对顺序是否发生了改变。

时间复杂度

对于基于比较的排序算法的时间复杂度，较好的性能是$O(nlogn)$，坏的性能是$O(n^2)$。一个排序算法的理想性能是$O(n)$，但是平均而言不可能达到。

选择排序

Selection sort是较为简单的一种排序算法，每次找到第$i$小的元素，然后将这个元素与数组的第$i$个位置上的元素交换。换句话说：每次找到未完成排序的数组中最小的值，然后将其与边界（已排序和未排序元素的边界）进行交换。

由于swap操作的存在，因此该算法是一种不稳定的排序算法

选择排序的最优、平均、最坏时间复杂度都是$O(n^2)$。两层for

Java：

public static void selection(int[] arr){ int n = arr.length; for (int i = 1; i < n; i++) { int minIndex = i; for (int j = i + 1; j < n; j++) { if (arr[j] < arr[minIndex]){ minIndex = j; } } swap(arr, i, minIndex); } }
冒泡排序

Bubble Sort由于在算法的执行过程中，较小的元素像气泡一样慢慢浮到数组的顶端，故称为冒泡排序。

工作原理：每次检查相邻的两个元素，如果满足排序条件，则交换。经过$i$次扫描，数组末尾的$i$项必然是第$i$大的元素，因此冒泡排序最多需要扫描$n - 1$遍数组就能完成排序。

稳定的排序算法

序列完全有序时，冒泡排序只需遍历一次数组，不用执行任何交换操作，时间复杂度位$O (n) $

最坏情况下，需要进行$\frac{(n - 1)n}{2} $次交换操作。

平均时间复杂度为$O(n)$

public static void bubbleSort(int[] arr) { boolean flag = true; while (flag) { flag = false; for (int i = 1; i < arr.length -1; i++) { if (arr[i] > arr[i + 1]) { flag = true; swap(arr, i, i + 1); } } } }
插入排序

Insertion Sort：将待排序元素划分为已排序和未排序两部分，每次从未排序元素中选择一个插入到已排序的的元素中的正确位置。

编译OpenJDK

Sat, 22 Feb 2020 18:18:19 +0000

前言

最近在看《深入理解Java虚拟机》这本书，1.6节是编译openjdk，自己也想尝试一下。

使用操作系统为：Ubuntu 18.04 LTS

正文

下载源码

http://hg.openjdk.java.net/jdk/jdk12

书中提供的下载地址由于网络问题下载较慢，所以在Github的仓库下载，地址为：

https://github.com/openjdk/jdk

作者建议阅读doc/building.md，里面有详细的需要安装的编译环境与编译说明。

构建编译

使用bash configure进行设置编译参数。具体的编译配置参数可见doc/building.md。成功后命令行回显如下：

编译

输入make images进行编译。等大概二十分钟编译完成。

编译好的jdk位于build/配置名称/jdk，该目录可以直接当成完整的JDK进行使用。

至此，编译JDK工作完成。

分布式锁的实现方案

Thu, 02 Jan 2020 20:24:24 +0000

简介

分布式锁是控制分布式系统或不同系统之间共同访问共享资源的一种锁实现，如果不同的系统或同一个系统的不同主机之间共享了某个资源时，往往需要互斥来防止彼此干扰来保证一致性。

分布式锁需要具备的条件：

互斥性：在任意一个时刻，只有一个客户端持有锁。

无死锁：即使持有锁的客户端崩溃或者其他意外事件，锁仍然可以被获取。

容错：只要大部分Redis节点都活着，客户端可以获取和释放锁。

分布式锁的主要实现方式：

数据库

Redis等缓存数据库，redis的setnx

Zookeeper 临时节点

Redis 实现分布式锁

第一阶段

public void hello() { Integer lock = get("lock"); if(lock == null){ set("lock",1); //todo del("lock"); return; }else { //自旋 hello(); } }
存在的问题：

请求同时打进来，所有请求都获取不到锁

第二阶段

使用setnx设置锁

setnx在key不存在时可以设置，存在当前key则不操作

public void hello(){ String lock = setnx("lock"); //0代表没有保存数据，说明有人占坑了，1代表占坑成功 if(lock != 0){ //todo del("lock"); }else { //自旋 hello(); } }
存在的问题：

由于各种问题（未捕获的异常，断电）等导致锁未释放，其他人永远获取不到锁

第三阶段

public void hello(){ String lock = setnx("lock"); if(lock != 0){ expire("lock",10s); //todo del("lock"); }else { hello(); } }
存在的问题：

Linux学习笔记

Tue, 09 Jul 2019 18:38:46 +0000

Git命令记录

Thu, 30 May 2019 12:14:39 +0000

1. 基本操作

基本命令

mkdir notes cd notes # 初始化一个git仓库 git init echo "my notes" > readme.md # 查看状态 git status # 查看修改内容 git diff readme.md # 添加文件到仓库 git add readme.md # 提交更改 git commit -m "add readme" # 查看提交日志 git log # 回退到上一个版本 git reset --hard HEAD^ # HEAD: 当前版本 # HEAD^: 上一个版本 # HEAD~100: 前一百个版本 # 58a65b: 指定版本
工作区与暂存区

|-------| |-------| |-------| | 工作区 | -- add --> | 暂存区 | -- commit --> | 主分支 | |-------| |-------| |-------| # 查看工作区与暂存区文件的差异 git diff readme.md # 查看工作区和版本库最新版本的差异 git diff HEAD -- readme.md # 放弃工作区的修改(未执行 git add 命令) git checkout -- readme.md # 撤销暂存区（已经执行了 git add 命令） git reset HEAD readme.md
删除文件

# 删除文件 rm test.txt git add test.txt git commit -m "rm test.txt" # 直接从版本库中删除文件 git rm test.txt git commit -m "git rm test.txt" # 还原文件 git reset --hard CommitID
2. 远程仓库

Github仓库

# 在本地创建一个 gitlearn 目录，并进入 mkdir gitlearn cd gitlearn # 使用命令 git init 初始化一个库 git init # 添加远程库 origin git remote add origin git@github.com:l1nker4/gitlearn.git # 添加 readme.md 文件 echo "git learn is very easy!" > readme.md # 添加文件并提交到仓库 git add readme.md git commit -m "add readme" # 执行向远程仓库 origin master 分支推送更新（-u 参数用于关联远程仓库） git push -u origin master
更新远程仓库

# 查看当前分支的关联远程仓库 git branch -vv # 查看远程仓库的 URL git remote -v # 重新设置远程仓库的 URL git remote set-url origin git@github.com:l1nker4/gitlearn.git # 将当前修改更新到远程 master 分支 git push origin master
3.分支管理

创建与合并分支

# 查看当前分支 git branch # 基于当前分支创建新分支 git branch dev # 切换分支 git checkout dev # 创建并切换分支 git checkout -b dev # 切换到 master 分支 git checkout master # 合并指定分支到当前分支(合并 dev 分支到 master 分支) git merge dev # 删除分支 git branch -d dev
冲突管理

在 master 分支上修改 readme.md，新增一行内容。提交修改。在 dev 分支上修改 readme.md，也新增一行内容。提交修改。

Docker学习笔记

Mon, 27 May 2019 20:18:39 +0000

1.Docker概念

模型

虚拟机运行在虚拟的硬件上，应用运行在虚拟机内核上，而Docker是机器上的一个进程，Docker应用是Docker的一个子进程。

Docker是对Linux容器（LXC）的一种封装，提供简单易用的接口，Docker是目前最流行的Linux容器解决方案。

Docker用途

提供一次性的环境。主要用于测试。

提供云服务

组建微服务架构。

Docker引擎

Docker 引擎是一个包含以下主要组件的客户端服务器应用程序。

一种服务器，它是一种称为守护进程并且长时间运行的程序。

REST API用于指定程序可以用来与守护进程通信的接口，并指示它做什么。

一个有命令行界面工具的客户端。

Docker系统架构

Docker 使用客户端-服务器 (C/S) 架构模式，使用远程 API 来管理和创建 Docker 容器。

Docker 容器通过 Docker 镜像来创建。

容器和对象的关系可以类似于对象和类。

Docker镜像

在Linux下，内核启动会挂载root文件系统，Docker镜像就相当于一个root文件系统，它除了提供容器运行时所需的程序，资源，配置之外，还有一些配置参数（匿名卷，环境变量，用户）。

Docker镜像使用分层存储技术，它并非像ISO镜像那样的文件，镜像是一个虚拟的概念，它是由一组文件系统构成。

Docker容器

容器的本质是进程，容器进程运行于属于自己的命名空间，它可以拥有自己的root文件系统，自己的网络配置等宿主机可以有的东西。

每一个容器运行时，都是以镜像为基础层，在其上创建一个当前容器的存储层，可以称这个为容器运行时读写而准备的存储层为容器存储层。

Docker仓库

存放镜像的地方

2.安装Docker

1.获取脚本并下载

//从官网获取安装脚本 $ curl -fsSL get.docker.com -o get-docker.sh //使用AzureChinaCloud镜像脚本 $ sudo sh get-docker.sh --mirror AzureChinaCloud
2.启动Docker

$ sudo systemctl enable docker $ sudo systemctl start docker
3.建立Docker用户组

docker命令只有root用户和docker组的用户才能访问docker引擎

建立Docker组

$ sudo groupadd docker
将当前用户加入Docker组

$ sudo usermod -aG docker $USER
校验是否安装成功

l1nker4@zero:~$ docker version Client: Version: 18.09.6 API version: 1.39 Go version: go1.10.8 Git commit: 481bc77 Built: Sat May 4 02:35:57 2019 OS/Arch: linux/amd64 Experimental: false Server: Docker Engine - Community Engine: Version: 18.09.6 API version: 1.39 (minimum version 1.12) Go version: go1.10.8 Git commit: 481bc77 Built: Sat May 4 01:59:36 2019 OS/Arch: linux/amd64 Experimental: false
4. 添加镜像加速器

新建daemon.json文件

$ sudo touch /etc/docker/daemon.json
添加内容

{ "registry-mirrors": [ "https://registry.docker-cn.com" ] }
3.常用命令

1.镜像操作

名称命令作用

搜索 docker search xxx 搜索镜像

拉取 docker pull xxx 从仓库拉取镜像

列表 docker images 列出所有镜像

删除 docker rmi imageID 删除镜像

2.容器操作

名称命令说明

运行 docker run –name container-name -d image-name –name：自定义容器名，-d：后台运行，image-name：指定镜像模板

列表 docker ps 查看运行中的容器，-a：查看所有容器

停止 docker stop container-name/container-id 停止当前你运行的容器

启动 docker start container-name/container-id 启动容器

删除 docker rm container-id s删除指定容器

端口映射 -p 6379:6379 -p：主机端口映射到容器内部端口

docker run -d -p 8888:8080 tomcat
-d：后台运行，-p：端口映射

FastDFS使用入门

Sat, 25 May 2019 10:03:52 +0000

介绍

FastDFS是一个开源的分布式文件系统，主要有以下功能。

分布式文件系统（Distributed File System）是指文件系统管理的物理存储资源不一定直接连接在本地节点上，而是通过计算机网络与节点相连。

FastDFS主要有以下特点：

文件存储

文件同步

文件访问（上传、下载）

存取负载均衡

在线扩容

FastDFS的架构

由三个部分组成：Client，Tracker Server，Storage Server。

Client是上传下载数据的服务器，Tracker Server是跟踪服务器，主要做调度工作，起到负载均衡，管理所有的Storage Server。Storage Server：存储服务器，主要提供容量和备份服务。

FastDFS安装

安装环境

操作系统：Ubuntu 18.04

下载libfastcommon

wget https://github.com/happyfish100/libfastcommon/archive/V1.0.7.tar.gz
解压

tar -zxvf V1.0.7.tar.gz cd libfastcommon-1.0.7
编译安装

./make.sh ./make.sh install
设置软链接

ln -s /usr/lib64/libfastcommon.so /usr/local/lib/libfastcommon.so ln -s /usr/lib64/libfastcommon.so /usr/lib/libfastcommon.so ln -s /usr/lib64/libfdfsclient.so /usr/local/lib/libfdfsclient.so ln -s /usr/lib64/libfdfsclient.so /usr/lib/libfdfsclient.so
安装FastDFS

wget https://github.com/happyfish100/fastdfs/archive/V5.05.tar.gz tar -zxvf V5.05.tar.gz cd fastdfs-5.05 ./make.sh ./make.sh install
配置Tracker服务器

cd /etc/fdfs cp tracker.conf.sample tracker.conf vim tracker.conf
修改base_path为指定目录

Mybatis学习笔记

Mon, 08 Apr 2019 13:44:13 +0000

Mybatis简介

开源免费框架，原名叫iBatis

作用：数据访问层框架，底层是对JDBC的封装

优点：

使用mybatis时不需要编写实现类，只需要写执行的sql命令

Mybatis简单使用

mybatis-config.xml：全局配置文件

<?xml version="1.0" encoding="UTF-8" ?> <!DOCTYPE configuration PUBLIC "-//mybatis.org//DTD Config 3.0//EN" "http://mybatis.org/dtd/mybatis-3-config.dtd"> <configuration> <environments default="default"> <environment id="default"> <transactionManager type="JDBC"/> <dataSource type="POOLED"> <property name="driver" value="com.mysql.jdbc.Driver"/> <property name="url" value="jdbc:mysql://localhost:3308/learnjsp?useSSL=false"/> <property name="username" value="root"/> <property name="password" value="root"/> </dataSource> </environment> </environments> <mappers> <mapper resource="UserMapper.xml"/> </mappers> </configuration>
mapper.xml文件：编写需要执行的SQL命令，把XML文件理解成实现类

UserMapper.xml：配置了sql语句，以及sql的封装规则

<?xml version="1.0" encoding="UTF-8" ?> <!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN" "http://mybatis.org/dtd/mybatis-3-mapper.dtd">  <mapper namespace="com.test.UserMapper">  <select id="selectUser" resultType="com.test.model.User"> select uid,uname,pwd,sex,age from t_user where id = #{id} </select> </mapper>
测试

Spring学习笔记（一）

Thu, 14 Mar 2019 20:15:42 +0000

基础

Spring介绍

Spring是一个开源框架。

Spring为简化企业级应用开发而生，使用Spring可以使简单的JavaBean实现以前只有EJB才能实现的功能。

Spring是一个IOC(DI)和AOP容器框架。

轻量级：Spring是非侵入式的-基于Spring开发的应用中的对象可以不依赖于Spring的API

依赖注入(DI)：Dependency Injection，IOC

面向切面编程（AOP-aspect oriented programming）

容器：Spring是一个容器，因为它包含并且管理应用对象的生命周期

框架：Spring实现了使用简单的组件配置组合成一个复杂的应用，在Spring中可以使用XML和Java注解组合这些对象。

一站式：在IOC和AOP的基础上可以整合各种企业应用的开源框架和优秀的第三方类库

核心特性

IoC容器

Spring事件

资源管理

国际化

校验

数据绑定

类型转换

Spring表达式

面向切面编程

IOC和DI

IOC（Inversion of Control）：其思想是反转资源获取的方向。

传统的资源查找方式要求组件向容器发起请求查找资源，作为回应，容器适时的返回资源，而应用了IOC之后，则是容器主动地将资源推送给它所管理的组件，组件所要做的仅是选择一种合适的方式来接受资源，这种行为也被称为查找的被动形式。

IoC容器的职责：

依赖处理

依赖查找

依赖注入

生命周期管理

容器

托管的资源

配置

容器

外部化配置

托管资源

DI：IOC的另一种表述方式，即组件以一些预先定义好的方式（例如：setter方法）接受来自如容器的资源注入，相对于IOC而言，这种表述更直接。

配置Bean

配置形式：基于XML文件的方式，基于注解的方式

Bean的配置方式：通过全类名（反射），通过工厂方法（静态工厂方法&实例工厂方法），FactoryBean

<?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">  <bean id="helloWorld" class="HelloWorld"> <property name="name" value="Spring"/> </bean> </beans>
class：bean的全类名，通过反射的方式在IOC容器中创建bean，所以要求bean要有无参构造器

id：标识容易中的bean，id唯一

Spring提供了两种类型的IOC容器实现：

BeanFactory：IOC容器的基本实现

ApplicationContext 提供了更多的高级特大型，是BeanFactory的子接口

BeanFactory是Spring框架的基础设施，面向Spring本身

ApplicationContext 面向使用Spring框架的开发者，几乎所有的应用场合都直接使用ApplicationContext

ApplicationContext ctx = new ClassPathXmlApplicationContext("applicationContext.xml"); HelloWorld helloWorld = (HelloWorld) ctx.getBean("helloWorld");
利用id定位到IOC容器中的Bean

PHP-Challenge-1

Sat, 01 Dec 2018 19:48:06 +0000

PHP数组整数键名截断问题

Fri, 23 Nov 2018 17:02:35 +0000

PHP弱类型产生的安全问题

Fri, 09 Nov 2018 11:00:15 +0000

理解PHP变量覆盖漏洞

Thu, 01 Nov 2018 11:32:14 +0000

浅析文件上传漏洞

Mon, 01 Oct 2018 21:05:56 +0000

南京邮电大学CTF平台Web系列WriteUp

Mon, 25 Jun 2018 14:10:49 +0000

你好世界

Thu, 14 Jun 2018 19:34:14 +0000

About

Mon, 01 Jan 0001 00:00:00 +0000

Email：evl1nker4@gmail.com

Talk is cheap, show me the code.

Too young too simple, sometimes naive.

知其然知其所以然。

博客于2018年夏季搭建，用来记录在CS领域的学习成长之路。

对于时代而言，个人只是区区沙砾，对于个人而言，时代就是他的全部，生活中的点点滴滴、喜怒哀乐、成长经验等数据，构成了独一无二的人，这些都值得记录下来。

Links

Mon, 01 Jan 0001 00:00:00 +0000

ZGQ

Orange

D-Veda

类型	tag	描述
CONSTANT_utf8_info	1	UTF-8编码的字符串
CONSTANT_Integer_info	3	整型字面量
CONSTANT_Float_info	4	浮点型字面量
CONSTANT_Long_info	5	长整型字面量
CONSTANT_Double_info	6	双精度浮点型字面量
CONSTANT_Class_info	7	类或接口的符号引用
CONSTANT_String_info	8	字符串类型字面量
CONSTANT_Fieldref_info	9	字段的符号引用
CONSTANT_Methodref_info	10	类中方法的符号引用
CONSTANT_InterfaceMethodref_info	11	接口中方法的符号引用
CONSTANT_NameAndType_info	12	字段或方法的符号引用
CONSTANT_MethodHandle_info	15	表示方法句柄
CONSTANT_MethodType_info	16	标识方法类型
CONSTANT_InvokeDynamic_info	18	表示一个动态方法调用点

名称	命令	作用
搜索	docker search xxx	搜索镜像
拉取	docker pull xxx	从仓库拉取镜像
列表	docker images	列出所有镜像
删除	docker rmi imageID	删除镜像

名称	命令	说明
运行	docker run –name container-name -d image-name	–name：自定义容器名，-d：后台运行，image-name：指定镜像模板
列表	docker ps	查看运行中的容器，-a：查看所有容器
停止	docker stop container-name/container-id	停止当前你运行的容器
启动	docker start container-name/container-id	启动容器
删除	docker rm container-id	s删除指定容器
端口映射	-p 6379:6379	-p：主机端口映射到容器内部端口