Redis

setex和setnx的区别

在Redis中，SETEX和SETNX是两种不同的命令，它们用于设置键值对，但具有不同的特性和用途：

1. SETEX（Set with Expire）：
   • SETEX命令用于设置一个键，并为其关联一个过期时间，这个键在指定的时间后会自动被Redis删除。
   • 语法：SETEX key seconds value
   • 参数说明：
     • key：键名。
     • seconds：键的过期时间，单位是秒。
     • value：与键关联的值。
   • 这个命令是原子的，即设置值和设置过期时间会在单个步骤中完成。
2. SETNX（Set if Not eXists）：
   • SETNX命令用于设置一个键，但只有当这个键不存在时才会设置成功。如果键已经存在，则SETNX不会对键进行任何操作。
   • 语法：SETNX key value
   • 参数说明：
     • key：键名。
     • value：与键关联的值。
   • 这个命令常用于实现锁机制，因为它的特性保证了只有在键不存在时才会设置新值，这可以用来避免多个客户端同时写入同一个资源。

主要区别：

• SETEX是设置键值对并带有过期时间，而SETNX仅用于设置键值对，但不允许覆盖已存在的键，并且没有设置过期时间的能力。
• 使用场景不同：SETEX适用于需要键值对在一定时间后自动过期的场景，而SETNX适用于需要确保键唯一性的场景，如分布式锁。

在Redis 2.6.12版本之后，SET命令新增了设置过期时间的功能，并且可以替代SETEX，例如使用SET key value [EX seconds] [PX milliseconds] [NX|XX]这样的语法来实现相似的功能。这使得SET命令变得更加灵活和强大。

如何在包含1亿个键的Redis中找出以特定前缀开头的大约10万个键

使用 KEYS 命令的问题

使用 KEYS 命令来查找匹配特定模式的所有键可能会导致性能问题，尤其是在生产环境中。这是因为 KEYS 命令会阻塞 Redis 服务器，直到所有匹配的键都被找到并返回。在 Redis 中，所有操作都是在一个单线程中执行的，因此 KEYS 命令会阻塞所有其他客户端的请求，直到它完成。对于一个包含 1 亿个键的数据库来说，这可能会导致显著的服务延迟甚至中断。

替代方案：使用 SCAN 命令

为了在不影响生产环境中的 Redis 服务器性能的情况下查找以特定前缀开头的键，应该使用 SCAN 命令。SCAN 命令是一个增量迭代器，它不会一次性返回所有匹配的键，而是每次返回一部分键。这使得 SCAN 命令在执行过程中不会阻塞 Redis 服务器，从而保证了其他客户端请求的正常处理。

SCAN 命令的特点

• 非阻塞性：SCAN 命令在执行时不会阻塞 Redis 服务器，因此不会影响其他客户端的操作。
• 增量迭代：每次调用 SCAN 命令都会返回一个游标，用于指示下一次迭代的起点。这使得 SCAN 命令可以逐步遍历数据库中的键。
• 可中断：如果客户端需要终止 SCAN 过程，可以随时停止调用 SCAN 命令。
• 可能的重复：SCAN 命令可能会在多次迭代之间返回相同的键，因此客户端需要处理重复的键。

Redis 的并发竞争问题是什么？了解 Redis 事务的 CAS 方案吗？

Redis 的并发竞争问题主要发生在多个客户端同时对同一个 key 进行写入操作时。由于 Redis 是单线程模型，虽然能保证命令的执行是原子的，但在并发环境下，客户端的请求可能会乱序执行，导致最终的数据结果与预期不符。以下是并发竞争问题的具体表现以及解决方法：

并发竞争问题：

1. 更新丢失（Lost Update）：当两个或多个客户端几乎同时读取同一个 key 的值，基于这个值进行一些计算或修改，然后写回新值时，后写入的操作可能会覆盖先前的写入，导致先前的更新丢失。
2. 脏读（Dirty Read）：在一个事务还未提交前，另一个事务读取了这个未提交的数据，这可能导致读取到不一致的数据状态。

解决方案：

1. 使用事务（MULTI...EXEC）：
   • 通过 MULTI 命令开启事务，将多个命令放入队列中，然后通过 EXEC 命令一次性执行。这保证了事务中的命令按顺序、原子性地执行。
2. 使用乐观锁（Optimistic Locking）：
   • 利用 WATCH 命令在事务开始前监视一个或多个 key。如果在 EXEC 执行前这些 key 被其他客户端修改，则事务会被中断，EXEC 返回 nil。客户端需要捕获这种情况并重新尝试事务或执行其他逻辑。

Redis 事务的 CAS 方案：

Redis 的事务支持类似 CAS（Compare and Swap，比较并交换）的乐观锁机制，具体步骤如下：

1. 监视键：使用 WATCH 命令监视可能发生并发修改的 key。
2. 开启事务：使用 MULTI 命令开始一个新事务。
3. 执行命令：在事务中执行需要的操作。
4. 执行事务：使用 EXEC 命令执行事务。如果监视的 key 在事务开启后被修改，EXEC 将失败并返回 nil。
5. 取消监视：无论事务是否成功执行，使用 UNWATCH 命令取消监视。

以下是详细的 CAS 方案流程：

WATCH mykey  # 监视 mykey，如果它被修改，后续事务将失败
MULTI        # 开启事务
SET mykey "new value"  # 尝试设置 mykey 的新值
EXEC         # 尝试执行事务

如果 mykey 在监视后、执行 EXEC 前被修改，EXEC 将返回 nil。客户端需要捕获这种情况，并根据业务逻辑决定是重试事务还是执行其他操作。

注意事项：

• Redis 的事务不支持自动回滚，因此在事务中的命令需要确保不会引发错误。
• 使用 WATCH 命令会增加额外的性能开销，因为它需要在事务执行时检查 key 的状态。
• 在处理并发竞争时，开发者需要考虑重试逻辑和事务失败时的回退策略。

如何检测并识别出缓存中的大Key？

1. 使用Redis自带命令检测：

   • DEBUG OBJECT命令： 通过执行DEBUG OBJECT key命令，我们可以获取到key的相关信息，包括内存使用情况。但是这个命令在生产环境中可能不是最佳选择，因为它会对Redis的性能产生一定影响。
   • SCAN命令结合MEMORY USAGE命令： 我们可以使用SCAN命令来迭代数据库中的所有key，并结合MEMORY USAGE命令来获取每个key的内存使用量。这种方法不会一次性加载所有key，因此对性能的影响较小。以下是命令示例：

     redis-cli --scan | xargs -L 1 redis-cli memory usage

2. 使用第三方工具：

   • redis-rdb-tools： 这个工具可以分析Redis的RDB快照文件，并输出每个key的大小和类型信息。使用它可以避免直接在生产环境中运行可能会引起性能问题的命令。
   • redis-bigkeys： 这个脚本能够扫描Redis实例并报告最大的key。使用方法如下：

     git clone https://github.com/weiyanwei4215/redis-bigkey
     python redis-bigkey.py

如果存在大Key问题如何解决

数据拆分

• 分片: 将一个大的数据集分割成多个较小的数据集，分别存储为不同的 key。
• 哈希表: 如果 key 存储的是多个字段的集合，可以考虑使用哈希表（HSET）来代替，将每个字段作为一个独立的 key-value 对存储。

数据压缩

• 对于文本数据，可以在存储到 Redis 之前进行压缩，比如使用 lz4 或 zlib。
• 在读取时再解压数据。

限制 key 的最大大小

• 使用 MAXLEN: 对于某些数据结构（如 list 和 stream），可以设置 MAXLEN 参数来限制其大小。
• 手动裁剪: 对于没有内置长度限制的数据结构，可以编写脚本或程序来手动裁剪数据。

避免阻塞

删除大Key可能会消耗较长时间，尤其是对于包含大量元素的数据结构（如大列表、大哈希等）。在删除过程中，其他操作可能会被阻塞，影响Redis的整体性能。建议在低峰时段进行删除操作，或者分批逐步删除。使用UNLINK命令代替DEL命令，UNLINK命令会在另一个线程中异步删除key，从而减少对主线程的影响。

Redis重启是如何进行数据恢复的？恢复数据的顺序

在Redis服务器重启过程中，数据恢复是通过以下步骤进行的：

1. 数据恢复机制：
   • Redis支持两种数据持久化机制：AOF（Append Only File）和RDB（Redis Database File）快照。
2. 恢复顺序：
   • 首先尝试AOF：如果Redis配置了AOF持久化，Redis在重启时会优先尝试从AOF文件恢复数据。AOF文件记录了所有的写操作命令，能够更完整地恢复数据状态。
   • 其次尝试RDB：如果没有启用AOF或者AOF文件损坏，Redis会尝试从RDB快照文件中恢复数据。RDB文件是一个在特定时间间隔或执行特定命令时生成的数据库快照。
3. 数据恢复过程：
   • 启动Redis服务：重启Redis服务时，Redis会自动检查是否存在AOF文件。
   • AOF恢复：如果AOF文件存在且启用，Redis会执行AOF文件中的命令来重建数据库状态。
   • RDB恢复：如果AOF文件不存在或损坏，Redis会检查是否存在RDB文件，并从中恢复数据。
   • 检查恢复结果：恢复完成后，可以通过INFO命令检查Redis的状态，确认数据是否恢复成功。

如果AOF文件损坏，可以使用redis-check-aof工具进行修复。

从AOF文件恢复通常比从RDB文件恢复要慢，因为它需要重新执行所有命令。

Linux

linux一个进程的线程挂了，进程状态会受影响吗

在Linux操作系统中，进程是由一个或多个线程组成的。如果一个进程的某个线程挂了（即线程执行失败或被终止），这确实可能会影响整个进程的状态，具体情况如下：

1. 主线程挂了：如果挂掉的是进程的主线程，那么整个进程通常会终止。因为主线程通常负责进程的主要执行流程，一旦它退出，进程就没有存在的意义了。
2. 子线程挂了：如果挂掉的是进程中的一个子线程，那么：
   • 如果进程没有对子线程的退出进行适当的处理，那么它可能会继续运行，但是可能会因为线程的异常退出而处于不稳定的状态。
   • 如果进程设置了线程退出信号的处理（例如，使用 pthread_cleanup_push 和 pthread_cleanup_pop），那么它可以清理资源并尝试恢复或优雅地终止。
   • 如果多个线程共享资源，而一个线程在持有锁的情况下挂掉，可能会导致死锁或资源泄露，影响进程的稳定性。
   • 如果线程是因为访问非法内存、除以零等运行时错误挂掉的，那么这可能会导致整个进程接收到信号而终止。

在多线程程序设计中，通常需要对线程的异常退出进行妥善处理，以保证程序的健壮性和稳定性。可以使用如下方法来减少线程失败对进程的影响：

• 线程分离：使用 pthread_detach 将线程分离，这样线程结束时资源会自动被回收，不会产生僵尸线程。
• 错误处理：在线程函数中加入错误处理逻辑，确保即使在出错的情况下也能释放资源并通知主线程或其他相关线程。
• 信号处理：捕捉并处理可能导致线程退出的信号，如 SIGSEGV（段错误）。

TCP和UDP是否可以共用同一个端口号

在同一个网络接口上，TCP和UDP协议可以使用相同的端口号，但是它们不能共享同一个套接字。这是因为TCP（传输控制协议）和UDP（用户数据报协议）是两种不同的传输层协议，它们有不同的通信机制和数据传输特点。

1. 端口号的作用：端口号用于区分不同的服务或应用进程。一个端口号码在TCP和UDP中是独立的，因此，同一个端口号可以同时被TCP和UDP使用。
2. 协议层的区分：尽管TCP和UDP可以使用相同的端口号，但是它们的数据包在传输层通过协议字段来区分。当一个数据包到达时，它会被操作系统根据其协议类型（TCP 或 UDP）进行分类。如果是 TCP 数据包，则会被路由到 TCP 协议栈中相应的端口；如果是 UDP 数据包，则会被路由到 UDP 协议栈中相应的端口。因此，即使 TCP 和 UDP 使用相同的端口号，它们也不会互相干扰。
3. 套接字：在网络编程中，一个套接字是由IP地址、端口号和协议类型三个元素唯一确定的。因此，即使是相同的IP地址和端口号，只要协议类型不同（一个是TCP，一个是UDP），它们就会对应不同的套接字。

线上Java应用出现响应延迟和性能卡顿如何定位和解决

定位问题

查看CPU和内存使用情况

• 使用命令如 top, htop 或 vmstat 查看进程的CPU和内存使用情况。如果CPU使用率很高或者内存占用过大，可能是资源不足导致的卡顿。

分析线程栈

1. 获取进程ID（PID）：

   • 首先，需要找到要分析的Java进程的PID。可以使用 jps 命令来列出所有Java进程及其PID。

   jps

2. 执行 jstack 命令：

   • 使用 jstack 命令获取指定PID的线程栈信息。

   jstack [pid] > thread-stack.txt

   这会将线程栈信息输出到一个文本文件中，便于后续分析。

3. 分析线程栈文件：

   • 打开 thread-stack.txt 文件，开始分析线程栈信息。
   • 寻找线程状态，尤其是 RUNNABLE 状态的线程，因为它们正在使用CPU资源。

4. 查看线程状态：

   • 线程栈中会显示每个线程的状态，如 RUNNABLE, BLOCKED, WAITING, TIMED_WAITING 等。
   • 特别关注那些状态为 RUNNABLE 且占用CPU时间较长的线程。

5. 识别线程操作：

   • 对于每个 RUNNABLE 线程，查看其堆栈跟踪，确定它们正在执行哪些操作。
   • 堆栈跟踪显示了线程当前执行的方法调用链，可以帮助定位到具体的代码行。

6. 查找锁竞争：

   • 查看是否有多个线程在等待同一个锁，这可能表明存在锁竞争。
   • 检查 BLOCKED 状态的线程，查看它们在等待哪个锁。

7. 重复栈信息：

   • 如果多个线程的栈信息看起来非常相似，这可能是线程池中所有线程都在等待同一个资源或者执行同一个任务。

8. 分析线程数量：

   • 检查线程的总数是否合理。过多的线程可能会导致上下文切换频繁，影响性能。

9. 使用工具辅助分析：

   • 可以使用如 VisualVM, JProfiler, YourKit 等可视化工具，它们可以更直观地展示线程状态和堆栈信息。

查看GC日志

• 分析GC日志（可以通过 -verbose:gc -XX:+PrintGCDetails -Xloggc:gc.log 参数开启），查看垃圾回收是否频繁或者耗时过长，这可能导致应用响应缓慢。

分析磁盘I/O

• 使用命令如 iostat 或 iotop 查看磁盘I/O情况。如果磁盘I/O很高，可能是磁盘操作导致的卡顿。

网络分析

1. 使用 netstat 检查网络连接：
   • netstat -antp：查看所有活跃的网络连接，包括TCP连接的状态（LISTEN、ESTABLISHED等），以及对应的进程ID（PID）和程序名。
   • netstat -ano：查看所有连接，包括正在监听的端口和IP地址。
   • 通过查看连接数和状态，可以判断是否有大量的连接积压，或者是否有异常的连接状态，如大量的TIME_WAIT或CLOSE_WAIT。
2. 使用 netstat 检查端口使用情况：
   • netstat -an | grep [port number]：针对特定端口进行过滤，查看是否有大量的连接请求或连接问题。
3. 使用 tcpdump 抓包分析：
   • tcpdump -i any -nn -s0 -w capture.pcap：开始抓取所有接口上的数据包，并且不进行DNS解析（-nn），不限制抓取长度（-s0），并将结果写入文件（capture.pcap）。
   • 抓包后，可以使用Wireshark等工具打开capture.pcap文件进行详细分析。
   • 在Wireshark中，可以查看数据包的传输时间、大小、延迟、重传次数等，以确定是否存在网络延迟或数据包丢失的问题。
4. 分析网络延迟：
   • 使用 ping 命令测试网络延迟，例如 ping [ip address]。
   • 使用 traceroute 或 tracert（Windows）命令查看数据包到达目的地的路径和延迟。

数据库查询分析

• 如果应用使用了数据库，检查慢查询日志，查看是否有耗时的数据库操作。

步骤流程

1. 确认资源瓶颈
   • 使用系统监控工具（如Prometheus + Grafana）确认服务器资源使用情况。
2. 定位Java进程问题
   • top - 确认Java进程的资源占用情况。
   • jstack [pid] - 查看线程栈，找出长时间运行的线程。
   • jmap -heap [pid] 或 jstat -gcutil [pid] - 查看堆内存使用情况。
   • jvisualvm 或 jmc - 使用可视化工具进一步分析。
3. 分析应用日志
   • 查看应用日志，寻找可能的异常或者错误信息。
4. 性能分析
   • 使用Java性能分析工具（如VisualVM, JProfiler, YourKit等）进行更深入的分析。
5. 测试和对比
   • 如果可能，对比不同时间段的性能数据，或者在不同环境（测试、预发、生产）中进行对比测试。
6. 优化和调整
   • 根据分析结果，对代码、JVM参数、系统配置等进行优化。

查看哪个进程正在使用特定的文件

在Linux系统中，如果我们需要查看哪个进程正在使用特定的文件，可以使用以下几种方法：

方法1：lsof 命令

lsof（list open files）命令可以列出系统上所有打开的文件以及访问这些文件的进程。

要使用lsof查看哪个进程正在使用某个文件，我们可以执行以下命令：

lsof /path/to/file

将/path/to/file替换为我们想要检查的文件的路径。

方法2：fuser 命令

fuser命令可以列出正在访问指定文件的进程的PID。

要使用fuser，我们可以执行以下命令：

fuser -m /path/to/file

选项-m告诉fuser列出使用该文件或该文件所在目录的进程。

方法3：ps 命令结合grep

如果我们知道文件名的一部分，可以使用ps命令结合grep来查找可能正在使用该文件的进程。

ps aux | grep '/path/to/file'

这个命令会列出所有进程及其命令行参数，然后通过grep筛选出包含指定文件路径的进程。

示例

假设我们想要查看哪个进程正在使用/var/log/syslog文件：

使用lsof：

lsof /var/log/syslog

使用fuser：

fuser -m /var/log/syslog

使用ps和grep：

ps aux | grep '/var/log/syslog'

请记住，一些进程可能以root用户身份运行，因此我们可能需要使用sudo来获取完整的信息。例如：

sudo lsof /path/to/file

使用这些命令，我们应该能够找到正在使用特定文件的进程，并获取到该进程的PID和其他相关信息。

MySQL

mysql如何实现死锁

死锁的发生条件

死锁通常发生在以下四个条件同时满足时：

1. 互斥条件：资源不能被多个事务同时使用。
2. 持有和等待条件：事务持有至少一个资源，并且正在等待获取额外的资源，而该资源又被其他事务持有。
3. 非抢占条件：事务持有的资源在完成前不能被抢占。
4. 循环等待条件：存在一个事务集，每个事务都在等待另一个事务持有的资源，形成了一个等待循环。

在MySQL中，死锁通常是在事务处理中发生的，当两个或更多的事务永久阻塞彼此，每个事务都在等待另一个事务释放资源。为了演示如何在MySQL中“实现”或触发一个死锁，我们可以构造一个特定的场景。

下面是一个简单的例子，假设我们有一个简单的表 test_table 和两个事务（会话）来触发死锁：

1. 创建测试表:

   CREATE TABLE test_table (
       id INT AUTO_INCREMENT PRIMARY KEY,
       value INT NOT NULL
   );

2. 插入测试数据:

   INSERT INTO test_table (value) VALUES (1), (2);

3. 打开两个MySQL客户端会话:

   • 会话A
   • 会话B

4. 在会话A中开始事务并锁定一行:

   START TRANSACTION;
   SELECT * FROM test_table WHERE id = 1 FOR UPDATE;

5. 在会话B中也开始事务并锁定另一行:

   START TRANSACTION;
   SELECT * FROM test_table WHERE id = 2 FOR UPDATE;

6. 让会话A尝试锁定会话B已经锁定的行:

   SELECT * FROM test_table WHERE id = 2 FOR UPDATE;

7. 让会话B尝试锁定会话A已经锁定的行:

   SELECT * FROM test_table WHERE id = 1 FOR UPDATE;

此时，会话A正在等待会话B释放行2，而会话B正在等待会话A释放行1，这样就形成了一个死锁。

在默认情况下，MySQL自身具有死锁检测机制，可以自动回滚其中一个事务以打破死锁。可以通过查看 INFORMATION_SCHEMA.INNODB_LOCKS 表来检查死锁状态。

如果想查看死锁发生时的信息，可以在任一会话中执行：

SHOW ENGINE INNODB STATUS;

这将显示当前InnoDB引擎的状态信息，包括任何可能发生的死锁。

为什么在表字段设计中不推荐使用可空值

在MySQL数据库的表字段设计中不推荐使用可空值（NULL）。主要原因可以归纳为以下几点：

1. 额外的存储空间：MySQL中的NULL列需要额外的存储空间来记录这些列的值是否为NULL。对于MyISAM表，每个NULL列都需要额外的一个位（bit）空间，这会影响存储效率。
2. 查询优化难度：MySQL难以优化引用可空列的查询。可空列会使索引、索引统计和值比较变得更加复杂。当可空列被索引后，每条记录都需要一个额外的字节，这可能导致MyISAM中固定大小的索引变成可变大小的索引，从而影响性能。
3. NULL值的更新问题：NULL值到非NULL值的更新无法做到原地更新，更容易发生索引分裂，影响性能。MySQL的数据存储和索引组织方式使得NULL值的更新更加复杂。
4. 开发中的便利性误解：一些程序员认为使用NULL可以简化SQL语句的编写，但实际上，这可能导致查询和数据处理时出现难以预料的问题。

BLOB和TEXT类型的区别

MySQL中的BLOB和TEXT类型都是用于存储大量数据的字符串类型，但它们之间有几个关键区别：

1. 数据类型：BLOB是二进制大对象，用于存储二进制数据，而TEXT用于存储非二进制字符串。
2. 字符集和排序：BLOB使用二进制字符集和校对，比较和排序基于字节数值。TEXT则使用非二进制字符集，其值的排序和比较基于字符集的校对规则。
3. 大小和存储需求：BLOB和TEXT都有四种类型（TINYBLOB/BLOB/MEDIUMBLOB/LONGBLOB 和 TINYTEXT/TEXT/MEDIUMTEXT/LONGTEXT），它们之间的区别在于能存储的最大长度。
4. 索引处理：TEXT列的索引条目比较会在末尾添加空格，可能导致唯一性约束问题。而BLOB列不会这样处理。
5. 默认值：BLOB和TEXT列不能有默认值。
6. 内部表示：每个BLOB或TEXT值内部由一个单独分配的对象表示，与其他数据类型不同。
7. 应用场景：BLOB通常用于存储如图片、音频等这样的二进制数据，而TEXT用于存储文本数据。

如何确保单个实例的buffer数据与磁盘数据的强一致性

MySQL为了保证单个实例中buffer pool中的数据与磁盘上的数据保持强一致性，主要依赖于以下几个机制：

1. Write-Ahead Logging (WAL): 在InnoDB存储引擎中，所有的修改操作都会先写入日志文件（即redo log），然后再写入buffer pool。如果系统发生故障，可以通过redo log来恢复数据。
2. Double Write Buffer: InnoDB使用了一个称为double write buffer的机制来保证页的完整性。当缓冲池中的页被刷新到磁盘时，首先会写入到一个连续的内存区域（double write buffer），大小为2MB。成功写入double write buffer后，才会将页写入实际的数据文件。如果写入过程中发生崩溃，InnoDB可以在恢复时使用double write buffer中的数据来修复可能损坏的页。
3. Checkpointing: InnoDB定期进行checkpoint操作，将脏页（modified pages in the buffer pool）刷新到磁盘。这样可以减少恢复时需要重做的日志量。

Write-Ahead Logging

1. 日志记录:
   • 当一个事务尝试修改数据库中的数据时，InnoDB首先会将这些修改操作记录到redo log中。这些日志记录包含了足够的信息，以便在系统故障后能够重放这些操作。
2. 缓冲池（Buffer Pool）修改:
   • 在记录了redo log之后，事务的修改操作会被应用到缓冲池中的相应页面上。缓冲池是InnoDB在内存中用来缓存频繁访问的数据和索引的结构。
3. 日志提交:
   • 一旦事务提交，InnoDB确保redo log被刷新到磁盘上，这样即使发生系统故障，这些日志也不会丢失。

• redo log的结构:

  • redo log由一系列的日志记录组成，每个记录描述了对数据库页的一个修改操作。这些记录按顺序编号，形成了一个连续的日志流。

• 持久性保证:

  • redo log的写入是按照特定的顺序进行的，即先写日志，再修改缓冲池中的数据。这种顺序保证了即使在修改操作尚未写入磁盘时发生故障，也能够通过redo log恢复这些操作。

• 检查点（Checkpoint）:

  • 为了避免redo log无限增长，InnoDB会定期执行检查点操作，将缓冲池中的脏页（修改过的页面）刷新到磁盘上。在刷新脏页之前，对应的redo log记录不再需要，因此可以被覆盖。

• 恢复过程:

  • 在系统启动或故障恢复时，InnoDB会检查最后一个检查点之后的redo log，并重放这些日志记录来恢复缓冲池中的数据页。这个过程称为崩溃恢复（crash recovery）。

• 组提交（Group Commit）:

  • 为了提高性能，InnoDB实现了组提交机制，允许多个事务的redo log在同一时间点被刷新到磁盘。这样可以减少磁盘I/O操作的次数。

• redo log文件管理:

  • redo log通常存储在磁盘上的一个或多个文件中。这些文件以循环方式使用，当日志文件写满时，InnoDB会回绕到第一个日志文件，并覆盖旧的记录。

• 配置选项:

  • InnoDB提供了多个配置选项来调整redo log的行为，例如innodb_log_file_size（日志文件大小）和innodb_log_files_in_group（日志文件组中的文件数量）。

• 性能提升:

  • 由于不需要每次数据修改都立即写入磁盘，WAL减少了磁盘I/O操作，提高了事务处理的性能。

• 数据完整性:

  • 在系统故障后，WAL确保了所有已提交事务的持久性，因为它们已经被记录在redo log中。

• 故障恢复:

  • 通过重放redo log，InnoDB可以在系统重启后恢复到故障前的状态，确保数据库的一致性。

Double Write Buffer

1. 内存中的Double Write Buffer:
   • Double Write Buffer是一块连续的内存区域，大小为2MB（这是默认大小，可以通过配置参数innodb_doublewrite_file和innodb_doublewrite_pages进行调整）。
2. 写入流程:
   • 当InnoDB准备将缓冲池中的一个脏页（即已经被修改但尚未写入磁盘的页）刷新到磁盘时，不是直接写入数据文件，而是先将其复制到Double Write Buffer。
   • 一旦脏页成功写入Double Write Buffer，InnoDB就会将页写入到实际的数据文件（.ibd文件）中。
3. 崩溃恢复:
   • 如果在将页写入数据文件的过程中发生系统崩溃（例如，操作系统崩溃或电源故障），Double Write Buffer中的数据可以用来恢复损坏的页。
   • 当系统重启时，InnoDB会检查数据页的校验和（checksum）。如果发现页损坏，它会使用Double Write Buffer中的副本来恢复该页。

• 部分写入问题:
  • 硬盘或文件系统通常以扇区为单位写入数据。如果一个16KB的InnoDB页在写入过程中发生崩溃，可能只有部分扇区被写入，导致页损坏。Double Write Buffer通过先写入一个连续的内存区域，再写入磁盘，来避免这种情况，因为连续的内存写入是原子的。
• 性能考虑:
  • Double Write Buffer虽然增加了写入的步骤，但由于内存写入速度非常快，所以对性能的影响很小。此外，这种额外的写入操作只在脏页刷新时发生，而不是每次写入操作。
• 页的校验和:
  • InnoDB为每个页计算校验和，并将其存储在页的头部。在恢复过程中，InnoDB会使用存储的校验和与页的实际校验和进行比较，以确定页是否损坏。
• 恢复过程:
  • 在恢复过程中，InnoDB会检查redo log来确定哪些页应该被写入磁盘。如果页的校验和不匹配，InnoDB会使用Double Write Buffer中的数据来恢复该页。
• 配置选项:
  • 默认情况下，Double Write Buffer是开启的。但是，在某些情况下，例如使用具有原子写入特性的存储设备时，可以通过设置innodb_doublewrite=0来禁用Double Write Buffer。

Checkpointing

1. 脏页（Dirty Pages）:
   • 当缓冲池（Buffer Pool）中的页被修改后，这些页被称为“脏页”。脏页包含了尚未写入磁盘的数据。
2. 定期刷新:
   • InnoDB会定期执行checkpoint操作，将缓冲池中的脏页刷新到磁盘上的数据文件中。
3. 减少日志重做:
   • 通过将脏页写入磁盘，对应的redo log记录就不再需要用于恢复这些页，从而减少了系统崩溃后恢复时需要重做的日志量。

• Checkpoint的类型:

  • Sharp Checkpoint：在数据库关闭时发生，此时InnoDB会将所有脏页写入磁盘。
  • Fuzzy Checkpoint：在数据库运行时发生，不会刷新所有脏页，而是根据一定的策略选择部分脏页进行刷新。

• 触发条件:

  • 定期触发：InnoDB会根据一定的间隔（如每秒或每10秒）执行一次checkpoint。
  • 缓冲池空间不足：当缓冲池中没有足够的空闲空间来容纳新的页时，InnoDB可能会触发checkpoint。
  • redo log空间不足：当redo log空间快被占满时，InnoDB会触发checkpoint来释放一些日志空间。

• LSN（Log Sequence Number）:

  • LSN是InnoDB中用于标识redo log记录和应用顺序的序列号。Checkpoint操作会记录一个LSN，称为“checkpoint LSN”，表示所有小于该LSN的redo log记录对应的脏页都已写入磁盘。

• 恢复优化:

  • 在系统崩溃恢复时，InnoDB只需要重放从最后一个checkpoint LSN到日志末尾的redo log记录，这显著减少了恢复所需的时间。

• 写入策略:

  • InnoDB使用一种称为“写前日志”（Write-Ahead Logging, WAL）的策略，确保在修改数据页之前，相应的日志记录已经被写入到磁盘上的redo log文件。

• 配置选项:

  • InnoDB提供了几个与checkpoint相关的配置选项，例如innodb_io_capacity（用于控制脏页刷新到磁盘的速度）和innodb_flush_log_at_trx_commit（控制事务提交时redo log的刷新策略）。

• 数据持久性:

  • 通过定期将脏页写入磁盘，checkpointing确保了数据的持久性，即使发生系统故障，数据也不会丢失。

• 性能优化:

  • Checkpointing有助于减少redo log文件的大小，避免其在磁盘上无限增长，同时通过及时刷新脏页，可以优化缓冲池的空间利用率。

• 恢复时间:

  • 在系统崩溃后，由于不必重做所有redo log记录，恢复时间得到了显著缩短。

MySQL 中有哪几种锁

MySQL中的锁类型主要包括全局锁、表级锁、行级锁等多种类型，每一类锁都有其特定的用途和功能。

1. 全局锁
   • 定义：全局锁是锁定数据库中所有表的锁，主要用于数据库的逻辑备份过程中，保证数据的一致性。
   • 特点：全局锁一旦加锁，整个数据库只能读取，不能进行任何写操作。这种锁通常不会长时间存在，仅在必要的维护操作或备份时临时使用。
2. 表级锁
   • 共享锁：允许多个事务同时持有共享锁，主要应用于读取操作。一个事务获取了共享锁后，其他事务也可以获取共享锁，但不能获得排他锁。
   • 排他锁：一个事务获得排他锁后，其他事务不能获取任何类型的锁，直到该锁释放。这种锁确保了在进行数据修改时的独占性和隔离性。
   • 意向锁：包括意向共享锁（IS）和意向排他锁（IX），这些锁表明一个事务有意在未来锁定某些数据行。意向锁主要配合表锁使用，提高锁定检查的效率。
3. 行级锁
   • 行共享锁：允许一个事务获取多行数据的共享锁，用于读取操作。这种锁允许多个事务同时读取同一行，但不允许修改。
   • 行排他锁：用于数据修改操作，确保一个事务在修改数据时，其他事务不能进行任何操作包括读取和修改。
   • 间隙锁：防止新数据插入到现有数据的间隙中，解决幻读问题。这种锁在可重复读隔离级别下自动启用。
   • 临键锁：间隙锁和行锁的组合，锁定一个范围的前开后闭区间，也是防止幻读的重要手段。
4. 页锁

• 页锁锁定的是数据库中的一个页（通常是4KB大小），适用于MyISAM存储引擎。

查询SQL的执行过程

后端

如何防止接口重复提交

使用Token机制

• 生成Token：在表单提交之前，服务器生成一个唯一的Token，并将其发送给客户端。
• 存储Token：客户端在提交表单时，将Token一起发送到服务器。
• 验证Token：服务器接收到请求后，验证Token是否有效，如果有效则执行业务逻辑，并删除Token；如果无效或已使用，则拒绝请求。

使用Redis等缓存实现分布式锁

• 在提交请求前，先在Redis中设置一个键值对，键为请求的唯一标识，值为任意内容。
• 提交请求时，检查Redis中该键是否存在，如果存在则认为是重复提交，如果不存在则继续处理，并设置键值对。
• 处理完成后，删除Redis中的键值对。

使用前端方案

• 禁用按钮：在表单提交后，禁用提交按钮，防止用户重复点击。
• JavaScript拦截：使用JavaScript来控制表单提交，确保在短时间内只能提交一次。

使用HTTP头部信息

使用 HTTP 头部信息如 Etag 或 If-None-Match 来控制请求处理是一种实现请求幂等性的方法，尤其是在 GET 请求中用来避免重复获取相同资源。但对于 POST 请求来说，这些头部信息通常用于避免重复提交问题。

ETag (实体标签)

ETag 是一种标识资源版本的方式，它允许客户端缓存服务器资源的版本信息。当客户端发起一个新的 GET 请求时，它可以带上之前获取的 ETag 信息，服务器可以根据这个信息决定是否需要发送完整的资源数据。

对于 POST 请求，我们可以采用类似的思路来避免重复提交。这里我们主要关注 POST 请求的幂等性，即多次相同的请求具有相同的效果。下面是如何使用 ETag 的步骤：

1. 生成 ETag：

   • 当客户端第一次发起 POST 请求时，服务器生成一个唯一的 ETag 并与响应一起返回给客户端。

2. 存储 ETag：

   • 客户端接收到响应后，存储这个 ETag（通常可以存储在本地存储中如 localStorage 或 sessionStorage）。

3. 重试 POST 请求：

   • 如果客户端尝试重新提交 POST 请求，它会在请求头中包含 If-Match 字段，并设置值为之前存储的 ETag。

4. 服务器验证 ETag：

   • 服务器接收到请求后，检查 If-Match 头部中的 ETag 是否与服务器上对应资源的 ETag 匹配。
     • 如果匹配，说明这是一个合法的重试请求，服务器继续处理请求。
     • 如果不匹配，说明这是一个新的请求或者是非法的重试请求，服务器可以选择拒绝处理或返回错误。

If-None-Match

If-None-Match 是一个条件 GET 请求头，它告诉服务器“如果资源的 ETag 不是我提供的这个 ETag，请返回资源”。通常用于 GET 请求，但在某些情况下也可以用于 POST 请求。

1. 客户端发起带有 If-None-Match 的请求：

   • 客户端在 POST 请求中包含 If-None-Match 头部，其值为之前存储的 ETag。

2. 服务器验证：

   • 服务器检查请求中的 If-None-Match 头部与资源当前的 ETag 是否匹配。
     • 如果匹配，说明资源未被修改，服务器可以安全地处理请求。
     • 如果不匹配，服务器可以选择返回一个 412 Precondition Failed 错误，或者根据业务需求处理请求。

状态机

根据业务状态判断能否执行操作，比如只能从“未下单”状态进行下单操作。

业务逻辑校验

在业务逻辑层增加校验机制，比如检查是否有重复的订单创建请求。

java写一个消费者生产者模式，维护一个队列，2个生产者，1个消费者，队列大于10生产者阻塞，为0消费者阻塞，不使用BlockingQueue

在Java中，我们可以通过实现wait()和notify()方法来手动实现消费者-生产者模式，而不使用BlockingQueue。

查看代码

public class ProducerConsumer {
    private final Object lock = new Object();
    private final Object[] buffer;
    private int in = 0;
    private int out = 0;
    private int count = 0;
    public ProducerConsumer(int size) {
        buffer = new Object[size];
    }
    public void produce(Object item) throws InterruptedException {
        synchronized (lock) {
            // 如果队列已满，生产者等待
            while (count == buffer.length) {
                lock.wait();
            }
            // 生产新元素
            buffer[in] = item;
            in = (in + 1) % buffer.length;
            count++;
            // 通知消费者
            lock.notifyAll();
        }
    }
    public Object consume() throws InterruptedException {
        synchronized (lock) {
            // 如果队列已空，消费者等待
            while (count == 0) {
                lock.wait();
            }
            // 消费元素
            Object item = buffer[out];
            out = (out + 1) % buffer.length;
            count--;
            // 通知生产者
            lock.notifyAll();
            return item;
        }
    }
    public static void main(String[] args) {
        ProducerConsumer pc = new ProducerConsumer(10);
        // 创建生产者和消费者线程
        Producer p1 = new Producer(pc);
        Producer p2 = new Producer(pc);
        Consumer c1 = new Consumer(pc);
        // 启动线程
        p1.start();
        p2.start();
        c1.start();
    }
}
class Producer extends Thread {
    private ProducerConsumer pc;
    public Producer(ProducerConsumer pc) {
        this.pc = pc;
    }
    @Override
    public void run() {
        try {
            for (int i = 0; i < 20; i++) {
                pc.produce(i);
                System.out.println("Produced: " + i);
                Thread.sleep((long) (Math.random() * 1000));
            }
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}
class Consumer extends Thread {
    private ProducerConsumer pc;
    public Consumer(ProducerConsumer pc) {
        this.pc = pc;
    }
    @Override
    public void run() {
        try {
            for (int i = 0; i < 20; i++) {
                Object item = pc.consume();
                System.out.println("Consumed: " + item);
                Thread.sleep((long) (Math.random() * 1000));
            }
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

在这个实现中，我们使用了一个互斥锁lock和一个整数count来跟踪队列中的元素数量。produce方法用于生产元素，而consume方法用于消费元素。如果队列已满，生产者会等待；如果队列已空，消费者会等待。当生产者或消费者完成操作后，它会通知其他正在等待的生产者或消费者。

java8新特性

Java 8 是 Java 语言的一个重要版本，它引入了许多新特性，极大地增强了 Java 语言的功能性和灵活性。以下是 Java 8 中的一些关键新特性：

1. Lambda 表达式

Lambda 表达式是一种匿名函数，它允许你以一种简洁的方式定义函数。Lambda 表达式可以作为方法参数传递，也可以作为返回值从方法中返回。这使得 Java 支持函数式编程风格。

示例:

List<String> list = Arrays.asList("a", "b", "c");
list.sort((s1, s2) -> s1.compareTo(s2));

2. 函数式接口

函数式接口是指仅有一个抽象方法的接口，这样的接口可以用来定义函数的行为。Java 8 标准库中引入了多个函数式接口，如 Function, Predicate, Consumer 和 Supplier。

示例:

Predicate<Integer> isEven = n -> n % 2 == 0;
System.out.println(isEven.test(2)); // 输出 true

3. Stream API

Stream API 提供了一种高效并且灵活的方式来处理数据集合。它支持并行操作、过滤、映射、聚合等操作，并且可以很容易地在并行流和顺序流之间切换。

示例:

List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5);
int sum = numbers.stream().filter(n -> n > 3).mapToInt(Integer::intValue).sum();
System.out.println(sum); // 输出 12

4. 默认方法和静态方法

Java 8 允许在接口中定义默认方法（使用 default 关键字）和静态方法。这使得可以在不破坏向后兼容性的前提下为现有接口添加新功能。

示例:

interface MyInterface {
    default void myMethod() {
        System.out.println("This is a default method.");
    }

    static void staticMethod() {
        System.out.println("This is a static method.");
    }
}

5. 新的时间日期 API

Java 8 引入了一个新的时间日期 API (java.time 包)，包括 LocalDate, LocalTime, LocalDateTime, ZonedDateTime 等类，用于更好地处理日期和时间。

示例:

LocalDate today = LocalDate.now();
System.out.println(today); // 输出今天的日期

6. Optional 类

Optional 类用于避免空指针异常，它可以包含一个值或者为空。使用 Optional 可以让代码更清晰、更安全。

示例:

Optional<String> optional = Optional.ofNullable(null);
String value = optional.orElse("Default Value");
System.out.println(value); // 输出 "Default Value"

7. 并行数组操作

Java 8 支持对数组进行并行处理，主要通过 Arrays.parallelSort() 等方法，可以在多核处理器上提高数组排序的速度。

示例:

int[] array = {3, 2, 1};
Arrays.parallelSort(array);

8. Nashorn JavaScript 引擎

Java 8 引入了 Nashorn JavaScript 引擎，允许在 JVM 上直接运行 JavaScript 代码。

示例:

ScriptEngine engine = new ScriptEngineManager().getEngineByName("nashorn");
String script = "print('Hello Nashorn!');";
engine.eval(script);

9. 类依赖分析器 jdeps

Java 8 提供了 jdeps 工具，用于显示 Java 类之间的依赖关系。

10. 移除 PermGen 空间

Java 8 中，永久代 (PermGen space) 被元空间 (Metaspace) 替代，提高了内存管理的效率。

Java创建子进程

在Java中，可以使用ProcessBuilder类来创建子进程。

以下是一个简单的示例：

查看代码

import java.io.IOException;

public class CreateSubprocess {
    public static void main(String[] args) {
        try {
            // 创建一个ProcessBuilder对象，传入要执行的命令
            ProcessBuilder processBuilder = new ProcessBuilder("notepad.exe");

            // 启动子进程
            Process process = processBuilder.start();

            // 等待子进程结束
            process.waitFor();
        } catch (IOException | InterruptedException e) {
            e.printStackTrace();
        }
    }
}

在这个示例中，我们创建了一个ProcessBuilder对象，传入了要执行的命令（在这里是打开记事本）。然后调用start()方法启动子进程，最后使用waitFor()方法等待子进程结束。

Spring和SpringBoot的区别

Spring 和 Spring Boot 都是基于 Java 的框架，用于构建企业级应用。但它们之间有几个关键的不同点：

1. 配置复杂度：

   • Spring：需要手动定义 Bean 的配置，通常使用 XML 或者 Java 配置类来管理依赖关系。
   • Spring Boot：简化了配置过程，通过约定优于配置的原则（Convention over Configuration），自动配置了许多常见的功能，减少了样板代码。

2. 起步依赖：

   • Spring Boot：引入了“starter”依赖，使得添加功能变得简单。例如，只需要加入 spring-boot-starter-web 就可以快速启动一个 Web 应用。
   • Spring：你需要明确地指定所需的依赖项，并且配置相对复杂一些。

3. 自动配置：

   • Spring Boot：提供了自动配置机制，它会根据你添加的依赖自动设置 Spring 应用的配置，减少手动配置的工作量。
   • Spring：没有这样的自动配置特性，所有配置都需要开发者自己设定。

4. 内嵌式服务器：

   • Spring Boot：支持内嵌式的 Servlet 容器，如 Tomcat, Jetty 或 Undertow，使得开发者不需要单独安装应用服务器即可运行 Web 应用。
   • Spring：通常需要一个外部的 Servlet 容器来运行 Web 应用。

5. 执行程序：

   • Spring Boot：可以被打包成一个可执行的 JAR 文件，包含运行应用所需的所有依赖和插件。
   • Spring：通常被打包成 WAR 文件，部署在 Servlet 容器中。

6. 运维友好：

   • Spring Boot：提供了一个名为 Actuator 的模块，用于监控和管理应用，提供了健康检查、指标收集等功能。
   • Spring：不包含这些开箱即用的功能，需要额外配置。

10G文件2G内存如何去重文件重复的行

对于10GB大文件在仅有2GB内存限制下去重文件中重复的行，可以采用以下方法：

1. 文件分割法：

   • 将大文件分割成若干小文件，确保每个小文件能够在2GB内存内进行处理。逐个读取这些小文件，使用哈希表或数据结构进行去重操作。这种方法需要对文件进行多次读写，但避免了一次性加载大文件造成的内存不足问题。

2. 外部排序法：

   • 利用外部排序算法（如外部归并排序），将文件分成若干可管理的部分，分别进行排序和去重，然后再合并结果。这涉及到磁盘上的临时文件操作，但是能够有效地处理大文件。

3. Bitmap位图法：

   • 适用性：适合处理大量整数或其他可数数据。
   • 通过将每个整数映射到一个bit位置，可以使用较少的内存来标记出现过的数字。最后通过遍历Bitmap找出那些被标记为未出现的数字，即为去重后的结果。

4. Bloom Filter算法：

   • 适用性：适用于允许一定错误率的情况。
   • Bloom Filter是一种空间效率极高的概率型数据结构，适用于大量数据的去重。通过多个哈希函数映射数据到固定大小的空间，然后检查某个元素是否可能存在于此空间中。此方法不保证100%正确率，但空间效率极高。

5. 哈希分割法：

   • 适用性：处理超大数据量时，尤其是去重非唯一值的场景。
   • 通过哈希函数将数据分割成小块，分块处理后再合并结果。这种方法需要设计良好的哈希函数以避免碰撞，并且可能需要结合其他技术如Bloom Filter来提高去重精度。

计网

http的概念中，加签和加密的区别，适用场景

加签（Signing）

1. 目的：

   确保数据的完整性：加签是为了验证数据在传输过程中没有被篡改。

   身份验证：确保数据是由特定的发送者发送的。

2. 过程：

   发送方使用私钥对数据的哈希值（或其他形式的摘要）进行数字签名。

   签名附加在数据上一起发送。

3. 验证：

   接收方使用发送方的公钥来验证签名。

   验证成功意味着数据在传输过程中未被篡改，并且确实是由持有私钥的发送方发送的。

4. 特性：

   不涉及数据的保密性，任何人都可以读取数据内容。

   签名本身不隐藏数据内容。

5. 适用场景：

   身份验证：确保信息是由特定实体发送的，例如，API调用时服务端验证客户端的身份。

   数据完整性：验证数据在传输过程中未被篡改，如配置文件、日志文件的传输。

   审计和日志记录：确保日志记录不可被篡改，用于后续的审计和分析。

加密（Encryption）

1. 目的：

   保护数据的保密性：确保只有授权的接收者才能读取数据内容。

2. 过程：

   发送方使用加密算法和密钥将原始数据转换成密文。

   密文发送给接收方。

3. 解密：

   接收方使用相应的密钥和算法将密文解密成原始数据。

4. 特性：

   防止未授权的第三方读取数据内容。

5. 适用场景：

   数据隐私：保护敏感信息，如用户密码、信用卡信息等，在传输过程中不被第三方读取。

   传输安全：在不受信任的网络环境中，如公网，确保数据传输的安全性。

   合规要求：满足法律法规对数据传输加密的要求，如GDPR。

通常情况下，加密也隐含了数据完整性的保护，因为未授权的修改会导致解密失败。

对比总结

• 数据可见性：

  加签：数据对所有人可见。

  加密：数据对未授权的第三方不可见。

• 密钥使用：

  加签：使用私钥创建签名，公钥验证签名。

  加密：对称加密使用同一密钥进行加密和解密；非对称加密使用公钥加密，私钥解密。

• 用途：

  加签：主要用于验证身份和数据完整性。

  加密：主要用于保护数据隐私。

如何防止中间人攻击

• 使用HTTPS：

  始终确保访问网站时使用HTTPS协议，这可以有效防止数据在传输过程中被窃听和篡改。

• 验证证书：

  当浏览器显示证书无效或不合适的警告时，不要忽视。这通常意味着当前的SSL/TLS连接可能不安全，存在中间人攻击的风险。

• 使用VPN：

  虚拟私人网络可以加密整个网络连接，使得中间人难以拦截和篡改数据。

• 避免公共Wi-Fi：

  尽量避免使用不安全的公共Wi-Fi网络，特别是那些不需要密码或加密的开放网络。如果需要在公共场所上网，可以考虑使用自己的移动热点。

• 多因素身份验证：

  对于敏感操作和重要账户，应启用多因素认证，即便攻击者获取到了密码，也因缺乏第二重验证而无法成功登录。