# 本地消息表的通用实现-Go版本

**Repository Path**: meoying/local-msg-go

## Basic Information

- **Project Name**: 本地消息表的通用实现-Go版本
- **Description**: No description available
- **Primary Language**: Unknown
- **License**: Not specified
- **Default Branch**: main
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 1
- **Forks**: 0
- **Created**: 2024-11-14
- **Last Updated**: 2024-12-11

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# local-msg-go
通用本地消息表-Go语言实现。

如果你在极客时间购买过大明老师的课程，可以找他要兑换码。[将项目用于面试](https://i.meoying.com/project/detail?id=10)

## 使用注意事项
你必须要先建好本地消息表，或者你也可以考虑依赖 service 来帮你建表。

不要用在生产环境，因为本身我只是用来演示如何设计一个通用的本地消息表解决方案，让你出去面试装逼的，所以它本身未经考验，代码质量和测试覆盖率都不是很好。

## 管理后台部署
你有多重部署形态。这里 admin 指的是管理服务的后台；前端指的是管理服务的前端；

### 和业务一起部署
例如说你有一个 order-service 的微服务，它提供的是微服务接口，那么你可以在这个服务上面额外部署管理后台，在这种情况下，你可以通过 HTTP 接口来访问；

更进一步，你可以把前端也部署起来，这样就可以通过界面来访问；

### admin 和业务一起部署，前端独立部署
也就是前端部署一份，但是后端有多个 admin 服务，然后用前端去访问这些 admin 服务。

一般来说，前端使用域名来访问，而域名则解析为这些 admin 服务，通过 DNS 来实现负载均衡。

### admin 和前端都独立部署
也就是手动部署一个独立的 admin，不和业务混在一起。

## 分库分表
我们整个机制是支持分库分表的，只有一个规则：
**业务数据库和本地消息表必须是同库**

换句话来说就是：
**本地消息表的分库规则必须和业务数据库的分库规则一样**

简单记忆就是：必然同库，可以不同表

现在通过一个例子来让你看清楚这个点。假设说订单的分库规则是 buyer 是偶数就在 order_db_00 上，奇数就在 order_db_01。那么：
- 对于一个 buyer id = 101 的人来说，对应业务的本地消息表一定也在 order_db_01 上
- 对于一个 buyer id = 101 的人来说，数据库是 order_db_01，数据表可以是 order_tab_123，而本地消息表可以是没有分表，是 order_db_01.local_msgs
- 对于一个 buyer id = 101 的人来说，数据库是 order_db_01，数据表可以是 order_tab_123，而本地消息表可以使用另外一种分表规则，例如说 order_db_01.local_msgs_abc