# redundant-table-solutions

**Repository Path**: tong-exists/redundant-table-solutions

## Basic Information

- **Project Name**: redundant-table-solutions
- **Description**: 冗余表的一致性的两类解决方案实战：同步双写、异步写
- **Primary Language**: Java
- **License**: Apache-2.0
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2022-11-22
- **Last Updated**: 2022-11-23

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

#  冗余表
[冗余表系列文章（一）冗余表的实现方案之同步双写](https://blog.csdn.net/2201_75287294/article/details/128000508)

[冗余表系列文章（二）冗余表的实现方案之异步写](https://blog.csdn.net/2201_75287294/article/details/128001250)
## 1.1为什么要有冗余表

当t_order表达到500万条或2GB时需要考虑水平分表，进行水平分表需要根据某个列进行分割，假设根据userId分割。用户查询自己的订单携带着userId，因此能够定位到具体哪张表。而商家查询者自己店铺的订单，没办法确定userId，只能访问一遍所有的分表再合并结果，效率非常低。为了加快商家端的查询，可以冗余一份订单表，这份冗余表根据merchantId切分，商家访问冗余表，效率就很好。这是引入冗余表的好处，坏处是我们要维护普通表和冗余表的数据一致。

## 1.2冗余表的两种实现方案

### 1.2.1    同步双写

![](./图片/同步双写概览.png)

更新t_order的操作要执行两次，一次更新普通表，一次更新冗余表，写两次。
优点：

- 实现简单，由一次写变为两次写

- 容易维护数据的一致性

缺点：

- 代码冗余，第二次写跟第一次写的代码类似，而且每个更新的地方都要写两次

- 请求处理时间变长

### 1.2.2    异步写

![](./图片/异步写概览.png)

更新请求过来，写一次数据库，再发送一条消息到消息中间件，返回响应。消费者拉取消息进行写操作。
优点：

- 处理时间是单次写

缺点

- 较复杂，引入了消息中间件
- 不容易维护数据的一致性