local-msg-go

通用本地消息表-Go语言实现。

如果你在极客时间购买过大明老师的课程，可以找他要兑换码。将项目用于面试

使用注意事项

你必须要先建好本地消息表，或者你也可以考虑依赖 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