数据库拆分方案

1. 数据库拆分:

①. 分库(垂直拆):
   a. 将用户、商品、订单拆分到不同的库.

②. 分表(水平拆):
   a. 单表超过1亿的数据量了,需要考虑水平拆分了:
      (1). 如uid按照特定的算法,拆分为多张表.数据结构是一样的.

2. 微服务借鉴:

①. 场景:
   a. 商城有用户、商品、交易 、搜索几个功能.
   b. 数据库拆分原理的共性来驱动微服务拆分.

②. 拆分的原则:
   a. 垂直拆分(以业务或API为基准).
   b. 水平拆分(以处理的功能为基准).

(1). 垂直拆分:

①. 业务关系分析:
   a. 用户可以发布和交易商品,是逻辑关系,不是物理关系.
   b. 业务功能垂直拆分,形成多个单体服务(4个服务).

②. 以用户服务来说,垂直拆分力度够不够?
   a. 有注册(写请求)、登录、用户查询(查请求).
   b. 写的重要性肯定大于读,但是写的请求小于读,一般读写比例为10:1.
   c. 如果一个用户只是一个服务,如果读很大了,一定会影响写服务.
   d. 可以按照api再次进一步垂直拆分.
      (1). 写是一个服务、读是一个服务,这就是读写分离.

③. 仅仅是垂直拆分是不够的,因为它只是多个单机,可以形成集群服务.  =>  水平拆分

(2). 水平拆分:

①. 以APP发起一个请求,分析请求生命周期:
   a. 网关服务层:
      (1). 不会做具体的业务逻辑.
      (2). 如通用参数的检查、请求的鉴权、协议转换、路由转换.
   b. 业务逻辑层:
      (1). 进行业务逻辑的处理.
      (2). 如微信的好友拉黑、拒收消息,不需要跟DB打交道.
   c. 数据访问层:
      (1). CURD的功能、屏蔽各种DB的差异性.
   d. DB

②. 总结:
   a. 一层就是一个服务,这样就水平拆分成了网关层、业务逻辑层、数据访问层.
   b. 上面只是同步架构,还有异步架构.
   c. 这几个层都是无状态化的,目的是为了高可用.