Canal 可以简单理解为数据库的 “实时消息通知员”。

它的核心作用：盯着数据库的一举一动，只要数据有新增、修改、删除，就立刻把这些变化告诉需要知道的系统。

打个比方：

• 就像你网购后，快递员（Canal）会盯着仓库（数据库），一旦你的商品（数据）有出库、运输等变动，马上推送给你（其他系统）。

用法很简单：

1. 让数据库开启 “日志记录”（binlog），记下所有数据变化
2. Canal 假装成 “数据库的小跟班”，实时读取这些日志
3. 解析后，把变化按规则发给缓存、搜索、数据分析等系统

这样一来，不用在业务代码里写一堆同步逻辑，各系统就能自动拿到最新数据了。

在电商项目中，Canal 是一个基于 MySQL 二进制日志（binlog）的增量同步工具，常用于实现数据的实时同步、缓存更新、业务解耦等场景。由于电商系统对数据一致性和实时性要求极高（如订单状态同步、库存更新、搜索索引刷新等），Canal 成为解决这些问题的重要中间件。

一、Canal 工作原理

Canal 模拟 MySQL 主从复制的交互协议，伪装成 MySQL 的从节点（slave），向主节点（master）发送 dump 请求，获取 MySQL 的 binlog 并解析，从而实时捕获数据库的增量变更（insert/update/delete）。

核心流程：

1. MySQL 开启 binlog（row 模式，记录每行数据的变更细节）。
2. Canal 客户端连接 MySQL 主库，模拟从库握手。
3. Canal 接收并解析 binlog 事件，提取数据变更信息。
4. 应用程序通过 Canal 客户端获取变更数据，执行后续业务（如更新缓存、同步到 ES 等）。

二、电商项目中 Canal 的典型用途

1. 实时缓存更新

电商系统大量依赖 Redis 缓存（如商品详情、库存、用户信息），传统方案中修改数据库后需手动更新缓存，易出现 “缓存不一致” 问题。Canal 方案：

• 监听商品表（product）、库存表（inventory）的 binlog 变更。
• 当数据库数据更新时，Canal 捕获变更并自动更新 Redis 缓存，确保缓存与数据库一致。

// 伪代码：Canal 监听商品表变更，更新 Redis 缓存
public class ProductDataHandler implements EntryHandler<Product> {
    @Autowired
    private RedisTemplate<String, Product> redisTemplate;

    @Override
    public void insert(Product product) {
        // 新增商品时，写入缓存
        redisTemplate.opsForValue().set("product:" + product.getId(), product);
    }

    @Override
    public void update(Product before, Product after) {
        // 更新商品时，更新缓存
        redisTemplate.opsForValue().set("product:" + after.getId(), after);
    }

    @Override
    public void delete(Product product) {
        // 删除商品时，清除缓存
        redisTemplate.delete("product:" + product.getId());
    }
}

2. 订单状态实时同步

电商订单流程涉及多个系统（订单系统、支付系统、物流系统），订单状态变更需实时同步到各系统。Canal 方案：

• 监听订单表（order）的状态字段（status）变更。
• 当订单状态从 “待支付” 变为 “已支付” 时，Canal 触发事件，通知库存系统扣减库存、物流系统创建物流单。

3. 搜索索引实时更新

电商搜索（如商品搜索）依赖 Elasticsearch（ES），需保证商品信息变更后 ES 索引实时更新。Canal 方案：

• 监听商品表、类目表的 binlog 变更。
• 解析变更数据后，通过 Canal 客户端同步到 ES，确保用户搜索到最新商品信息。

4. 数据异构与跨库同步

电商系统可能分库分表（如订单表按用户 ID 分片），或需将核心数据同步到数据仓库（如 Hive）用于分析。Canal 方案：

• 从业务库同步增量数据到数据仓库，避免全量同步的性能损耗。
• 支持跨数据库类型同步（如 MySQL → PostgreSQL）。

5. 分布式事务补偿

电商下单流程涉及 “扣库存”“创建订单” 等操作，若某一步失败，需通过补偿机制回滚。Canal 方案：

• 监听库存表和订单表的变更，若发现 “订单创建成功但库存未扣减” 的异常，触发补偿逻辑（如自动扣减库存或取消订单）。

三、电商项目中 Canal 的架构设计

通常采用 “Canal Server + 消息队列（Kafka/RocketMQ） + 消费端” 的架构，确保高可用和削峰填谷：

1. Canal Server：部署多个节点，监听 MySQL binlog，将解析后的变更数据发送到消息队列。
2. 消息队列：缓存变更事件，避免消费端压力过大。
3. 消费端：多个业务服务（如缓存服务、搜索服务）订阅消息队列，处理各自关注的变更事件。

四、注意事项

1. MySQL 配置：需开启 binlog，并设置为 row 模式（binlog_format=ROW），否则无法获取行级变更细节。
2. 数据一致性：Canal 同步存在毫秒级延迟，需设计业务逻辑容忍短暂不一致（如通过版本号控制）。
3. 高可用：Canal Server 需集群部署，结合 ZooKeeper 实现主从切换；MySQL 建议主从架构，避免主库故障导致同步中断。
4. 权限控制：Canal 连接 MySQL 的账号需授予 REPLICATION SLAVE 和 REPLICATION CLIENT 权限。

总结

在电商项目中，Canal 是实现 “数据实时同步” 和 “系统解耦” 的关键工具，尤其适用于缓存更新、搜索索引同步、跨系统数据一致性保障等场景。通过 Canal，可大幅减少业务代码中的 “同步逻辑”，提升系统的可维护性和实时性。