在MySQL主从复制（Master-Slave Replication）架构中，数据从一个数据库服务器（称为“主服务器”或“源服务器”）复制到一个或多个数据库服务器（称为“从服务器”或“副本服务器”）。这种机制确保了数据的一致性和可用性，同时提高了系统的性能和可靠性。下面是MySQL主从同步的基本原理和一些关键步骤的图解说明。

## mysql 主从复制安装配置

### 基础设置准备

```
sh

#操作系统：
centos6.5
#mysql版本：
5.7
#两台虚拟机：
node1:192.168.85.111（主）
node2:192.168.85.112（从）
```

### 安装mysql数据库

```
sh

#详细安装和卸载的步骤参考对应的文档
```

### 在两台数据库中分别创建数据库

```
sql

--注意两台必须全部执行
create database mac;
```

### 在主（node1）服务器进行如下配置：

在主服务器上，需要启用二进制日志（binary log），这是记录所有修改数据库数据的SQL语句的日志。这些日志是复制过程中从服务器用来同步数据的基础。

```
sh

#修改配置文件，执行以下命令打开mysql配置文件
vi /etc/my.cnf
#在mysqld模块中添加如下配置信息
log-bin=master-bin #二进制文件名称
binlog-format=ROW  #二进制日志格式，有row、statement、mixed三种格式，row指的是把改变的内容复制过去，而不是把命令在从服务器上执行一遍，statement指的是在主服务器上执行的SQL语句，在从服务器上执行同样的语句。MySQL默认采用基于语句的复制，效率比较高。mixed指的是默认采用基于语句的复制，一旦发现基于语句的无法精确的复制时，就会采用基于行的复制。
server-id=1		   #要求各个服务器的id必须不一样
binlog-do-db=mac   #同步的数据库名称
```

### 配置从服务器登录主服务器的账号授权

```
sql

--授权操作
set global validate_password_policy=0;
set global validate_password_length=1;
grant replication slave on *.* to 'root'@'%' identified by '123456';
--刷新权限
flush privileges;
```

### 从服务器的配置

```
sh

#修改配置文件，执行以下命令打开mysql配置文件
vi /etc/my.cnf
#在mysqld模块中添加如下配置信息
log-bin=master-bin	#二进制文件的名称
binlog-format=ROW	#二进制文件的格式
server-id=2			#服务器的id
```

### 重启主服务器的 mysqld 服务

```
sh

#重启mysql服务
service mysqld restart
#登录mysql数据库
mysql -uroot -p
#查看master的状态
show master status；
```

### 重启从服务器并进行相关配置

```
sh

#重启mysql服务
service mysqld restart
#登录mysql
mysql -uroot -p
#连接主服务器
change master to master_host='192.168.85.11',master_user='root',master_password='123456',master_port=3306,master_log_file='master-bin.000001',master_log_pos=154;
```

在从服务器上启动复制过程

```
sql

start slave
```

查看slave的状态

```
sql

show slave status\G
```

此时可以在主服务器进行相关的数据添加删除工作，在从服务器看相关的状态

## mysql 主从复制原理

### 为什么需要主从复制？

在业务复杂的系统中，有这么一个情景，有一句sql语句需要锁表，导致暂时不能使用读的服务，那么就很影响运行中的业务，使用主从复制，让主库负责写，从库负责读，这样，即使主库出现了锁表的情景，通过读从库也可以保证业务的正常运作。

做数据的热备,架构的扩展。业务量越来越大，I/O访问频率过高，单机无法满足，此时做多库的存储，降低磁盘I/O访问的频率，提高单个机器的I/O性能。

### 什么是主从复制？

MySQL 主从复制是指数据可以从一个MySQL数据库服务器主节点复制到一个或多个从节点。MySQL 默认采用异步复制方式，这样从节点不用一直访问主服务器来更新自己的数据，数据的更新可以在远程连接上进行，从节点可以复制主数据库中的所有数据库或者特定的数据库，或者特定的表。

### mysql 复制原理

原理：

* master服务器将数据的改变记录二进制binlog日志，当master上的数据发生改变时，则将其改变写入二进制日志中；
* slave服务器会在一定时间间隔内对master二进制日志进行探测其是否发生改变，如果发生改变，则开始一个I/OThread请求master二进制事件
* 同时主节点为每个I/O线程启动一个dump线程，用于向其发送二进制事件，并保存至从节点本地的中继日志中，从节点将启动SQL线程从中继日志中读取二进制日志，在本地重放，使得其数据和主节点的保持一致，最后I/OThread和SQLThread将进入睡眠状态，等待下一次被唤醒。

也就是说：

* 从库会生成两个线程,一个I/O线程,一个SQL线程;
* I/O线程会去请求主库的binlog,并将得到的binlog写到本地的relay-log(中继日志)文件中;
* 主库会生成一个log dump线程,用来给从库I/O线程传binlog;
* SQL线程,会读取relay log文件中的日志,并解析成sql语句逐一执行;

注意：

master将操作语句记录到binlog日志中，然后授予slave远程连接的权限（master一定要开启binlog二进制日志功能；通常为了数据安全考虑，slave也开启binlog功能）。

slave开启两个线程：IO线程和SQL线程。其中：IO线程负责读取master的binlog内容到中继日志relay log里；SQL线程负责从relay log日志里读出binlog内容，并更新到slave的数据库里，这样就能保证slave数据和master数据保持一致了。

Mysql复制至少需要两个Mysql的服务，当然Mysql服务可以分布在不同的服务器上，也可以在一台服务器上启动多个服务。

Mysql复制最好确保master和slave服务器上的Mysql版本相同（如果不能满足版本一致，那么要保证master主节点的版本低于slave从节点的版本）

master和slave两节点间时间需同步

主从同步原理图解：

![image.png](https://blog.liushigong.cn/static/img/c127ce214ab64c305a4ef10882152497.image.webp)

* 二进制日志（Binary Log）：主服务器上的所有修改（INSERT、UPDATE、DELETE等）都会被记录到二进制日志中。
* 复制事件（Replication Events）：这些日志被从服务器读取，并被转换为SQL语句来应用在从服务器的数据库上。
* 中继日志（Relay Log）：从服务器上的中继日志存储了从主服务器接收到的二进制日志事件，以便稍后应用。这是为了确保即使在主服务器暂时不可用时，复制过程也不会中断。
* 数据一致性：通过定期检查二进制日志的位置和文件名，确保主从数据的一致性。

##### 具体步骤：

1、从库通过手工执行change master to 语句连接主库，提供了连接的用户一切条件（user 、password、port、ip），并且让从库知道，二进制日志的起点位置（file名 position 号）； start slave

2、从库的IO线程和主库的dump线程建立连接。

3、从库根据change master to 语句提供的file名和position号，IO线程向主库发起binlog的请求。

4、主库dump线程根据从库的请求，将本地binlog以events的方式发给从库IO线程。

5、从库IO线程接收binlog events，并存放到本地relay-log中，传送过来的信息，会记录到master.info中

6、从库SQL线程应用relay-log，并且把应用过的记录到relay-log.info中，默认情况下，已经应用过的relay 会自动被清理purge

### mysql 主从同步延时分析

mysql的主从复制都是单线程的操作，主库对所有DDL和DML产生的日志写进binlog，由于binlog是顺序写，所以效率很高，slave的sql thread线程将主库的DDL和DML操作事件在slave中重放。DML和DDL的IO操作是随机的，不是顺序，所以成本要高很多，另一方面，由于sql thread也是单线程的，当主库的并发较高时，产生的DML数量超过slave的SQL thread所能处理的速度，或者当slave中有大型query语句产生了锁等待，那么延时就产生了。

#### 解决方案

1. 业务的持久化层的实现采用分库架构，mysql服务可平行扩展，分散压力。
2. 单个库读写分离，一主多从，主写从读，分散压力。这样从库压力比主库高，保护主库。
3. 服务的基础架构在业务和mysql之间加入memcache或者redis的cache层。降低mysql的读压力。
4. 不同业务的mysql物理上放在不同机器，分散压力。
5. 使用比主库更好的硬件设备作为slave，mysql压力小，延迟自然会变小。
6. 使用更加强劲的硬件设备

代码上的解决方案

先 insert 或 update，然后 select 可能会因为主从同步导致未查询到数据或者查询到更新前数据，导致代码运行异常。

所以在主从同步机制下，代码可以通过对象的引用传递进行处理，而不是再次查询。

数据库 - Mysql 高性能架构的读写分离

数据库 - Mysql 的全量与增量同步（作废，请查看平滑迁移一文）

在现代分布式系统中，我们常常需要将数据同时写入多个存储系统（如数据库+缓存），这种操作被称为"双写"。双写场景下最大的挑战是如何保证不同存储系统间的数据一致性。本文将深入探讨双写一致性问题，并通过Java实战演示解决方案。

## 双写一致性挑战

常见问题场景：

* 写入顺序不一致：先写缓存成功但数据库失败
* 并发冲突：多个线程同时更新同一数据
* 部分失败：一个存储成功另一个失败
* 网络延迟：不同存储系统的响应时间差异

## 主流方案

### 基于消息队列的最终一致性方案

基于消息队列的最终一致性方案的实现思路为： **应用服务 → 更新数据库 ↓ 同时发送消息 → 消息队列 → 缓存服务 → Redis**

#### 核心代码

数据库操作与消息发送（原子操作）

```
java

@Service
@RequiredArgsConstructor
public class UserService {
    private final UserRepository userRepository;
    private final MessageSender messageSender;

    @Transactional
    public void updateUser(User user) {
        // 1. 更新数据库
        userRepository.save(user);
        
        // 2. 发送缓存更新消息
        messageSender.sendCacheUpdate(new CacheUpdateEvent(
            "user:" + user.getId(),
            user
        ));
    }
}
```

消息发送器（保证可靠性）

```
java

@Component
@RequiredArgsConstructor
public class MessageSender {
    private final RabbitTemplate rabbitTemplate;
    private final TransactionTemplate transactionTemplate;

    public void sendCacheUpdate(CacheUpdateEvent event) {
        transactionTemplate.execute(status -> {
            // 将消息存入本地事务表（略）
            saveToLocalTxTable(event);
            
            // 发送到MQ
            rabbitTemplate.convertAndSend(
                "cache.update.exchange",
                "cache.update.key",
                event
            );
            return null;
        });
    }
}
```

缓存消费者（幂等处理）

```
java

@Component
@RequiredArgsConstructor
public class CacheConsumer {
    private final RedisTemplate<String, Object> redisTemplate;
    private final CacheUpdateRecordRepository recordRepository;

    @RabbitListener(queues = "cache.update.queue")
    public void handleMessage(CacheUpdateEvent event) {
        // 幂等检查：防止重复消费
        if (recordRepository.existsByMessageId(event.getMessageId())) {
            return;
        }
        
        try {
            // 更新缓存
            redisTemplate.opsForValue().set(
                event.getKey(),
                event.getData(),
                Duration.ofMinutes(30)
            );
            
            // 记录消费日志
            recordRepository.save(new CacheUpdateRecord(event.getMessageId()));
        } catch (Exception e) {
            // 告警并加入重试队列
            sendToRetryQueue(event);
        }
    }
}
```

在实体中添加版本号字段，每次更新完版本号叠加，发送消息的同时存储事务消息记录（缓存更新的快照记录），到缓存消费者中进行幂等校验处理，校验后将缓存进行更新，如果更新失败，可抛出异常进行重试，也可进入自定义重试队列中，当重试达到一定次数后，进入死信队列人工处理。

```
java

@Entity
public class User {
    @Id
    private Long id;
    
    @Version
    private Long version; // 乐观锁版本号
    
    // 其他字段...
}
```

注意

以上仅为demo实现，具体可根据思路自行扩展，例如可以将存储的本地事务消息添加状态，在消费者中可以先查询缓存版本号与当前消息的版本号进行对比，对比不通过则更新缓存，缓存处理成功时，查询一次最新缓存的版本号与事务版本号对比，如果对比成功则对本地事务消息的状态进行更新。

这个时候，定时任务只需要扫描缓存未更新的情况即可，而无需全量扫描。

#### 补偿与降级

添加双重保障机制，消息队列保证主流程，通过定时任务兜底检查，如果版本不一致也可以添加补偿缓存数据，保证数据的最终一致性。同时查询方法添加降级策略，保证服务的高可用。

补偿任务（兜底机制）

```
java

@Scheduled(fixedDelay = 30000)
public void checkInconsistency() {
    // 查询最近更新的数据库记录
    List<User> recentUsers = userRepository.findUpdatedLast5Minutes();
    
    recentUsers.forEach(user -> {
        String key = "user:" + user.getId();
        User cachedUser = (User) redisTemplate.opsForValue().get(key);
        
        // 比较数据库与缓存的数据版本
        if (cachedUser == null || 
            cachedUser.getVersion() < user.getVersion()) {
            // 触发缓存更新
            redisTemplate.opsForValue().set(key, user);
        }
    });
}
```

熔断降级策略

```
java

// 当缓存更新失败时降级
public User getUser(Long id) {
    try {
        return cacheService.getUser(id);
    } catch (Exception e) {
        log.warn("缓存降级，查询数据库");
        return userRepository.findById(id).orElse(null);
    }
}
```

#### 方案评估

方案的整体效果上，通过高性能的 RocketMQ 可以保障最终一致性达到秒级。不过会对性能产生一些影响：由于添加了消息发送，会给业务流程操作增加部分耗时。同时依赖 MQ 中间件，要注意消息堆积，消息幂等，消息的可靠性处理

此方案的核心原则：容忍短暂不一致，保证最终一致；优先保障核心存储，非核心系统可降级；始终设计补偿机制。

### 同步双写，失败补偿

补偿机制的核心思想是：当主操作成功但辅助操作失败时，通过后续的补偿操作来达到数据一致的状态。在双写场景中，补偿机制通常用于在数据库更新成功但缓存更新失败时，通过定时任务或后台线程来修复缓存的不一致状态。

#### 补偿机制方案设计

方案本质就是双写，不成功就重试，重试多次不成功，则告警通知，主体流程如下：

1. **主操作**：先更新数据库（事务操作），再更新缓存（或发送消息更新缓存）
2. **失败检测**：当数据库更新失败时，直接失败，无需处理缓存操作
3. **缓存更新**：数据库事务提交成功，开始执行缓存
4. **异步补偿**：如果缓存更新失败，通过线程池进行异步补偿
5. **重试策略**：补偿采用指数退避重试，设置最大重试次数，避免雪崩
6. **最终处理**：超过最大重试次数后，发出告警，人工介入

#### 核心代码

定义基础的补偿架构支撑

```
java

@Slf4j
@Component
public class CompensableTransaction<T> {

    /**
     * 最大重试次数
     */
    private static final int MAX_RETRY = 3;

    /**
     * 静态线程池
     */
    static class CompensableThreadPool {

        private static final AtomicInteger number = new AtomicInteger(1);

        public static final ThreadPoolExecutor executor = new ThreadPoolExecutor(
                Runtime.getRuntime().availableProcessors(),
                Runtime.getRuntime().availableProcessors() * 2,
                60,
                TimeUnit.SECONDS,
                new LinkedBlockingQueue<>(1000),
                r -> new Thread(r, "CompensableTransaction-thread-" + number.getAndIncrement()),
                new ThreadPoolExecutor.CallerRunsPolicy());
    }

    /**
     * 执行
     */
    @SneakyThrows
    public void execute(String operation, Callable<T> doPrimaryAction, Consumer<T> doSecondaryAction, Consumer<T> doCompensate) {
        // 执行主操作
        T call = doPrimaryAction.call();
        try {
            // 执行辅助操作
            doSecondaryAction.accept(call);
        } catch (Exception e) {
            // 异步补偿
            CompensableThreadPool.executor.execute(() -> {
                // 补偿操作
                int retryCount = 0;
                while (retryCount < MAX_RETRY) {
                    try {
                        // 自定义补偿逻辑，成功则返回
                        doCompensate.accept(call);
                        return;
                    } catch (Exception ex) {
                        retryCount++;
                        log.warn("补偿操作失败({}/{}): {}", retryCount, MAX_RETRY, ex.getMessage());
                        // 指数
                        try {
                            TimeUnit.MILLISECONDS.sleep(exponentialBackoff(retryCount));
                        } catch (InterruptedException exc) {
                            log.error("{}补偿操作线程被中断", operation);
                            return;
                        }
                    }
                }
                // 最终补偿失败
                log.error("{}补偿操作最终失败", operation);
                alertAdmin(operation);
            });
        }
    }

    private void alertAdmin(String operation) {
        // 发送告警邮件、短信、钉钉消息
        log.info("发送告警邮件、短信、钉钉消息");
    }

    /**
     * 根据重试次数计算指数停顿时间
     */
    private long exponentialBackoff(int retryCount) {
        // 100ms, 200ms, 400ms...
        return (long) (100 * Math.pow(2, retryCount));
    }
}
```

数据库 + 缓存双写实现

```
java

@Service
public class ImUsersServiceImpl extends ServiceImpl<ImUsersMapper, ImUsers> implements ImUsersService {

    @Resource
    private CompensableTransaction<ImUsers> compensableTransaction;

    /**
     * 初始化用户信息
     *
     * @param userInfo 微信用户信息
     */
    @Override
    public void initUser(WxOAuth2UserInfo userInfo) {
        // 主操作
        Callable<ImUsers> primaryAction = () -> {
            // 保存用户信息
            ImUsers users = BeanUtil.toBean(userInfo, ImUsers.class);
            this.save(users);

            // 登录
            StpUtil.login(users.getId());
            return users;
        };

        // 辅助操作
        Consumer<ImUsers> secondaryAction = users -> {
            // 缓存用户信息
            UserInfo info = BeanUtil.toBean(users, UserInfo.class);
            RedisCacheUtil.hPutAll(String.format(RedisKeyDefine.USER_INFO, users.getId()), BeanUtil.beanToMap(info));
        };

        // 补偿操作
        Consumer<ImUsers> compensateAction = users -> {
            String key = String.format(RedisKeyDefine.USER_INFO, users.getId());
            if (!RedisCacheUtil.hasKey(key)) {
                RedisCacheUtil.hPutAll(String.format(RedisKeyDefine.USER_INFO, users.getId()), BeanUtil.beanToMap(users));
            }
        };
        compensableTransaction.execute("初始化用户信息", primaryAction, secondaryAction, compensateAction);
    }
}
```

此处定义了3个步骤操作：

1. 主操作，就是事务提交的方法
2. 辅助操作，就是缓存等需要双写的方法
3. 补偿操作，当辅助操作失败后，进行补偿操作，可直接复用辅助操作，也可自定义其他处理，例如删除缓存

在实现以上补偿机制的同时，还要注意补偿失败情下的补偿，做好补偿的监控体系，关注补偿的失败率统计与失败的问题定位，进行人工干预补偿，也可定时扫描补偿，就不在过多陈述

#### 补偿机制优缺点分析

其实补偿方案实现相对简单，不依赖其他中间件，补偿操作异步执行对性能影响小，同时保证最终一致性，可靠性比较高。

但也存在一些缺点，在高并发流量下，会存在一定的脏读，就是数据库更新了，缓存还没更新，存在短暂数据不一致的情况，这也是不可避免的；

在一个就是如果 Redis 缓存挂掉了，会导致线程池阻塞，存在性能瓶颈，同时补偿操作本身可能失败，极端情况下需要人工干预。

提示

我个人更加推荐同步双写，失败补偿的方案，适用于大多数并发不高，可接受短暂脏数据的系统。

### 延迟双删方案

延迟双删是一种在双写场景中用于保证缓存与数据库一致性的策略。它主要用于解决在更新数据库和缓存时，由于并发操作导致的脏数据问题。

#### 核心思想

延迟双删是解决缓存与数据库双写一致性的经典策略，其核心流程为：

* 先删缓存 - 避免旧数据污染
* 更新数据库 - 完成持久化操作
* 延迟删除缓存 - 消除并发期间产生的脏数据

先删除缓存 -> 更新数据库 -> 延迟一段时间（比如几百毫秒） -> 再次删除缓存

![deepseek_mermaid_20250616_ebacb0.png](https://blog.liushigong.cn/static/img/4cf89e12422f95fbd6972c7ecfcb4d3b.deepseek_mermaid_20250616_ebacb0.webp)

#### 为什么需要延迟双删？

考虑以下并发场景：

1. 线程A更新数据，先删除缓存，然后准备更新数据库。
2. 此时线程B来读取数据，发现缓存不存在，于是从数据库读取旧数据，并写入缓存。
3. 线程A更新数据库，然后等待一段时间（确保线程B的读操作完成并写入缓存）后再次删除缓存。

这样，线程B写入的旧数据缓存会被第二次删除，后续读取会重新加载最新数据。

#### 核心代码

业务代码的基础实现

```
java

@Service
@RequiredArgsConstructor
public class UserService {
    private final UserRepository userRepository;
    private final RedisTemplate<String, Object> redisTemplate;
    private final ScheduledExecutorService scheduler = 
        Executors.newScheduledThreadPool(4);

    // 更新操作入口
    @Transactional
    public void updateUser(User user) {
        String cacheKey = "user:" + user.getId();
        
        // 1. 先删除缓存
        deleteCache(cacheKey);
        
        // 2. 更新数据库
        userRepository.save(user);
        
        // 3. 提交事务后发起延迟双删
        scheduler.schedule(() -> {
            deleteCacheWithRetry(cacheKey, 3); // 带重试的二次删除
        }, 500, TimeUnit.MILLISECONDS); // 延迟500ms
    }

    // 带重试机制的缓存删除
    private void deleteCacheWithRetry(String key, int maxRetry) {
        int retryCount = 0;
        while (retryCount < maxRetry) {
            try {
                redisTemplate.delete(key);
                log.info("延迟双删成功: {}", key);
                return;
            } catch (Exception e) {
                retryCount++;
                log.warn("缓存删除失败({}/{}): {}", retryCount, maxRetry, key);
                try {
                    Thread.sleep(100 * retryCount); // 指数退避
                } catch (InterruptedException ignored) {}
            }
        }
        log.error("缓存删除最终失败: {}", key);
    }
}
```

优化版 - 结合版本号校验

```
java

// 实体类增加版本控制
@Entity
public class User {
    @Id
    private Long id;
    
    @Version
    private Long version; // 乐观锁版本号
    
    // 其他字段...
}

// 服务层增强校验
public void updateUserWithVersion(User user) {
    String cacheKey = "user:" + user.getId();
    
    // 1. 先删除缓存
    redisTemplate.delete(cacheKey);
    
    // 2. 更新数据库（带版本校验）
    try {
        userRepository.save(user);
    } catch (OptimisticLockingFailureException ex) {
        // 版本冲突时重新加载数据
        User freshUser = userRepository.findById(user.getId()).orElseThrow();
        throw new ConcurrentUpdateException("数据已被修改，请刷新重试");
    }
    
    // 3. 延迟双删（携带版本信息）
    scheduler.schedule(() -> {
        Object cached = redisTemplate.opsForValue().get(cacheKey);
        if (cached instanceof User) {
            User cachedUser = (User) cached;
            // 仅当缓存版本较旧时删除
            if (cachedUser.getVersion() < user.getVersion()) {
                redisTemplate.delete(cacheKey);
            }
        }
    }, 600, TimeUnit.MILLISECONDS);
}
```

生产级增强方案

```
java

@Component
public class CacheDoubleDeleteManager {
    private final RedisTemplate<String, Object> redisTemplate;
    private final RedissonClient redissonClient;
    private final DelayQueue<DeleteTask> delayQueue = new DelayQueue<>();
    
    @PostConstruct
    public void init() {
        // 启动处理线程
        new Thread(this::processTasks).start();
    }
    
    // 添加延迟双删任务
    public void scheduleDelete(String key, long delayMs) {
        delayQueue.put(new DeleteTask(key, delayMs));
    }
    
    // 任务处理核心
    private void processTasks() {
        while (!Thread.currentThread().isInterrupted()) {
            try {
                DeleteTask task = delayQueue.take();
                RLock lock = redissonClient.getLock(task.key + ":lock");
                try {
                    if (lock.tryLock(1, 5, TimeUnit.SECONDS)) {
                        redisTemplate.delete(task.key);
                    }
                } finally {
                    lock.unlock();
                }
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            }
        }
    }
    
    // 延迟任务对象
    private static class DeleteTask implements Delayed {
        final String key;
        final long executeTime;
        
        DeleteTask(String key, long delayMs) {
            this.key = key;
            this.executeTime = System.currentTimeMillis() + delayMs;
        }
        
        @Override
        public long getDelay(TimeUnit unit) {
            return unit.convert(executeTime - System.currentTimeMillis(), 
                TimeUnit.MILLISECONDS);
        }
        
        @Override
        public int compareTo(Delayed o) {
            return Long.compare(executeTime, ((DeleteTask)o).executeTime);
        }
    }
}
```

#### 延迟双删优缺点分析

延迟双删是平衡性能与一致性的有效方案，以可控延迟换取更高吞吐，适用于写少读多、可接受短暂不一致的业务

优势：

* 有效解决"读请求在更新期间加载旧数据"问题
* 实现简单，不依赖复杂中间件
* 性能影响可控（异步化处理）
* 兼容各种数据库和缓存类型

局限性：

* 短暂不一致窗口（延迟期间）
* 删除操作可能失败（需配合重试）
* 不保证强一致性（最终一致）
* 延迟时间需根据业务调优

注意

没有完美的解决方案，只有最适合场景的方案。延迟双删在电商库存、用户配置等场景表现优异，但对金融交易等强一致性场景需慎重使用。

### 主流方案对比

| 方案 | 原理 | 优点 | 缺点 |
| --- | --- | --- | --- |
| 基于消息队列 | 通过消息队列保证最终一致性 | 高可靠性，解耦系统 | 实现复杂，依赖中间件 |
| 补偿机制 | 失败后执行反向操作 | 简单易实现，适用性高 | 高并发下数据短暂不一致性 |
| 延迟双删策略 | 更新前后删除缓存 | 缓解脏读问题 | 不能完全避免不一致 |

## 总结

保障双写一致性没有银弹，**需要根据业务场景选择合适方案**。注意每种方案完善重试机制，最好结合版本控制，每种方案的监控+告警+兜底三位一体必不可少。

本文展示的基于主流的解决方案进行讲述。在实际应用中还需结合监控（如缓存命中率、不一致告警）和压力测试持续优化。

性能优化 - 保证缓存与DB数据的双写一致性

面试与未来规划 - 随手记

2025-06-14 的今天参与了腾讯云架构师北京技术同盟的线下活动，今天的主题是 **「AI 时代下的架构设计」**，很有幸成为架构师同盟的一员，我将总结分享下今天的内容。

![image.png](https://blog.liushigong.cn/static/img/6ab44cbd6a100ba6aa2825b489762ce1.image.webp)

## 「AI 时代下的架构设计」

今天分享的主要有4个主题，确实收货满满

![image.png](https://blog.liushigong.cn/static/img/7bd1b034041671254b20f47a0f0204b1.image.webp)

### AI 时代下的数据治理

这一篇主题是我比较感兴趣的，之前了解 AI 的时候，就思考过 AI 在大数据处理中的应用，如何通过 AI 来实现业务中各种的数据统计与分析，此处老师分享的是数据治理。

在一些企业中，创建了数据湖仓，对应的数据来源可能从不同的子公司或者其他途径获取，其中不同子公司的数据字典词义相同，但是其语义不同，造成了数据湖仓中的数据分析的紊乱。

当出现此类情况时就需要我们的数据治理，如果数据字典数据量少的情况下，人工处理也是可以的，但是往往真实情况中数据字典量会非常庞大，这个时候我们就需要用到 AI 来治理我们的数据。

#### 数据治理实现思路

数据治理需要制定数据标准，数据规范，可通过 AI 由以下几种方式进行实现

* 智能对话/业务咨询
* 业务术语、业务描述的生成
* 智能识别、智能匹配

在治理的过程中，可以结合「需求文档、设计文档、产品原型、培训文档」等资料训练模式，结合 SQL 给出业务语义，从而实现统一标准规范

![image.png](https://blog.liushigong.cn/static/img/c32f8e2e6c65b43d41db6cc4b1269bb6.image.webp)

![image.png](https://blog.liushigong.cn/static/img/07c90344b902dc7798fe61f7b93cd891.image.webp)

#### AI 数据分级分类的实现思路：向量词

需要专业可靠的词库，否则专业词会被拆分，将会影响最终匹配结果，所以我们要继续完善词库信息

![image.png](https://blog.liushigong.cn/static/img/e756d8b8d6469e882491d025d918b511.image.webp)

![image.png](https://blog.liushigong.cn/static/img/20eb56be55cdc94309e7391c9cc2c5ab.image.webp)

#### 要点回顾

![image.png](https://blog.liushigong.cn/static/img/a39e86c1ee4112114913dd388242a854.image.webp)

#### 总结

![image.png](https://blog.liushigong.cn/static/img/16c0ee63e806ce404d1eff2a4260944e.image.webp)

以上为我在会议中的手画图，整体的数据治理流程就是通过将业务数据导入与采集，然后结合 AI 进行数据治理，统一规范标准后入数据湖仓，接下来通过数据分析与统计，回写到业务数据中进行展示，由此形成闭环。

### AI 时代智能数据存储与处理解决之道

嗯~这一篇在讲结合 AI 的云存储的底层实现，感觉像是在介绍腾讯云产品，直接跳过吧

### AI 驱动下的社交电商架构升级

这一篇是由闫国旗闫老师讲述的电商业务，围绕社交电商的核心业务场景，深入剖析 AI 技术如何针对这些场景的业务痛点，提供智能化解决方案。同时，阐述为实现这些 AI 应用，社交电商架构在数据层、应用层、基础设施层的升级路径，展现 AI 驱动下社交电商架构从理论到实践的完整升级过程。

开始讲述的电商的发展历程，从电商到社交，在到现在的短视频（忘记名词了），再到电商中 AI 的落地实现

* 以业务问题为导向
* 轻量级起步 + 快速验证
* 利用已有平台能力（无需从零训练模型）

接下来讲述基于电商的实际业务中的 AI 实现，其中包含

* 商品搜索
* 商品转链 - 文字染色，推广文案，文案敏感词检测（风控）
* 内容种草 - 数据洞察，内容创作
* 私域投放 - 流量引入

![image.png](https://blog.liushigong.cn/static/img/48def3e4da1c5892263552626174636d.image.webp)

![image.png](https://blog.liushigong.cn/static/img/594936b22c29604f77dc94beabb44a7f.image.webp)

#### 一些 AI 经验

**深度释放模型CoT能力**

业务问题结构化拆解，将复杂场景转化为“问题链”再通过CoT分步处理。使用提示词模板固定推理框架。

**精准划定AI能力输出边界**

利用传统技术在内容安全、数据隐私、业务合规等方面做兜底方案。特别是在线业业务，通过输出审计便于后期追溯和选代。

**以点带线提升业务短板**

采用高ROI场景切入策略，在问题边界明确、数据的可获得性，收益价值可量化三个方面进行筛选。要考虑能力的复用与价值链的延伸与技术资产沉淀。

#### 目标

AI大模型通过打造基于消费场景的专业化助理、深化用户消费意图的多维度心智解析，以及将商品文案、营销素材等内容生成能力进行标准化封装输出，实现社交电商导购从需求捕捉到内容服务的全链路智能化升级，为商家降低运营成本的同时提升用户消费体验。

**基于消费场景的AI助理**

从“通用服务”到“场景专家。以线带面，基于用户场景，实现用户、商品与服务的连接。

**用户消费意图理解**

借助大模型的理解能力和情感分析能力，实现对用户消费意图的深度洞察。

**内容生成能力优化**

从“零散输出”到“标准化能力”，完成内容从“量”到“质”转变，拒绝制造“内容垃圾”。

#### 总结

闫老师宣讲的内容更多的偏向于业务上的 AI 应用，更多的是让我们有一种产品思维去考虑在电商中如何应用 AI。

### AI 技术赋能从产品设计到交付的效率

这位老师想从自己创业产品作为切入点，结果大多数是个人介绍的经理，唯一干货就是通过 cursor 生成项目代码，要保证代码可控，可以结合原型、UI自主生成代码，等有机会玩一玩，到时候出一篇文章来讲讲，唯一的缺点就是收费，差点意思。