土亢不坑1. 高并发进销存系统的典型困境
进销存系统作为企业核心业务支撑平台，其性能瓶颈往往最先暴露在数据库层面。当并发请求量突破每秒500次时，传统设计模式下的系统就会开始出现明显的响应延迟。我曾参与过某零售企业ERP改造项目，其原有系统在促销活动期间，订单提交响应时间从正常的200ms骤增至8秒以上，直接导致前端页面超时。
这种性能劣化通常呈现三个典型特征：首先是数据库连接池耗尽，监控显示活跃连接数长期维持在最大值；其次是慢查询日志中出现大量全表扫描记录；最致命的是锁等待时间占比超过30%，形成恶性循环。究其根源，在于传统进销存系统常采用"大单体"架构，所有业务逻辑集中处理，库存扣减、订单创建、财务记账等操作都在同一个事务中完成。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 领域驱动设计在数据模型中的实践
2.1 核心领域划分策略
采用DDD（领域驱动设计）方法重构数据模型时，我们首先需要识别核心子域。对于进销存系统，通常可以划分为：
- 库存核心域（包含SKU、仓库、库存流水等）
- 订单核心域（订单、订单项、支付凭证等）
- 采购核心域（供应商、采购单、到货单等）
- 财务核心域（应收应付、总账明细等）
每个领域对应独立的数据库schema，例如：
sql复制CREATE SCHEMA inventory_domain;
CREATE TABLE inventory_domain.sku (
sku_id BIGINT PRIMARY KEY,
warehouse_id INT NOT NULL,
current_stock INT CHECK (current_stock >=0),
version INT DEFAULT 0
);
CREATE SCHEMA order_domain;
CREATE TABLE order_domain.orders (
order_id VARCHAR(32) PRIMARY KEY,
user_id BIGINT NOT NULL,
total_amount DECIMAL(12,2)
);
2.2 聚合根设计要点
库存领域的SKU聚合根设计需要特别注意版本控制。我们采用乐观锁机制避免超卖：
java复制public class Sku {
private Long skuId;
private Integer stock;
private Integer version;
public boolean reduceStock(int quantity) {
if (this.stock < quantity) {
return false;
}
this.stock -= quantity;
this.version++;
return true;
}
}
对应的SQL更新语句必须包含版本校验：
sql复制UPDATE inventory_domain.sku
SET current_stock = current_stock - ?,
version = version + 1
WHERE sku_id = ? AND version = ?
3. 高并发下的解耦架构实现
3.1 命令查询职责分离（CQRS）
将读写操作分离到不同模型：
mermaid复制graph LR
Command-->|Event|WriteDB
WriteDB-->|CDC|ReadDB
Query-->ReadDB
实际实现中，我们使用Debezium捕获数据库变更事件：
yaml复制# debezium配置示例
connector.class: io.debezium.connector.mysql.MySqlConnector
database.hostname: mysql
database.port: 3306
database.user: debezium
database.password: dbz
database.server.id: 184054
database.server.name: inventory_server
database.include.list: inventory_domain
table.include.list: inventory_domain.sku
3.2 事件驱动架构设计
关键业务流程通过事件总线解耦：
- 订单服务创建订单后发布OrderCreated事件
- 库存服务消费事件并执行库存预留
- 支付服务接收库存预留成功事件后触发支付流程
使用Spring Cloud Stream的典型实现：
java复制@SpringBootApplication
@EnableBinding(OrderChannels.class)
public class OrderService {
public static void main(String[] args) {
SpringApplication.run(OrderService.class, args);
}
}
interface OrderChannels {
@Output
MessageChannel orderCreated();
}
@Service
class OrderCreator {
private final OrderChannels channels;
public void createOrder(Order order) {
// 持久化订单
orderRepository.save(order);
// 发布事件
channels.orderCreated().send(
MessageBuilder.withPayload(order).build()
);
}
}
4. 性能优化关键策略
4.1 数据库分片方案
按照仓库ID进行水平分片，每个分片单独部署：
code复制库存库_分片1（warehouse_1到warehouse_10）
库存库_分片2（warehouse_11到warehouse_20）
...
使用ShardingSphere配置分片规则：
yaml复制spring:
shardingsphere:
datasource:
names: ds0,ds1
sharding:
tables:
sku:
actual-data-nodes: ds$->{0..1}.sku_$->{0..15}
table-strategy:
inline:
sharding-column: warehouse_id
algorithm-expression: sku_$->{warehouse_id % 16}
database-strategy:
inline:
sharding-column: warehouse_id
algorithm-expression: ds$->{warehouse_id % 2}
4.2 缓存应用模式
采用多级缓存策略：
- 本地缓存（Caffeine）：存储热点SKU的库存信息，TTL 500ms
- 分布式缓存（Redis）：存储全量SKU基础信息，TTL 5分钟
- 数据库：作为唯一真实数据源
库存扣减的缓存处理流程：
java复制public boolean reduceStock(Long skuId, int quantity) {
// 1. 检查本地缓存
SkuCache localCache = caffeineCache.getIfPresent(skuId);
if (localCache != null && localCache.getStock() >= quantity) {
return true;
}
// 2. 检查Redis库存
Long remain = redisTemplate.opsForValue().decrement("stock:"+skuId, quantity);
if (remain == null || remain < 0) {
redisTemplate.opsForValue().increment("stock:"+skuId, quantity);
return false;
}
// 3. 异步更新数据库
mqTemplate.send("stock-update",
new StockUpdateMessage(skuId, quantity));
return true;
}
5. 容错与一致性保障
5.1 分布式事务方案
采用Saga模式保证最终一致性：
mermaid复制sequenceDiagram
participant O as OrderService
participant I as Inventory
participant P as Payment
O->>I: 预留库存
alt 成功
I->>O: 预留成功
O->>P: 发起支付
else 失败
I->>O: 预留失败
O->>O: 取消订单
end
对应的补偿事务实现：
java复制@Saga
public class OrderSaga {
@StartSaga
@SagaEventHandler(associationProperty = "orderId")
public void handle(OrderCreatedEvent event) {
// 发送库存预留命令
commandGateway.send(new ReserveStockCommand(
event.getOrderId(),
event.getItems()
));
}
@SagaEventHandler(associationProperty = "orderId")
public void handle(StockReservedEvent event) {
// 发起支付
commandGateway.send(new ProcessPaymentCommand(
event.getOrderId()
));
}
@SagaEventHandler(associationProperty = "orderId")
public void handle(StockReservationFailedEvent event) {
// 取消订单
commandGateway.send(new CancelOrderCommand(
event.getOrderId()
));
}
}
5.2 重试与幂等设计
所有服务接口必须实现幂等：
java复制@RestController
public class InventoryController {
@PostMapping("/stock/reserve")
public ResponseEntity<?> reserveStock(
@RequestBody ReserveRequest request,
@RequestHeader("Idempotency-Key") String idempotencyKey) {
// 检查幂等键
if (idempotencyStore.exists(idempotencyKey)) {
return ResponseEntity.ok(idempotencyStore.getResult(idempotencyKey));
}
// 处理业务逻辑
ReserveResult result = inventoryService.reserve(request);
// 保存结果
idempotencyStore.save(idempotencyKey, result);
return ResponseEntity.ok(result);
}
}
6. 监控与调优实践
6.1 关键指标监控体系
建立三级监控指标：
-
基础层：
- 数据库连接池使用率
- 慢查询占比
- 锁等待时间
-
中间层：
- 事件处理延迟
- 消息积压量
- 缓存命中率
-
业务层：
- 库存扣减成功率
- 订单创建TP99
- 支付超时率
使用Prometheus配置示例：
yaml复制- job_name: 'inventory_service'
metrics_path: '/actuator/prometheus'
scrape_interval: 5s
static_configs:
- targets: ['inventory-service:8080']
6.2 JVM调优参数
针对库存服务的JVM配置建议：
code复制-XX:+UseG1GC
-XX:MaxGCPauseMillis=200
-XX:InitiatingHeapOccupancyPercent=35
-XX:ParallelGCThreads=4
-XX:ConcGCThreads=2
-Xms4g
-Xmx4g
-XX:MaxMetaspaceSize=512m
7. 实战中的经验教训
在多个项目实践中，我们总结了以下关键经验：
-
库存预占超时设置应短于订单创建超时（建议2:1比例），避免用户长时间等待后看到订单创建失败。
-
事件格式必须包含：
- 事件版本号（用于兼容处理）
- 发生时间戳（UTC）
- 业务唯一ID
- 明确的类型标记
-
分布式追踪需要贯穿所有服务，建议采用OpenTelemetry标准：
java复制@Bean
public OpenTelemetry openTelemetry() {
return OpenTelemetrySdk.builder()
.setTracerProvider(
SdkTracerProvider.builder()
.addSpanProcessor(
BatchSpanProcessor.builder(
OtlpGrpcSpanExporter.builder()
.setEndpoint("http://otel-collector:4317")
.build()).build())
.build())
.setPropagators(
ContextPropagators.create(
TextMapPropagator.composite(
W3CTraceContextPropagator.getInstance(),
W3CBaggagePropagator.getInstance())))
.build();
}
-
数据库连接池配置需要根据实际吞吐量调整，建议公式：
code复制最大连接数 = (平均查询时间(ms) × 峰值TPS) / 1000 + 缓冲系数(20-30%) -
缓存更新策略推荐采用"先更新数据库再删除缓存"模式，配合本地缓存短TTL，可平衡一致性与性能。