小菜鸟

java菜鸟号正在起航

0%

发表于 更新于 分类于 阅读次数： Valine：
本文字数： 8.9k 阅读时长 ≈ 8 分钟

Spring 核心注解全解析：从配置到实战

Spring 框架的注解体系是简化开发、实现 “约定优于配置” 的核心。从早期的 XML 配置到现在的全注解开发，注解极大地提升了开发效率。本文将系统整理 Spring 常用注解，按功能分类详解其作用、用法及适用场景，帮助开发者快速掌握注解的使用技巧。

配置类与 Bean 定义注解

这类注解用于替代 XML 配置文件，实现 Bean 的定义与配置类的声明，是注解开发的基础。

1. @Configuration

  • 作用：标记类为 Spring 配置类，相当于 XML 配置中的 <beans> 标签。

  • 特点：配置类中可通过 @Bean 定义 Bean，容器启动时会扫描并加载这些配置。

  • 示例：

    1
    2
    3
    4
    5
    6
    7
    8
    @Configuration // 声明为配置类
    public class AppConfig {
        // 定义 Bean（方法名默认作为 Bean 的 id）
        @Bean
        public UserService userService() {
            return new UserService();
        }
    }

2. @Bean

  • 作用：在配置类中定义 Bean，相当于 XML 中的 <bean> 标签。

  • 核心属性：

    • name/value：指定 Bean 的 id（默认是方法名）；
    • initMethod：Bean 初始化方法（相当于 XML 的 init-method）；
    • destroyMethod：Bean 销毁方法（相当于 XML 的 destroy-method）。

  • 示例：

阅读全文 »

发表于 更新于 分类于 阅读次数： Valine：
本文字数： 2.2k 阅读时长 ≈ 2 分钟

Redis 缓存常见问题及解决方案

Redis 作为高性能缓存中间件，在实际应用中可能面临缓存击穿、缓存穿透、缓存雪崩等问题，同时需保证缓存与数据库的数据一致性。本文详细解析这些问题的成因及针对性解决方案。

缓存击穿

问题定义

热点 key 过期瞬间，大量并发请求直接穿透缓存，直击数据库，导致数据库压力骤增（甚至宕机）。
例：某热门商品的缓存 key 过期，恰好此时有 1000 个并发请求查询该商品，全部打到数据库。

解决方案

1. 互斥锁（推荐）

原理：当缓存失效时，通过锁机制保证同一时间只有一个请求能查询数据库，其他请求等待重试，避免并发冲击。
步骤：

  • 缓存未命中时，先尝试通过 SETNX 获取锁（如 SET lock:key 1 EX 5 NX）。
  • 成功获取锁：查询数据库，写入缓存，释放锁（DEL lock:key）。
  • 未获取锁：等待 50ms 后重试（循环几次后返回默认值）。

优点：简单有效，避免数据库过载。
缺点：可能增加请求延迟（等待锁），需合理设置锁超时时间（避免死锁）。

2. 热点 key 永不过期 + 定时更新

原理：不对热点 key 设置过期时间，而是通过定时任务（如 10 分钟一次）从数据库主动更新缓存，确保缓存始终有效。
适用场景：热点数据更新频率低（如商品基本信息）、可接受轻微延迟。
优点：彻底避免过期问题，性能稳定。
缺点：需维护定时任务，缓存可能存在短暂不一致（更新间隔内）。

缓存穿透

问题定义

阅读全文 »

发表于 更新于 分类于 阅读次数： Valine：
本文字数： 3.2k 阅读时长 ≈ 3 分钟

Redis 配置详解（基于 6.0.10 版本）

Redis 的配置文件（redis.conf）是控制 Redis 行为的核心，包含了从基础运行参数到高级特性（如持久化、集群、安全）的所有设置。本文基于 6.0.10 版本，按模块解析关键配置项的作用、默认值及实际应用建议。

INCLUDES 模块：配置文件引入

1
2
# include /path/to/local.conf
# include /path/to/other.conf
  • 作用：通过 include 指令引入其他配置文件，便于拆分配置（如将环境特定配置与通用配置分离）。
  • 使用场景：多环境部署（开发 / 测试 / 生产）时，可共享基础配置，仅在环境专属文件中修改差异项。

GENERAL 模块：基础运行参数

核心配置

配置项 作用 默认值 建议设置
daemonize 是否以守护进程（后台）模式运行。 no 生产环境设为 yes
pidfile 进程 ID 文件路径（守护模式下必填）。 redis_6379.pid 按端口区分（如 redis_6380.pid）
port 监听端口。 6379 多实例需修改（如 6380、6381）
loglevel 日志级别（debug/verbose/notice/warning）。 notice 生产环境用 warning（减少日志量）
logfile 日志文件路径（空表示输出到控制台）。 "" 设为具体路径（如 ./logs/redis.log）
databases 数据库数量（通过 select <dbid> 切换）。 16 无需修改（默认足够）

NETWORK 模块：网络与连接设置

阅读全文 »

发表于 更新于 分类于 阅读次数： Valine：
本文字数： 3.9k 阅读时长 ≈ 4 分钟

Redis 集群详解（基于 6.0.10 版本）

Redis 集群（Redis Cluster）是 Redis 3.0 引入的分布式解决方案，旨在解决单机 Redis 的容量和性能瓶颈，支持水平扩展、自动分片和故障转移。本文基于 6.0.10 版本，详细解析集群的核心原理、搭建方法、命令操作及可用性保障。

集群核心原理：虚拟槽（Virtual Slot）分片

Redis 集群采用虚拟槽分片策略，将数据分散到多个节点，平衡负载并支持动态扩展。

虚拟槽的工作机制

  • 槽范围：集群将数据划分为 0~16383 共 16384 个虚拟槽（固定值，由 2^14 计算而来）。
  • 键与槽的映射：存储键值对时，Redis 通过以下步骤定位槽：
    1. 对键执行 CRC16 哈希算法，得到哈希值。
    2. 哈希值对 16384 取余，结果即为该键所属的槽（slot = CRC16(key) % 16384）。
  • 槽与节点的映射：集群中的每个主节点负责一部分槽（如节点 A 负责 0~5000，节点 B 负责 5001~10000 等），集群自动维护槽与节点的对应关系。

为什么选择虚拟槽？

对比传统分片策略，虚拟槽的优势显著：

分片策略 原理 缺点 虚拟槽的改进
取模（如 key%N） 键对节点数取模定位节点 节点增减时，大量键需重新映射（命中率骤降） 槽与节点解耦，节点增减仅需迁移部分槽
一致性哈希 键和节点映射到 2^32 哈希环 节点少时易分布不均，负载失衡 16384 个槽均匀分布，负载更均衡

集群架构与通信

节点类型与角色

阅读全文 »

发表于 更新于 分类于 阅读次数： Valine：
本文字数： 1.7k 阅读时长 ≈ 2 分钟

NoSQL 简介：非关系型数据库的崛起与分类

NoSQL（全称为 “Not Only SQL”，也常被解释为 “non-relational”）是一类非关系型数据库的统称，旨在解决大规模数据存储、高并发访问和灵活数据结构等传统关系型数据库难以应对的挑战。它并非要取代关系型数据库，而是作为补充，在特定场景中发挥优势。

NoSQL 的核心特点

与传统关系型数据库（如 MySQL、Oracle）相比，NoSQL 具有以下显著特征：

  • 无固定 schema（模式自由）：无需预先定义表结构，数据格式可动态调整，适合半结构化或非结构化数据（如日志、文档、社交关系）。
  • 分布式架构：天然支持水平扩展，可通过增加节点应对数据量和访问量的增长，适合大数据场景。
  • 高吞吐量：优化了读写性能，尤其擅长处理高并发的简单查询（如键值查询）。
  • 灵活的数据模型：根据业务场景提供多种数据结构（如键值对、文档、列族、图），而非单一的二维表。

NoSQL 的四大分类及代表产品

根据数据模型和应用场景，NoSQL 可分为四大类：

1. 键值存储数据库（Key-Value Store）

核心特点：
  • 以键值对（Key-Value）形式存储数据，Key 唯一，Value 为任意格式（字符串、二进制等）。
  • 读写性能极高，适合简单的查询场景。
代表产品：
  • Redis：支持字符串、哈希、列表等多种数据结构，提供持久化、过期策略和分布式锁，广泛用于缓存、会话存储。
  • Tokyo Cabinet/Tyrant：轻量级键值数据库，适合嵌入式场景。
  • Voldemort：分布式键值存储，强调高可用性和分区容错性。
应用场景：
  • 缓存系统（如热点数据缓存）。
  • 会话管理（存储用户登录状态）。
  • 计数器、排行榜等简单高频操作。

2. 列存储数据库（Column-Family Store）

阅读全文 »