HespethornのBlog

2356. 每位教师所教授的科目种类的数量表: Teacher 123456789+-------------+------+| Column Name | Type |+-------------+------+| teacher_id | int || subject_id | int || dept_id | int |+-------------+------+在 SQL 中，(subject_id, dept_id) 是该表的主键。该表中的每一行都表示带有 teacher_id 的教师在系 dept_id 中教授科目 subject_id。 查询每位老师在大学里教授的科目种类的数量。 以 任意顺序 返回结果表。 查询结果格式示例如下。 示例 1: 1234567891011121314151617181920212223242526272829输入: Teacher 表:+------------+------------+---------+| teacher_id | subject_id | dept_id...

1193. 每月交易 I表：Transactions 123456789101112+---------------+---------+| Column Name | Type |+---------------+---------+| id | int || country | varchar || state | enum || amount | int || trans_date | date |+---------------+---------+id 是这个表的主键。该表包含有关传入事务的信息。state 列类型为 ["approved", "declined"] 之一。 编写一个 sql 查询来查找每个月和每个国家/地区的事务数及其总金额、已批准的事务数及其总金额。 以 任意顺序 返回结果表。 查询结果格式如下所示。 示例...

1934. 确认率表: Signups 12345678+----------------+----------+| Column Name | Type |+----------------+----------+| user_id | int || time_stamp | datetime |+----------------+----------+User_id是该表的主键。每一行都包含ID为user_id的用户的注册时间信息。 表: Confirmations 1234567891011+----------------+----------+| Column Name | Type |+----------------+----------+| user_id | int || time_stamp | datetime || action | ENUM |+----------------+----------+(user_id,...

445. Add Two Numbers IIYou are given two non-empty linked lists representing two non-negative integers. The most significant digit comes first and each of their nodes contains a single digit. Add the two numbers and return the sum as a linked list. You may assume the two numbers do not contain any leading zero, except the number 0 itself. 1234567891011121314151617181920212223242526272829303132333435363738394041424344/** * Definition for singly-linked list. * struct ListNode { * int...

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146#include <sys/socket.h>#include <sys/types.h>#include <netdb.h>#include <cstring>#include <unistd.h>#include <cerrno>#include...

一、网络地址解析的必要性在网络通信中，应用程序通常需要通过域名（如www.example.com）而非直接使用 IP 地址（如93.184.216.34）来定位目标主机，同时需要通过服务名（如http）而非直接使用端口号（如80）来指定通信端口。这种抽象带来了以下核心需求： 用户友好性：人类更容易记忆域名而非数字 IP 协议兼容性：需同时支持 IPv4 与 IPv6，避免硬编码地址类型 服务灵活性：服务端口可能动态分配，通过服务名解析更可靠 网络拓扑适应：同一域名可能对应多个 IP（负载均衡场景），需支持多地址选择 传统地址解析方法（如gethostbyname、getservbyname）存在明显局限性：仅支持 IPv4、无法统一处理主机名与服务名、线程安全性差。getaddrinfo作为 POSIX 标准接口，完美解决了这些问题，是现代 C++ 网络编程的首选地址解析方案。 二、getaddrinfo 函数getaddrinfo是一个统一的地址解析接口，可同时处理主机名→IP 地址、服务名→端口号的解析，并返回可直接用于socket调用的地址结构。 2.1...

导言在 AI 工具如 Claude、ChatGPT 日益渗透到软件开发全流程的当下，Playtechnique 的《AI Doesn't Lighten the Burden of Mastery》像一剂清醒剂，戳破了 “AI 能帮我们跳过学习、直接掌握技术” 的幻象。文章没有否定 AI 的价值，却直指一个更本质的问题：AI 能生成 “形似” 的优质代码，却无法替我们完成 “理解” 与 “思考” 的核心工作；它能减轻机械性的体力负担，却永远无法替代 “精通” 所需的认知投入。这篇短文让我对 “AI 时代如何做技术” 有了更深刻的反思。 在 C++ 开发领域，AI 工具同样展现出强大的代码生成能力 —— 从类定义、模板函数到 STL 容器用法，甚至多线程同步逻辑，AI 都能快速输出 “形似规范” 的代码。但结合 playtechnique 的观点再看 C++ 开发场景，会发现 “虚假精通” 的陷阱更隐蔽、危害也更大：C++ 的内存管理、指针操作、模板元编程等底层特性，恰恰是 AI 最易出错却最难被察觉的地方。这篇感悟将聚焦 C++ 开发，聊聊如何在借助 AI...

一、assert 宏的基本语法与工作机制断言是 C++ 标准库提供的调试工具，核心通过头文件（兼容 C 的<assert.h>）中的assert宏实现，其本质是条件检查宏，仅在调试阶段生效。 1.1 核心语法assert宏接收一个布尔表达式作为参数，语法如下： 12345678910111213#include <cassert> // 必须包含的头文件int main() { int* ptr = new int(10); // 检查指针是否非空（调试阶段生效） assert(ptr != nullptr); delete ptr; ptr = nullptr; // 此时断言会失败（指针已置空） assert(ptr != nullptr); return 0;} 1.2 工作机制与 NDEBUG 宏assert的行为完全由 **NDEBUG宏 **（"No Debug"）控制，这是 C++...

一、定义热 Key 是 Redis 高并发场景中，访问频率显著高于其他键的特殊键，其核心问题是 “单键请求过度集中于某一 Redis 节点”，导致该节点 CPU、内存资源占用飙升，进而引发节点响应延迟、命令阻塞，甚至拖累整个集群稳定性。 1.1 核心判定特征 访问频率：单键 QPS（每秒请求数）占集群总 QPS 的 10% 以上，或单键每秒访问次数持续超过 1000 次（具体阈值可根据集群规模调整，小集群可适当降低）； 节点资源占用：热 Key 所在节点的 CPU 使用率（系统 CPU + 用户 CPU）持续超过 80%（Redis 为单线程模型，CPU 满负荷会阻塞所有命令执行），或该节点内存占用远超集群内其他节点； 业务影响范围：热 Key 关联核心功能，若其所在节点故障，会导致大范围业务不可用，而非局部功能异常。 二、识别方法识别的核心目标是 “精准定位热 Key 及所在节点”，常用方法按 “轻量临时→专业长期” 分为两类： 轻量临时识别（依赖 Redis 原生命令）步骤 1：获取集群性能基线 执行redis-cli info...

一、引言在Redis的实际应用中，大Key问题是影响性能和稳定性的重要因素之一。从系统资源消耗维度分析，此类问题主要体现在三个层面：其一，内存管理层面，单 Key 占据过量内存空间，致使内存碎片化程度加剧，频繁触发内存淘汰机制，降低存储效率；其二，网络传输层面，大 Key 的读写操作产生大规模数据包，极易造成网络带宽饱和，例如单次读取 100MB 大 Key 会完全占用对应带宽资源；其三，CPU 资源层面，大 Key 的序列化与反序列化过程，以及复杂数据结构的遍历操作（如大列表遍历），均会消耗大量 CPU 资源，进而影响其他指令的执行效率。 二、大Key定义与危害分析2.1 定义对于String类型，通常认为超过10KB的键值对就属于大Key。在我们的测试环境中，user_session_1002键的大小为325,001字节，明显属于大Key范畴。 2.2...

59. Spiral Matrix IIGiven a positive integer n, generate an n x n matrix filled with elements from 1 to n2 in spiral order. Example 1: 12Input: n = 3Output: [[1,2,3],[8,9,4],[7,6,5]] Example 2: 12Input: n = 1Output: [[1]] Constraints: 1 <= n <= 20 题目大意给定一个正整数 n，生成一个 n×n 的矩阵，其中元素从 1 到 n² 按螺旋顺序填充。 解题思路 创建一个 n×n 的空矩阵 定义四个边界：上、下、左、右 按顺时针方向（右→下→左→上）填充数字 每填充完一行或一列就调整相应的边界 重复步骤 3-4 直到所有数字都被填充 123456789101112131415161718192021222324252627282930313233343536373839class Solution...

48. Rotate ImageYou are given an n x n 2D matrix representing an image, rotate the image by 90 degrees (clockwise). You have to rotate the image in-place, which means you have to modify the input 2D matrix directly. DO NOT allocate another 2D matrix and do the rotation. Example 1: 12Input: matrix = [[1,2,3],[4,5,6],[7,8,9]]Output: [[7,4,1],[8,5,2],[9,6,3]] Example 2: 12Input: matrix = [[5,1,9,11],[2,4,8,10],[13,3,6,7],[15,14,12,16]]Output:...

54. 螺旋矩阵给你一个 m 行 n 列的矩阵 matrix ，请按照 顺时针螺旋顺序 ，返回矩阵中的所有元素。 示例 1： 12输入：matrix = [[1,2,3],[4,5,6],[7,8,9]]输出：[1,2,3,6,9,8,7,4,5] 示例 2： 12输入：matrix = [[1,2,3,4],[5,6,7,8],[9,10,11,12]]输出：[1,2,3,4,8,12,11,10,9,5,6,7] 提示： m == matrix.length n == matrix[i].length 1 <= m, n <= 10 -100 <= matrix[i][j] <= 100 题目大意给定一个 m 行 n...

一、为什么需要 Trie 树？—— 先搞懂核心价值在开始写代码前，我们先明确 Trie 树的 “不可替代性”： 数据结构 插入 / 查询复杂度 前缀匹配能力 内存效率（重复前缀） 适用场景 哈希表（unordered_map） 平均 O (1) 不支持 低（存完整字符串） 单键精准查询（如缓存） 红黑树（map） O(log n) 支持（遍历） 低 有序键值对查询 Trie 树 O (k)（k 为字符串长度） 原生支持 高（前缀共享） 前缀相关操作（自动补全） 简单说：如果你的需求涉及 “前缀”（如输入 “app” 要提示 “apple”“application”），Trie 树是最优解之一。 本文实现的 Trie 树将包含以下核心功能： 单词插入（自动统计重复单词的出现次数） 词频查询（返回单词出现次数，0 表示不存在） 前缀匹配（返回所有以指定前缀开头的单词，支持字典序 / 词频排序） 单词删除（智能回收无用节点，不破坏共享前缀） 整体清空（安全释放所有内存，避免泄漏） 二、代码结构设计 ——...

一、Trie 树定位Trie 树（前缀树 / 字典树）是专为字符串设计的树形结构，核心价值是通过 “前缀共享” 减少内存冗余，同时实现 O (k)（k 为字符串长度）的插入 / 查询效率，尤其适合 “前缀相关场景”（如自动补全、拼写检查）。 二、核心结构：节点设计与前缀共享1. 节点结构体Trie 的最小单元是节点，需存储子节点映射和单词结尾标记，C++ 中用结构体实现最简洁： 123456789struct TrieNode { // 子节点：两种实现方案（按需选择） // 方案1：数组（仅适用于固定小字符集，如小写字母，速度快） TrieNode* children[26] = {nullptr}; // 方案2：哈希表（字符集不确定时用，如含数字/符号，灵活） // unordered_map<char, TrieNode*> children; bool isEnd = false; //...

导言在 C 和 C++ 编程中，结构体（struct）是组织复杂数据的核心工具，而 typedef 则常用于简化类型名、提升代码可读性。实际开发中，我们常会见到两种结构体 + typedef 的定义方式：typedef struct Person{} Person; 与 typedef struct {} Person;。这两种写法看似相似，却因语言特性（C/C++ 差异）和结构体标签（tag）的存在与否，在使用场景、功能限制上有显著区别。 一、基础认知：结构体标签与 typedef 的作用在深入差异前，需先明确两个核心概念： 结构体标签（tag）：紧跟 struct 后的标识符（如 struct Person 中的 Person），是结构体的 “原生名称”，仅在 struct 关键字后生效。 typedef 别名：通过 typedef 为类型（包括结构体）定义的简化名称（如 Person），可直接作为类型名使用。 C 和 C++ 对 “结构体标签” 的处理规则不同，这是两种定义方式差异的根源 ——C 语言中，结构体必须通过 struct 标签 或...

一、RDB 概念解析Redis 数据库的 RDB（Redis Database）持久化机制，本质上是一种将内存数据以二进制快照形式存储至磁盘的技术方案。该机制通过创建一个名为dump.rdb的文件（默认文件名），将 Redis 内存中的全部数据进行序列化保存。例如，当 Redis 实例包含 10,000 条数据记录时，RDB 机制会将这些数据完整保存至快照文件，在系统重启时通过加载该文件实现数据恢复。 二、核心技术原理RDB 持久化的实现过程主要涉及以下两个关键步骤： 子进程创建（fork 机制）：在触发 RDB 快照生成时，Redis 利用操作系统的fork机制创建一个子进程。此时，父进程继续处理客户端的读写请求，确保业务连续性；而子进程则负责将内存数据写入 RDB 文件，这种分离设计有效避免了对业务处理的阻塞。 写时复制（Copy-On-Write，COW）：在子进程执行数据写入操作期间，若父进程需要修改内存中的数据，系统会采用写时复制策略。具体而言，父进程将待修改的数据复制一份，在新副本上进行修改操作，而子进程继续读取原始数据写入 RDB 文件。通过这种方式，能够确保...

导言在分布式计算架构中，Redis 作为内存数据库的典型代表，其数据持久化机制构成了系统容错性与数据一致性保障的核心技术支撑。在 Redis 提供的 RDB（Redis Database）快照持久化与 AOF（Append-Only File）日志追加持久化两种核心策略中，AOF 机制凭借其基于操作日志的增量式数据记录模式，在数据完整性保障方面展现出独特优势。 一、AOF 持久化机制的理论模型与实现架构AOF 持久化机制遵循 "Write-Ahead Logging"（预写日志）设计范式，通过顺序追加的方式记录数据库写操作，从而构建可回溯的历史操作序列。该机制在运行时经历命令缓存、磁盘同步、日志优化三个核心处理阶段，各阶段通过协同工作实现数据可靠性与系统性能的动态平衡。 1. 命令缓存层：基于 RESP 协议的操作记录在 Redis 执行写操作过程中，系统将 SET、HSET、LPUSH 等指令按照 RESP（Redis Serialization Protocol）协议标准进行序列化，并暂存于内存级 AOF 缓冲区。这种设计有效规避了频繁磁盘...

导言在分布式系统中，Redis 作为高性能分布式缓存，可有效减轻数据库压力、提升接口响应速度，但高并发场景下，缓存雪崩、缓存击穿、缓存穿透三类异常易引发系统稳定性问题。 一、缓存穿透 ——“不存在数据” 的持续穿透1. 核心定义缓存穿透是指查询的数据在缓存和数据库中均不存在（如查询不存在的 ID、非法参数），导致每次请求都穿透缓存直接查询数据库，且由于缓存无法存储 “不存在的数据”，后续相同请求会持续穿透，造成数据库无效查询压力激增的现象。 核心特征：区别于前两类异常，其关键在于 “查询无结果数据”，缓存无法拦截，请求持续打向 DB。 2. 触发条件缓存穿透的发生源于两类场景： 非法请求攻击：恶意用户构造非法参数（如负数 ID、超长字符串）发起大量查询，这类数据在缓存和 DB 中均不存在； 业务空数据查询：正常业务场景中，部分查询天然无结果（如查询已删除的用户、未创建的订单），且未做缓存处理。 3. 解决方案对比 解决方案 实现逻辑 优点 缺点 适用场景 空值缓存 查询 DB 无结果时，将 “空值”（如空字符串、默认对象）存入...

1757. 可回收且低脂的产品表：Products 12345678910+-------------+---------+| Column Name | Type |+-------------+---------+| product_id | int || low_fats | enum || recyclable | enum |+-------------+---------+product_id 是该表的主键（具有唯一值的列）。low_fats 是枚举类型，取值为以下两种 ('Y', 'N')，其中 'Y' 表示该产品是低脂产品，'N' 表示不是低脂产品。recyclable 是枚举类型，取值为以下两种 ('Y', 'N')，其中 'Y' 表示该产品可回收，而 'N' 表示不可回收。 编写解决方案找出既是低脂又是可回收的产品编号。 返回结果 无顺序要求...