小菜鸟

Vim 编辑器完全指南：从入门到高效操作

Vim 是 Linux 系统中最强大的文本编辑器之一，以其高效的操作模式和丰富的功能著称。掌握 Vim 的核心在于理解其三种工作模式（命令模式、插入模式、末行模式）及模式间的切换逻辑。本文将系统讲解 Vim 的使用技巧，帮助你从入门到精通。

Vim 三种核心模式

Vim 的强大之处在于其模式化设计，不同模式下的操作逻辑不同，熟练切换是高效使用的基础：

命令模式：高效操作的核心

命令模式是 Vim 的 “指挥中心”，几乎所有非输入操作都在此完成。以下是常用操作分类：

1. 光标移动

（1）基础移动（单字符 / 行）

• h：向左移动 1 字符
• l：向右移动 1 字符
• j：向下移动 1 行
• k：向上移动 1 行
• 0（数字 0）：跳转到行首第一个字符
• $：跳转到行尾最后一个字符

（2）快速移动（单词 / 段落）

• w：向后移动 1 个单词（以空格 / 标点分隔）
• b：向前移动 1 个单词
• ^：跳转到行首第一个非空白字符
• gg：跳转到文件首行
• G（Shift+g）：跳转到文件尾行
• nG（如 5G）：跳转到第 n 行
• Ctrl+f：向下翻一页
• Ctrl+b：向上翻一页
• Ctrl+d：向下翻半页
• Ctrl+u：向上翻半页

（3）屏幕定位

• H：将光标移到当前屏幕顶部
• M：将光标移到当前屏幕中间
• L：将光标移到当前屏幕底部

2. 文本删除

Redis 主从复制详解（基于 6.0.10 版本）

Redis 主从复制（Master-Slave Replication）是实现高可用和读写分离的核心机制，通过将主节点（Master）的数据同步到从节点（Slave），避免单点故障并分担读压力。本文详细解析主从复制的原理、配置方式、常见模式及哨兵（Sentinel）自动故障转移机制。

主从复制核心原理

主从复制通过 PSYNC 命令 实现数据同步，支持全量同步和部分同步两种模式，兼顾初次复制和断线重连场景。

PSYNC 命令的两种模式

• 全量同步（Full Resync）：适用于初次复制（Slave 首次连接 Master）。
  流程：
  1. Slave 向 Master 发送 PSYNC ? -1（表示需要全量同步）。
  2. Master 生成 RDB 快照，发送给 Slave；同时缓存快照生成期间的写命令（复制积压缓冲区）。
  3. Slave 加载 RDB 快照，再执行缓存的写命令，最终与 Master 数据一致。
• 部分同步（Partial Resync）：适用于断线重连（Slave 短暂断开后重新连接）。
  流程：
  1. Slave 重连后，向 Master 发送 PSYNC <master_runid> <offset>（携带上次同步的 Master 标识和偏移量）。
  2. Master 验证master_runid（自身标识）和offset（同步偏移量）：
     • 若有效（偏移量在复制积压缓冲区内），仅发送偏移量后的增量写命令。
     • 若无效（如 Master 重启或偏移量过期），触发全量同步。

核心概念

• master_runid：Master 的唯一标识（每次重启会变化），用于 Slave 验证连接的是否为同一 Master。
• 复制偏移量（Offset）：Master 和 Slave 分别维护的计数器，记录已同步的字节数（确保数据一致性）。
• 复制积压缓冲区：Master 端的环形缓冲区（默认 1MB），存储最近的写命令，用于部分同步。可通过 repl-backlog-size 调整大小（如 repl-backlog-size 10mb）。

主从复制配置

主从复制采用 “配从不配主” 原则：只需配置 Slave 指向 Master，Master 无需额外配置。

Redis 过期删除与内存淘汰机制详解（基于 6.0.10 版本）

Redis 允许为键设置过期时间，但如何高效处理过期键、避免内存溢出，是其性能优化的核心问题。不同于简单的定时删除，Redis 采用定期删除 + 惰性删除的混合策略处理过期键，并在内存不足时通过淘汰机制释放空间。本文详细解析这两种机制的原理、配置及实践建议。

过期键的删除策略

Redis 未采用 “每个过期键对应一个定时器” 的定时删除策略（避免 CPU 资源耗尽），而是结合定期删除和惰性删除，在内存占用与 CPU 消耗之间取得平衡。

1. 惰性删除（Lazy Eviction）

• 核心逻辑：键过期后不主动删除，仅在被访问时（如 get、hget 等命令）才检查是否过期。若过期，则删除该键并返回空；若未过期，则正常返回值。
• 优势：无需额外 CPU 资源监控过期键，仅在必要时执行删除，适合低频访问的过期键。
• 劣势：若过期键长期未被访问，会占用内存（“内存泄漏” 风险），需配合定期删除弥补。

2. 定期删除（Periodic Eviction）

• 核心逻辑：Redis 每隔一段时间（由hz配置控制，默认每秒 10 次）主动扫描部分过期键并删除，具体步骤：
  1. 从 “过期键字典”（专门存储设置了过期时间的键）中随机抽取 20 个键。
  2. 删除这 20 个键中已过期的键。
  3. 若过期键占比超过 25%，重复步骤 1（继续抽取删除），直至占比低于 25% 或达到最大扫描时间（默认 25ms）。
• 配置参数：
  • hz <num>：控制定期扫描的频率（默认 10，即每秒 10 次）。值越大，扫描越频繁，过期键删除越及时，但 CPU 消耗越高。
• 优势：主动清理长期未访问的过期键，减少内存浪费。
• 注意：为避免扫描耗时过长阻塞服务，单次扫描时间被限制在 25ms 内，因此无法保证所有过期键都被及时删除。

3. 主从结构中的过期键处理

在主从复制中，过期键的删除存在特殊逻辑：

• 主服务器：采用上述 “定期 + 惰性” 策略正常删除过期键，并向从服务器发送 del 命令。
• 从服务器：即使键已过期，也不主动删除，仅在收到主服务器的 del 命令后才删除。
• 潜在问题：主从同步存在延迟时，从服务器可能返回已过期的键（主服务器已删除，但 del 命令未同步），导致短暂的数据不一致。

内存淘汰机制（Maxmemory Policy）

当 Redis 内存使用达到 maxmemory 配置的阈值时，会触发内存淘汰机制，主动删除部分键以释放空间。淘汰机制的核心是 “按规则筛选并删除键”，具体规则由 maxmemory-policy 配置。

Hadoop性能调优Hadoop

在大数据处理场景中，Hadoop 集群的性能直接影响数据处理效率和资源利用率。性能调优需从操作系统底层到 Hadoop 组件参数进行全面优化，以下是详细的调优方向和实践建议。

操作系统参数调优

操作系统作为 Hadoop 运行的基础环境，其参数配置对集群稳定性和性能至关重要。

1. 增大文件打开限制上限

Hadoop 集群在运行过程中（尤其是 HDFS 和 MapReduce）会打开大量文件句柄，默认的系统文件打开限制可能无法满足需求，容易出现 “too many open files” 错误。

• 调整方法：使用ulimit命令临时设置，或通过配置文件永久生效。

  • 临时设置：ulimit -n 65535（将单个进程最大文件句柄数设为 65535）。

  • 永久生效：修改/etc/security/limits.conf文件，添加以下配置：

    1 2	* soft nofile 65535 * hard nofile 65535

  • 生效方式：重启服务器或重新登录用户。

2. 增大网络连接上限

Redis 持久化机制详解：RDB、AOF 与混合模式

Redis 作为内存数据库，数据默认存储在内存中，若发生宕机可能导致数据丢失。持久化机制通过将内存数据写入磁盘，确保数据可恢复。Redis 提供两种核心持久化方式：RDB（快照） 和 AOF（Append Only File），4.0 版本后新增 混合模式，结合两者优势。本文基于 Redis 6.0.10 版本，详细解析这三种机制的原理、配置与优缺点。

RDB 持久化（Redis DataBase）

RDB 是 Redis 默认的持久化方式，通过定时生成内存数据的快照（二进制文件）实现持久化，恢复时通过加载快照文件还原数据。

核心原理

• 快照生成：在指定时间间隔内，当写入操作满足触发条件时，Redis 会 fork 一个子进程，将内存数据完整写入临时文件，完成后替换旧快照文件（dump.rdb）。

• Copy On Write（COW）：fork 后父子进程共享内存数据，父进程处理新请求时，若修改数据会复制对应内存页（不影响子进程的快照生成），避免数据不一致。

  子进程在做数据持久化的过程中，只会进行遍历读取，但是父进程必须服务客户端请求，可能会对数据进行修改，此时使用COW(copy on write)机制，当父进程写数据时，将该内存页复制一份父进程来操作修改，其余的还是在共享内存内。随着父进程持续的修改数据，越来越多的共享页面被分离出来，内存会持续增长，但是最多也不会超过原有数据内存的2倍

  每一页是4K

配置参数（redis.conf）

RDB 配置位于 SNAPSHOTTING 模块，核心参数如下：

save 900 1 #15分钟内修改了1次
save 300 10 #5分钟内修改了10次
save 60 10000 #1分钟内修改了10000次

当达到条件时会触发bgsave命令

这个我测试了一下 save 300 3表示的是自上次生成rdb快照后，300s内如果有3次更改，在300s的时间节点时会触发一次bgsave命令，而不是写入3次后就立马触发

手动触发快照

• save 命令：由主线程执行，会阻塞所有客户端请求（直到快照完成），生产环境慎用。
• bgsave 命令：后台执行（background save），fork 子进程处理快照，主线程继续响应请求，不阻塞服务。