小菜鸟

密码学：加密算法的核心原理与应用

密码学是研究信息加密、解密及安全传输的学科，其核心目标是确保信息在存储和传输过程中的机密性、完整性、可用性和不可否认性。根据加密密钥的使用方式，密码学中的加密算法可分为对称加密和非对称加密两大类，两者各有优劣，在实际应用中常结合使用。

密码学的基本概念

在密码学中，信息的处理流程涉及以下核心术语：

• 明文（Plaintext）：未加密的原始信息（如文本、文件内容）。
• 密文（Ciphertext）：明文经过加密算法处理后得到的不可读信息。
• 加密算法（Encryption Algorithm）：将明文转换为密文的数学运算规则。
• 解密算法（Decryption Algorithm）：将密文还原为明文的数学运算规则（通常是加密算法的逆过程）。
• 密钥（Key）：加密和解密过程中使用的参数，决定了加密结果的唯一性（密钥不同，相同明文加密后密文不同）。

对称加密（共享密钥加密）

对称加密（Symmetric Encryption）又称 “私钥加密”，其核心特征是加密和解密使用同一个密钥，且该密钥需在通信双方之间共享。

核心原理

1. 密钥共享：通信双方（如 Alice 和 Bob）预先约定一个共享密钥（K），并确保密钥仅双方知晓。
2. 加密过程：发送方（Alice）使用密钥 K 对明文（M）进行加密，得到密文（C）：
   C = 加密算法(M, K)
3. 解密过程：接收方（Bob）使用同一密钥 K 对密文（C）进行解密，还原出明文（M）：
   M = 解密算法(C, K)

悲观锁与乐观锁：并发控制的两种核心策略

在多线程环境中，为保证共享资源的一致性，需通过同步机制控制并发访问。悲观锁与乐观锁是两种截然不同的设计思想，分别适用于不同的并发场景。理解它们的原理、适用场景及优缺点，是设计高效并发系统的基础。

悲观锁（Pessimistic Locking）

核心思想

总是假设最坏情况：每次操作共享资源时，都认为其他线程会同时修改该资源，因此必须先加锁，阻止其他线程访问，直到自己操作完成并释放锁。

实现方式

• 数据库层面：行锁、表锁、读锁（S 锁）、写锁（X 锁）等，如SELECT ... FOR UPDATE会对查询行加排他锁。
• Java 层面：
  • synchronized关键字：隐式加锁，自动释放锁。
  • ReentrantLock：显式加锁（lock()）和释放锁（unlock()），支持可重入、中断等特性。

工作流程

1. 线程访问共享资源前，先尝试获取锁（如synchronized块进入时）；
2. 若获取成功，独占资源并执行操作，期间其他线程会被阻塞（进入BLOCKED状态）；
3. 操作完成后释放锁（如synchronized块退出或unlock()），阻塞线程被唤醒并重新竞争锁。

优缺点

Elasticsearch 索引过程全解析：从写入到持久化的完整流程

Elasticsearch 的索引过程（文档写入、存储与检索）是其核心能力，涉及分片路由、内存缓冲、持久化机制、分段管理等多个环节。理解这一过程有助于优化写入性能、保障数据安全，并解释 “准实时搜索” 等特性的底层原理。

数据写入：分片路由机制

文档写入 Elasticsearch 时，首先需要确定存储到哪个主分片（副本分片仅用于同步和容错，不直接接收写入）。

分片路由公式

分片的分配通过以下公式计算：

1

shard = hash(routing) % number_of_primary_shards

• routing：路由键，默认是文档的 _id，也可在写入时通过 routing 参数自定义（如按用户 ID 路由，确保同一用户的文档在同一分片）。
• number_of_primary_shards：索引的主分片数量（创建后不可修改）。

示例：若索引有 3 个主分片，某文档 _id=123，则 hash(123) % 3 计算结果为 0、1 或 2，对应写入的主分片。

写入流程（协调节点与主 / 副本分片）

1. 请求接收：客户端向任意节点（协调节点）发送写入请求。
2. 路由计算：协调节点通过上述公式确定目标主分片，并转发请求到该主分片所在的节点。
3. 主分片写入：主分片节点写入文档，成功后同步请求到所有副本分片。
4. 响应确认：所有副本分片写入成功后，主分片节点向协调节点返回 “成功” 响应，最终反馈给客户端。

索引文档：从内存到磁盘的流转

文档写入主分片后，并非直接持久化到磁盘，而是经历 “内存缓冲→文件系统缓存→磁盘” 的多阶段流转，平衡性能与可靠性。

初始写入：Memory Buffer 与 Translog

数据一致性：分布式系统的平衡艺术

在分布式系统中，数据一致性是永恒的核心命题。不同于单机环境下通过锁和事务即可保证的数据一致性，分布式系统因节点分散、网络不可靠等特性，需在 “一致性”“可用性” 和 “分区容错性” 之间寻找平衡。CAP 理论和 BASE 理论为这种平衡提供了底层逻辑，而最终一致性则成为多数场景的务实选择。

CAP 理论：分布式系统的 “不可能三角”

CAP 理论由加州大学伯克利分校的 Eric Brewer 提出，揭示了分布式系统设计的根本约束：任何分布式系统都无法同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition-Tolerance），最多只能满足其中两项。

三大特性的核心定义

• 一致性（Consistency）：
  所有节点在同一时间访问到的数据完全一致。当数据在某个节点被修改后，所有节点需立即感知到最新值，不存在 “中间状态”。
  例：分布式数据库中，用户 A 修改了数据，用户 B 在任何节点查询都应看到更新后的值。
• 可用性（Availability）：
  任何合法请求都能在有限时间内获得响应（成功或失败），系统不会无响应或超时。即使部分节点故障，剩余节点仍需正常提供服务。
  例：电商网站在部分服务器宕机时，仍能响应用户的下单请求。
• 分区容错性（Partition-Tolerance）：
  当网络分区（节点间通信中断）发生时，系统仍能继续运行，不会因网络故障而整体崩溃。
  例：跨机房部署的系统，即使机房间网络中断，每个机房内的服务仍能独立工作。

三者的矛盾与取舍

分布式系统的节点通过网络连接，而网络分区是不可避免的（如光缆中断、路由故障），因此分区容错性（P）是必须满足的前提。在此基础上，系统只能在 “一致性（C）” 和 “可用性（A）” 中二选一：

分布式事务：从理论到实践的一致性解决方案

事务的 ACID 特性（原子性、一致性、隔离性、持久性）在单机数据库中通过锁机制和日志系统较易保证，但在分布式系统中，由于数据分散在多个节点，且节点间存在网络延迟、故障等不确定性，如何保证跨节点操作的原子性成为核心难题。本文将系统梳理分布式事务的理论模型、经典协议及工业界实践方案。

分布式事务的核心挑战

分布式事务的本质是跨节点操作的原子性：即多个节点的操作要么全部成功，要么全部失败，最终保证全局数据一致。其核心挑战源于：

• 网络不确定性：节点间通信可能超时、丢包，导致操作结果未知；
• 节点故障：部分节点宕机可能导致局部操作成功而其他节点失败；
• 性能与一致性权衡：强一致性方案往往伴随性能损耗，需根据业务场景取舍。

分布式事务规范与模型

1. X/Open DTP 模型：分布式事务的基础规范

The Open Group 提出的 X/Open DTP（Distributed Transaction Processing）模型定义了分布式事务的核心组件及交互方式，为实现分布式事务提供了标准框架。

核心组件：

• AP（Application Program）：应用程序，定义事务边界（开始、提交、回滚），并发起对多个资源的操作（如跨库转账）。
• RM（Resource Manager）：资源管理器，如数据库（MySQL、Oracle）、消息队列等，负责管理具体资源，并通过XA 接口向 TM 提供事务能力（提交、回滚）。
• TM（Transaction Manager）：事务管理器，协调所有 RM，负责全局事务的决策（提交或回滚），并通过 XA 接口与 RM 通信，确保所有分支事务一致。