学习笔记 on 洛克里亚的五度博客

Kafka 学习笔记

Sat, 18 Jul 2026 16:01:26 +0800

偏移量索引

高可用

ISR机制

软考系统架构师学习

Tue, 18 Jun 2024 12:51:35 +0800

本笔记基于考纲核心知识点整理，配合代码示例和记忆口诀，适合冲刺复习。

一、法律法规与标准化

1.1 著作权

类别	内容
不受保护	政府公文、法律条例、时事新闻
受保护	演讲稿、编写的图书、软件代码
归属时间	软件开发完成之日起自动产生
保护期限	50年（署名权、修改权、完整权永久保护）

著作权归属规则：

谁开发归谁
员工利用公司资源开发 → 归公司
职务作品无合同 → 归企业法人
改编作品 → 著作权归改编人

⚠️ 处理过程（算法逻辑）不属于软件著作权保护对象，只保护代码表达形式。

受时间限制的权利（50年）： 发表权、发行权、展览权、复制权
永久保护的权利： 署名权、修改权、保护作品完整权

1.2 其他知识产权

商标权：注册完成后才享有；保护对象为软件注册商标
专利权：专利注册完成后才享有

二、软件工程

2.1 软件开发模型对比

模型	适用场景	核心特征
瀑布模型	需求明确固定	阶段严格顺序，不可逆
增量模型	需求部分明确，需快速交付核心	分批次交付模块
原型模型	需求模糊，用户难以描述	先做原型再开发目标软件
螺旋模型	大型复杂高风险项目	每轮增加风险评估环节
喷泉模型	面向对象开发	无严格阶段划分，阶段可交叉迭代
V模型	可靠性要求高	开发与测试一一对应
W模型	质量要求高	开发与测试同步进行

瀑布模型阶段：
需求分析 → 系统设计 → 详细设计 → 编码 → 测试 → 维护
（每个阶段完成后才进入下一阶段）

螺旋模型四象限：
① 制定计划  ② 风险分析
③ 实施工程  ④ 客户评估

2.2 敏捷开发方法对比

方法	核心理念	关键特征
XP（极限编程）	把传统开发做到极致精简	结对编程、测试先行、持续集成
SCRUM	短周期冲刺	三会议（站会/计划/回顾），需求按商业价值排序
水晶开发	以人为本	最轻量灵活，重团队协作，文档少
FDD	特性驱动	五步：建模→功能清单→规划→设计→实现
ASD	适应性开发	猜测→协作→复盘，三个非线性阶段
DSDM	动态系统开发	八条原则，聚焦业务价值按时交付
开放源码	全球协作	高并行排障，代码公开

SCRUM 三大会议： 每日站会、迭代计划会、复盘回顾会

ElasticSearch 学习

Sat, 18 May 2024 12:51:05 +0800

1. 基础篇

1.1 起源：Lucene

Lucene：Apache 开源的 Java 全文搜索引擎类库。
优势：易扩展、高性能（纯 Java，可嵌入）。
缺点：使用复杂，需处理索引创建、查询解析等底层细节，无分布式支持。
Elasticsearch 基于 Lucene 构建，提供分布式、易用的 RESTful API。

1.2 技术栈（ELK）

Elasticsearch：存储、搜索和分析引擎。
Logstash：服务器端数据处理管道，采集、转换数据后发送至 ES。
Kibana：可视化平台，制作图表、仪表板，管理 ES。
Beats：轻量型数据采集器，发送到 Logstash 或 ES。

1.3 使用 Docker 安装

Elasticsearch（单节点）：

docker run -d --name es \
  -e "ES_JAVA_OPTS=-Xms512m -Xmx512m" \
  -e "discovery.type=single-node" \
  -v es-data:/usr/share/elasticsearch/data \
  -v es-plugins:/usr/share/elasticsearch/plugins \
  --privileged \
  --network testNet \
  -p 9200:9200 -p 9300:9300 \
  elasticsearch:7.12.1

9200：HTTP API 端口
9300：内部节点通信端口
discovery.type=single-node：单节点模式（测试用）

Kibana：

docker run -d --name kibana \
  -e ELASTICSEARCH_HOSTS=http://es:9200 \
  --network=testNet \
  -p 5601:5601 \
  kibana:7.12.1

1.4 倒排索引（Inverted Index）

正向索引：文档 ID → 文档内容。适合根据 ID 精确查找，但做模糊搜索需遍历所有文档，效率低。
倒排索引：
- 文档（Document）：ES 中存储的一条 JSON 数据。
- 词条（Term）：文档经过分词后的最小单元。
- 结构：词条 → 文档 ID 列表（及位置、频率等）。
- 优点：快速定位包含某个词条的所有文档，实现高效全文搜索。

1.5 分词器（Analyzer）

将文本拆分为词条（term）的组件，由三部分组成：

AWS 学习

Thu, 18 Apr 2024 12:48:03 +0800

面向系统架构师认证，结合 Java 后端视角整理。核心思路：每个服务解决什么痛点、何时选它、和类似服务怎么区分。

一、存储 Storage

1.1 三种存储类型对比

类型	代表服务	访问单元	典型场景
块存储	EBS, EC2 Instance Store	数据块（Block）	数据库、OS 磁盘
文件存储	EFS, FSx	文件/目录树	多实例共享、NFS/SMB挂载
对象存储	S3	对象（Object + Key）	静态资源、备份、数据湖

块存储  → 像本地硬盘，OS看到的是裸设备，自己格式化挂载
文件存储 → 像 NAS，多台机器可以同时 mount 同一个目录
对象存储 → 像 HTTP PUT/GET 的 Key-Value，无目录概念，靠前缀模拟

1.2 Amazon S3

核心功能速查：

功能	说明	常见考点
Versioning	同一 Key 保留多个历史版本	开启后才能用 CRR / MFA Delete
CRR（跨区域复制）	异步复制到另一 Region	灾备 DR、降低延迟
Transfer Acceleration	通过 CloudFront 边缘节点加速上传	上传到遥远 Region 时使用
Lifecycle Policy	对象按年龄自动迁移存储类	节省成本核心手段
S3 File Gateway	本地 SMB/NFS 映射到 S3	混合云文件迁移
Intelligent-Tiering	自动在 Standard ↔ IA 间切换	访问模式不可预测时使用

S3 存储类选择决策树：

Spring Cloud 学习

Mon, 18 Mar 2024 12:46:51 +0800

1. 服务拆分与远程调用

1.1 为什么要拆分服务？

单体应用随业务增长面临：部署慢、扩展性差、技术栈固化等问题。微服务将其拆分为独立部署、独立扩缩容的小服务，每个服务只负责一个业务域。

拆分原则：

单一职责：每个服务只做一件事
高内聚低耦合：服务内部紧密，服务之间松散
数据独立：每个服务拥有独立数据库

1.2 用户登录流程（微服务视角）

Client → Gateway（鉴权） → 业务微服务A → 微服务B（OpenFeign）
                ↓
           Nacos（服务发现）

1.3 RestTemplate — 微服务间原始调用

RestTemplate 是 Spring 提供的 HTTP 客户端，可用于微服务间调用，但代码繁琐、不支持负载均衡，是 OpenFeign 出现前的过渡方案。

// 注册为 Bean，并开启负载均衡
@Bean
@LoadBalanced
public RestTemplate restTemplate() {
    return new RestTemplate();
}

// 调用方式（服务名替代 IP:Port）
String url = "http://user-service/api/users/" + userId;
User user = restTemplate.getForObject(url, User.class);

⚠️ RestTemplate 已逐渐被 OpenFeign 取代，生产中优先选择 OpenFeign。

2. 服务治理 — Nacos 注册中心

2.1 解决的问题

微服务实例 IP / 端口动态变化，调用方无法硬编码地址。注册中心提供：

SSM框架学习

Sun, 18 Feb 2024 12:40:44 +0800

一、Spring IoC 容器

1.1 容器体系结构

BeanFactory（顶层接口）
    └── ApplicationContext（常用接口，扩展了BF）
            ├── ClassPathXmlApplicationContext（XML配置）
            ├── FileSystemXmlApplicationContext（文件路径XML）
            └── AnnotationConfigApplicationContext（注解配置）

BeanFactory vs ApplicationContext 核心区别：

特性	BeanFactory	ApplicationContext
Bean 初始化时机	懒加载（第一次 getBean 时）	饿加载（容器启动时）
功能	基础 IoC	IoC + 事件发布 + 国际化 + AOP等
使用场景	资源极度受限的嵌入式	99% 的业务场景

ApplicationContext 为什么没有 close()？
ApplicationContext 接口本身不定义 close()，是为了保持接口的通用性（不是所有容器都能/需要被关闭，如 Web 容器）。但其实现类 AbstractApplicationContext 实现了 Closeable，可以强转后调用，或用 ConfigurableApplicationContext 接口接收。

1.2 延迟加载（Lazy Loading）

// 注解方式：@Lazy 让 Bean 在第一次被使用时才初始化
@Bean
@Lazy
public HeavyService heavyService() {
    return new HeavyService();
}

// XML方式：
// <bean id="heavyService" class="..." lazy-init="true"/>

适用场景：初始化代价高、启动时不一定用到的 Bean（如某些连接池、第三方SDK客户端）。

MyBatis-Plus 学习

Tue, 16 Jan 2024 15:38:37 +0800

1. 简介

MyBatis-Plus（简称 MP）是一个 MyBatis 的增强工具，在 MyBatis 的基础上只做增强不做改变，为简化开发、提高效率而生。

核心特点：

无侵入：引入 MP 不会对现有 MyBatis 工程产生影响，犹如丝般顺滑。
损耗小：启动即会自动注入基本 CRUD，性能基本无损耗。
强大的 CRUD 操作：内置通用 Mapper、通用 Service，仅通过少量配置即可实现单表大部分 CRUD 操作。
支持 Lambda 形式调用：通过 Lambda 表达式，安全高效的编写查询条件，防止字段名误写。
内置代码生成器：通过少量配置即可生成 Mapper、Service、Controller 等代码。
内置分页插件：基于 MyBatis 物理分页，开发者无需关心具体操作，配置后即可使用。

官网：https://baomidou.com/

2. 基本用法

2.1 引入依赖

在 Maven 项目 pom.xml 中添加：

<dependency>
    <groupId>com.baomidou</groupId>
    <artifactId>mybatis-plus-boot-starter</artifactId>
    <version>3.5.3.1</version> <!-- 请按最新版本 -->
</dependency>

如果是传统 Spring 项目，可引入 mybatis-plus 核心依赖并自行配置。通常 Spring Boot 项目直接使用 starter。

2.2 定义实体类

@Data
public class User {
    private Long id;
    private String name;
    private Integer age;
    private String email;
}

2.3 编写 Mapper 接口

继承 BaseMapper<T> 即可获得 CRUD 能力：

学习笔记 on 洛克里亚的五度 博客