题目
设计高并发场景下的用户积分变更系统
信息
- 类型：问答
- 难度：⭐⭐
考点
事务处理,并发控制,性能优化
快速回答
在高并发积分变更场景中，核心解决方案包括：
- 使用事务（BEGIN/COMMIT）保证操作的原子性
- 通过SELECT FOR UPDATE实现行级锁避免并发冲突
- 采用批量更新减少事务提交次数
- 使用索引优化（如user_id索引）加速查询
- 考虑读写分离或分库分表应对更高并发
问题场景
电商系统中，用户完成订单、评价等行为时需实时增减积分。当出现瞬时高并发（如秒杀活动）时，需解决：1）积分准确性 2）系统性能 3）并发冲突问题。
核心解决方案
1. 事务处理与并发控制
原理说明： PostgreSQL的MVCC机制虽提供读并发性，但写操作仍需显式锁控制。使用SELECT FOR UPDATE锁定目标行，防止其他事务修改。
代码示例：
BEGIN;
-- 锁定用户积分行
SELECT points FROM user_points WHERE user_id = 1001 FOR UPDATE;
-- 计算新积分（增加50分）
UPDATE user_points
SET points = points + 50,
version = version + 1 -- 乐观锁版本号
WHERE user_id = 1001;
COMMIT;2. 性能优化策略
- 批量更新： 合并多个操作减少事务开销
UPDATE user_points SET points = points + CASE user_id WHEN 1001 THEN 50 WHEN 1002 THEN 30 END WHERE user_id IN (1001, 1002); - 索引优化： 确保
user_id有B-tree索引 - 连接池配置： 使用PgBouncer管理数据库连接
3. 进阶方案
- 异步处理： 用RabbitMQ/Kafka缓冲请求，Worker批量消费
- 分片策略： 按user_id分表（PostgreSQL分区表）
- 物化视图： 预聚合积分汇总数据
最佳实践
- 事务尽量简短，避免长事务锁竞争
- 读写分离：写主库，读从库
- 监控锁等待：
SELECT * FROM pg_locks - 设置合理的事务隔离级别（通常Read Committed）
常见错误
- 丢失更新： 未加锁导致并发覆盖
- 死锁： 多行更新顺序不一致引发死锁
- 性能瓶颈： 高频单行更新导致I/O压力
- 连接耗尽： 未使用连接池导致连接爆炸
扩展知识
- PostgreSQL特性： SKIP LOCKED跳过已锁行，避免阻塞
- 乐观锁： 通过version字段实现（见代码示例）
- 压测工具： 使用pgbench模拟并发场景
- 替代方案： 使用Redis原子操作处理实时计数，定期同步到PG
