Mybatis如何配置多数据源

MyBatis 多数据源配置的核心是通过AbstractRoutingDataSource实现动态路由，结合 Spring AOP 可实现声明式切换，适用于读写分离、多业务库等场景。实际使用中需注意事务一致性和线程安全问题，根据业务复杂度选择合适的切换策略。

  1. 先在配置文件里写好两个库的地址
    就像给两个数据库 “编个号”，比如叫 db1 和 db2，把它们的连接地址、账号密码都写在 application.yml 里，告诉程序 “这俩库你得认识”。
  2. 搞个 “数据源总管”
    用 Spring 提供的一个叫 AbstractRoutingDataSource 的工具，它就像个 “调度员”。你得告诉它：“db1 对应哪个库，db2 对应哪个库”，再指定一个默认用哪个（比如默认用 db1）。
  3. 给线程贴个 “标签”
    用 ThreadLocal 这个东西，给当前线程贴个 “用 db1” 或 “用 db2” 的标签。程序执行时，“调度员” 会看这个标签，决定去查哪个库。
  4. 用的时候指定一下就行
    两种方式：
  • 简单的话，直接在方法上贴个自定义注解AOP，比如 @用 db2，调用这个方法时就自动切到 db2 了；

高并发场景下Canal出现的不一致问题

  1. 从源头（MySQL）保证 binlog 格式正确、顺序可靠；
  2. 中间层（Canal）通过集群化和偏移量持久化，确保不丢数据、不重复解析；
  3. 消费端通过幂等性设计和可靠存储，确保事件被正确处理；
  4. 最后通过业务层的定期校验，兜底解决极端场景下的不一致。

DDD领域驱动设计架构

DDD（Domain-Driven Design）领域驱动设计是一种软件架构设计方法，它的核心思想是把业务逻辑和领域知识放在代码的中心位置，让代码更贴近业务需求。

DDD的核心概念

1. 领域（Domain）

领域就是我们要解决的业务问题，比如电商系统中的订单管理、用户管理、商品管理等，每个都是一个领域。

2. 实体（Entity）

实体就是有唯一标识的对象，比如用户实体，每个用户都有唯一的用户ID，即使两个用户的姓名、年龄都一样，但ID不同就是不同的实体。

3. 值对象（Value Object）

值对象就是没有唯一标识的对象，比如地址、金额、颜色等，只要属性值相同就认为是同一个对象。

4. 聚合（Aggregate）

聚合就是一组相关的实体和值对象的集合，比如订单聚合包含订单实体、订单项实体、地址值对象等。聚合有一个根实体，外部只能通过根实体来访问聚合内的其他对象。

5. 领域服务（Domain Service）

领域服务就是那些不属于任何实体的业务逻辑，比如计算订单总价、验证用户权限等。

DDD的分层架构

1. 用户界面层（User Interface Layer）

这一层负责处理用户的输入输出，比如Web控制器、API接口等。

2. 应用层（Application Layer）

应用层负责协调领域对象完成业务用例，它不包含业务逻辑，只是调用领域层的服务。

3. 领域层（Domain Layer）

领域层是DDD的核心，包含所有的业务逻辑和领域知识，包括实体、值对象、领域服务等。

4. 基础设施层（Infrastructure Layer）

基础设施层负责技术实现，比如数据库访问、外部服务调用、消息队列等。

DDD的优势

1. 业务逻辑集中

所有的业务逻辑都集中在领域层，不会散落在各个地方，维护起来更容易。

2. 代码更贴近业务

代码结构和业务结构保持一致，开发人员更容易理解业务需求。

3. 可测试性强

领域层的业务逻辑可以独立测试，不依赖外部系统。

4. 可维护性好

当业务需求变化时，只需要修改领域层的代码，其他层的代码基本不变。

DDD的实施步骤

1. 领域建模

首先分析业务需求，识别出领域、实体、值对象、聚合等概念。

2. 设计分层架构

根据DDD的分层原则，设计出清晰的分层架构。

3. 实现领域层

先实现领域层的核心业务逻辑，包括实体、值对象、领域服务等。

4. 实现其他层

然后实现应用层、用户界面层和基础设施层。

DDD的实践建议

1. 从简单开始

不要一开始就追求完美的DDD架构，先从简单的业务场景开始实践。

2. 持续重构

随着对业务理解的深入，不断重构代码结构，让它更贴近业务。

3. 团队协作

DDD需要业务专家和技术专家密切协作，共同理解业务需求。

4. 工具支持

可以使用一些工具来支持DDD的实施，比如事件风暴、领域建模工具等。

DDD的常见问题

1. 过度设计

不要为了DDD而DDD，要根据实际业务需求来设计架构。

2. 领域边界不清

要明确各个领域的边界，避免领域之间的耦合。

3. 技术实现复杂

DDD的架构可能比传统的三层架构复杂，需要团队有足够的技术能力。

4. 学习成本高

DDD需要团队学习新的概念和方法，有一定的学习成本。

DDD在项目中的应用

在实际项目中，我们可以这样应用DDD：

  1. 识别业务领域：比如电商系统可以分为用户领域、商品领域、订单领域、支付领域等。

  2. 设计聚合：比如订单聚合包含订单实体、订单项实体、地址值对象等。

  3. 实现领域服务：比如订单计算服务、库存检查服务等。

  4. 分层实现：按照DDD的分层架构，逐层实现各个功能。

  5. 持续优化：根据业务需求的变化，不断优化架构设计。

DDD不是银弹，它适合复杂的业务系统，对于简单的CRUD系统，传统的三层架构可能更合适。关键是要根据实际业务需求来选择合适的架构模式。