分布式事务在点赞功能中的实现

 

---

title: 分布式事务在点赞功能中的实现
date: 2025/04/27 13:01:10
updated: 2025/04/27 13:01:10
author: cmdragon

excerpt:
分布式事务在点赞功能中面临原子性、数据一致性和失败补偿的挑战。Tortoise-ORM提供基础事务和装饰器事务两种管理方式，确保数据一致性。点赞功能实现需防重复点赞和事务处理，采用唯一约束防止重复。跨服务事务处理使用Saga模式，按反向顺序执行补偿操作确保最终一致性。常见报错包括事务超时、唯一约束冲突和请求参数校验失败，需优化事务操作、使用upsert和详细响应模型解决。

categories:

• 后端开发
• FastAPI

tags:

• 分布式事务
• 微服务架构
• Tortoise-ORM
• 点赞功能
• Saga模式
• 事务管理
• 数据一致性

---

扫描二维码关注或者微信搜一搜：编程智域 前端至全栈交流与成长

探索数千个预构建的 AI 应用，开启你的下一个伟大创意：https://tools.cmdragon.cn/

第一章：分布式事务在点赞功能中的应用

1.1 分布式事务核心原理

在微服务架构中，一个业务操作可能涉及多个独立服务的数据修改。传统数据库事务的ACID特性（原子性、一致性、隔离性、持久性）在分布式环境中面临挑战：

• 原子性困境：跨服务的操作无法使用单一数据库事务保证
• 数据一致性：各服务数据库独立，无法通过锁机制实现强一致性
• 失败补偿：部分操作成功后出现异常需要回滚的复杂处理

以点赞功能为例，典型业务场景包含：

用户服务（扣除点赞次数） → 文章服务（增加点赞数） → 通知服务（发送消息）

1.2 Tortoise-ORM事务配置

Tortoise-ORM提供两种事务管理方式：

基础事务模式：

async with in_transaction() as conn:
    await User.filter(id=user_id).update(likes=F('likes') + 1)
    await Article.filter(id=article_id).update(likes=F('likes') + 1)

装饰器事务模式：

@atomic()
async def like_article(user_id: int, article_id: int):
    user = await User.get(id=user_id)
    article = await Article.get(id=article_id)
    await Like.create(user=user, article=article)

1.3 点赞功能实现方案

完整实现包含防重复点赞和事务处理：

# 数据库模型
class Like(Model):
    id = fields.IntField(pk=True)
    user = fields.ForeignKeyField('models.User')
    article = fields.ForeignKeyField('models.Article')
    created_at = fields.DatetimeField(auto_now_add=True)

    class Meta:
        unique_together = (('user', 'article'),)  # 唯一约束防重复


# 业务逻辑
async def toggle_like(user_id: int, article_id: int):
    try:
        async with in_transaction():
            # 检查是否已点赞
            exists = await Like.exists(user_id=user_id, article_id=article_id)
            if exists:
                # 取消点赞
                await Like.filter(user_id=user_id, article_id=article_id).delete()
                delta = -1
            else:
                # 新增点赞
                await Like.create(user_id=user_id, article_id=article_id)
                delta = 1

            # 更新统计数
            await User.filter(id=user_id).update(likes_count=F('likes_count') + delta)
            await Article.filter(id=article_id).update(likes_count=F('likes_count') + delta)

            return {"status": "success", "action": "unlike" if exists else "like"}
    except IntegrityError:
        raise HTTPException(status_code=400, detail="操作冲突，请重试")

1.4 跨服务事务处理

当涉及多个微服务时，采用Saga事务模式实现最终一致性：

# Saga协调器示例
class LikeSaga:
    def __init__(self):
        self.compensation_actions = []

    async def execute(self):
        try:
            # 阶段1：预扣点赞次数
            await user_service.decrement_quota(user_id)
            self.compensation_actions.append(
                lambda: user_service.increment_quota(user_id)
            )

            # 阶段2：增加文章点赞
            await article_service.increment_likes(article_id)
            self.compensation_actions.append(
                lambda: article_service.decrement_likes(article_id)
            )

            # 阶段3：发送通知
            await notification_service.send_like_notice(user_id, article_id)
        except Exception as e:
            # 执行补偿操作
            for action in reversed(self.compensation_actions):
                await action()
            raise

课后Quiz

Q1：为什么在点赞功能中需要唯一约束？
A. 提高查询速度
B. 防止用户重复点赞
C. 减少数据库存储空间
D. 方便统计用户数据

正确答案：B
解析：唯一约束确保(user_id, article_id)组合的唯一性，从数据库层面防止重复点赞，比应用层检查更可靠。

Q2：Saga模式中的补偿操作应该按什么顺序执行？
A. 任意顺序
B. 正向顺序
C. 反向顺序
D. 随机顺序

正确答案：C
解析：补偿操作需要按照与业务操作相反的顺序执行，例如先撤销最后完成的操作。

常见报错解决

错误1：TransactionManagementError - 事务超时
原因分析：

• 长时间未提交的事务导致锁等待超时
• 复杂事务处理时间超过数据库配置的超时阈值

解决方案：

1. 优化事务内的操作，减少不必要的数据库交互
2. 在事务开始时设置合理超时时间：

async with in_transaction(timeout=30) as conn:  # 30秒超时
# 业务操作

错误2：IntegrityError - 唯一约束冲突
原因分析：

• 并发请求导致同时插入相同数据
• 未正确处理重复请求

解决方案：

1. 在前端添加防重提交机制
2. 在后端使用upsert操作：

await Like.update_or_create(
    user_id=user_id,
    article_id=article_id,
    defaults={'created_at': datetime.now()}
)

错误3：ValidationError - 请求参数校验失败
原因分析：

• 客户端传递的参数不符合Pydantic模型要求
• 数值型参数传递了字符串类型

解决方案：

1. 检查请求体是否符合接口文档要求
2. 在路由中添加详细的响应模型：

@app.post("/likes", response_model=LikeResponse, responses={
    422: {"model": ValidationErrorResponse}
})

余下文章内容请点击跳转至 个人博客页面 或者 扫码关注或者微信搜一搜：编程智域 前端至全栈交流与成长，阅读完整的文章：分布式事务在点赞功能中的实现 | cmdragon’s Blog

往期文章归档：

• Tortoise-ORM级联查询与预加载性能优化 | cmdragon’s Blog
• 使用Tortoise-ORM和FastAPI构建评论系统 | cmdragon’s Blog
• 分层架构在博客评论功能中的应用与实现 | cmdragon’s Blog
• 深入解析事务基础与原子操作原理 | cmdragon’s Blog
• 掌握Tortoise-ORM高级异步查询技巧 | cmdragon’s Blog
• FastAPI与Tortoise-ORM实现关系型数据库关联 | cmdragon’s Blog
• Tortoise-ORM与FastAPI集成：异步模型定义与实践 | cmdragon’s Blog
• 异步编程与Tortoise-ORM框架 | cmdragon’s Blog
• FastAPI数据库集成与事务管理 | cmdragon’s Blog
• FastAPI与SQLAlchemy数据库集成 | cmdragon’s Blog
• FastAPI与SQLAlchemy数据库集成与CRUD操作 | cmdragon’s Blog
• FastAPI与SQLAlchemy同步数据库集成 | cmdragon’s Blog
• SQLAlchemy 核心概念与同步引擎配置详解 | cmdragon’s Blog
• FastAPI依赖注入性能优化策略 | cmdragon’s Blog
• FastAPI安全认证中的依赖组合 | cmdragon’s Blog
• FastAPI依赖注入系统及调试技巧 | cmdragon’s Blog
• FastAPI依赖覆盖与测试环境模拟 | cmdragon’s Blog
• FastAPI中的依赖注入与数据库事务管理 | cmdragon’s Blog
• FastAPI依赖注入实践：工厂模式与实例复用的优化策略 | cmdragon’s Blog
• FastAPI依赖注入：链式调用与多级参数传递 | cmdragon’s Blog
• FastAPI依赖注入：从基础概念到应用 | cmdragon’s Blog
• FastAPI中实现动态条件必填字段的实践 | cmdragon’s Blog
• FastAPI中Pydantic异步分布式唯一性校验 | cmdragon’s Blog
• 掌握FastAPI与Pydantic的跨字段验证技巧 | cmdragon’s Blog
• FastAPI中的Pydantic密码验证机制与实现 | cmdragon’s Blog
• 深入掌握FastAPI与OpenAPI规范的高级适配技巧 | cmdragon’s Blog
• Pydantic字段元数据指南：从基础到企业级文档增强 | cmdragon’s Blog
• Pydantic Schema生成指南：自定义JSON Schema | cmdragon’s Blog
• Pydantic递归模型深度校验36计：从无限嵌套到亿级数据的优化法则 | cmdragon’s Blog
• Pydantic异步校验器深：构建高并发验证系统 | cmdragon’s Blog
• Pydantic根校验器：构建跨字段验证系统 | cmdragon’s Blog
• Pydantic配置继承抽象基类模式 | cmdragon’s Blog
• Pydantic多态模型：用鉴别器构建类型安全的API接口 | cmdragon’s Blog
• FastAPI性能优化指南：参数解析与惰性加载 | cmdragon’s Blog