小菜鸟

ShardingSphere-JDBC水平分库分表

ShardingSphere-JDBC水平分库分表非常简单，只需要添加ShardingSphere-JDBC依赖并进行配置即可

1
2
3
4
5
6

<!-- sharding-jdbc 分库分表 -->
<dependency>
    <groupId>org.apache.shardingsphere</groupId>
    <artifactId>sharding-jdbc-spring-boot-starter</artifactId>
    <version>4.1.0</version>
</dependency>

Hystrix 隔离策略：线程隔离与信号量隔离的深度解析

在分布式系统中，服务间依赖可能因网络延迟、资源耗尽等原因出现故障。Hystrix 通过隔离策略限制故障影响范围，防止单个依赖拖垮整个系统。其核心隔离策略有两种：线程隔离（THREAD） 和信号量隔离（SEMAPHORE），适用于不同场景，各有优劣。

隔离策略的核心目标

隔离的本质是限制依赖服务对系统资源（线程、CPU 等）的占用，避免 “一个依赖故障导致全局崩溃”。具体目标包括：

1. 防止依赖服务的高延迟或故障占用过多线程资源；
2. 控制依赖服务的并发量，避免超出其承载能力；
3. 当依赖故障时，快速失败并触发降级，减少对调用方的影响。

线程隔离（THREAD）：彻底的资源隔离

线程隔离是 Hystrix 的默认策略，通过为每个依赖服务分配独立线程池实现隔离。调用依赖服务的逻辑在独立线程中执行，与调用方线程（如 Tomcat 的工作线程）完全分离。

实现原理

• 独立线程池：每个依赖服务（或分组）对应一个线程池，线程池参数（核心线程数、队列大小等）可单独配置；
• 调用流程：调用方线程将请求提交到线程池后立即返回，由线程池中的线程执行依赖调用；
• 资源隔离：线程池的线程数和队列长度限制了对该依赖的最大并发量，避免占用调用方的主线程资源。

Maven 环境配置：多环境管理与灵活激活策略

在实际开发中，项目通常需要在本地、开发、测试、生产等多环境中部署，而不同环境的配置（如数据库地址、端口、依赖版本）往往存在差异。Maven 提供了 profile 机制来管理多环境配置，支持灵活的激活方式，确保在不同环境下的构建一致性。本文将详细介绍 Maven 环境配置的实现与最佳实践。

什么是 Maven Profile？

profile 是 Maven 中用于区分环境配置的机制，可在不同环境下启用不同的属性、依赖、插件或构建规则。每个 profile 通过唯一 id 标识，可包含以下内容：

• 自定义属性（如 profileActive=dev）。
• 依赖管理（如不同环境引入不同版本的 Jar 包）。
• 插件配置（如生产环境跳过测试，开发环境启用调试）。
• 仓库配置（如开发环境使用私服，生产环境使用中央仓库）。

Profile 配置方式

Maven 支持在两个位置配置 profile：项目的 pom.xml 和 全局的 settings.xml，两者适用场景不同。

在 pom.xml 中配置（项目级）

适合项目专属的环境配置（如项目特有的数据库地址、端口），配置直接位于项目 pom.xml 的 <profiles> 标签中。

示例：区分本地、开发、测试、生产环境：

ShardingSphere简介

Apache ShardingSphere 是一套开源的分布式数据库解决方案组成的生态圈，它由 JDBC、Proxy 和 Sidecar（规划中）这 3 款既能够独立部署，又支持混合部署配合使用的产品组成。 它们均提供标准化的数据水平扩展、分布式事务和分布式治理等功能，可适用于如 Java 同构、异构语言、云原生等各种多样化的应用场景

属于客户端

连接、增量和可插拔是 Apache ShardingSphere 的核心概念。

• 连接：通过对数据库协议、SQL 方言以及数据库存储的灵活适配，快速的连接应用与多模式的异构数据库
• 增量：获取数据库的访问流量，并提供流量重定向（数据分片、读写分离、影子库）、流量变形（数据加密、数据脱敏）、流量鉴权（安全、审计、权限）、流量治理（熔断、限流）以及流量分析（服务质量分析、可观察性）等透明化增量功能
• 可插拔：项目采用微内核 + 3 层可插拔模型，使内核、功能组件以及生态对接完全能够灵活的方式进行插拔式扩展，开发者能够像使用积木一样定制属于自己的独特系统

分库分表

分库分表是为了解决单库单表数据量太大，导致的数据库压力过大

分库分表有两种方式，分为垂直拆分和水平拆分

垂直拆分

垂直分表和垂直分库

• 垂直分表 把一张大表中的字段拆分为两张表
• 垂直分库 由于垂直分表之后，两个表还是存储在同一个数据库中，而如果数据库中表过多，数据库的压力过大，可以按照业务来对数据库进行拆分