分库分表:订单中心,多key业务如何进行数据库切分

订单中心数据查询需求分析

还是那句话,任何脱离业务的架构设计都是耍流氓,在进行架构讨论之前,首先要对业务进行简要分析,看看表结构上有哪些查询需求。

    根据业务经验,订单中心往往有以下几类业务需求:

(1)用户侧,前台访问,最典型的有三类需求

订单实体查询:通过oid查询订单实体,90%都是这种需求。

用户订单列表查询:通过buyer_id分页查询用户历史订单列表,9%流量属于这种需求。

商家订单列表查询:通过seller_uid分页查询商家历史订单列表,1%流量属于这类需求。          

前台访问的特点是:吞吐量大,服务要求高可用,对一致性要求较高。其中商家对一致性要求较低,可以接受一定程度的延迟。

(2)运营侧,后台访问。

根据产品、运营需求,访问模式各异:按照时间,架构,商品和详情来进行查询

后台访问的特点:运营侧的查询基本上是批量的分页查询,访问量低,对可用性一致性的要求不高,允许秒甚至十秒级别的查询延迟。

订单中心数据查询需求解决方案-运营侧

后台运营侧的查询需求各异,基本是批量的分页查询,计算量和返回数据量较大,比较消耗数据库性能。

此时如果后台业务和前台业务共用一批服务和同一个数据库。有可能会导致后台少数几个请求的批量查询的低效访问造成数据库服务器cpu瞬时100%,影响前台用户的正常访问。

对这一类业务,应该采用“前后台分离”的架构方案:前台业务架构不变,站点访问,服务分层,数据库水平切分

 

订单中心数据查询需求解决方案-用户侧

明确了订单中心的访问需求后,问题转化为,前台的oid,buyer_id,seller_id如何来进行数据库的水平切分呢?

需要同时满足以下条件:

1.根据buyer_uid%n,可以定位到数据库

2.根据oid%n,可以定位到数据库

3.根据seller_uid%n,可以定位到数据库

以上业务是一个

  • 1:N(1个买家:N个订单)
  • N:N(1个买家:N个卖家, 1个卖家:N个买家)的业务场景,
  • 对于“多对多”的业务,水平切分应该使用“数据冗余法”

订单中心数据库切分方法--数据冗余法


     • 当有订单生成时,通过buyer_uid分库,oid中融入分库基因,写入DB-buyer库
     • 通过线下异步的方式,通过binlog+canal,将数据冗余到DB-seller库中
     • buyer库通过buyer_uid分库,seller库通过seller_uid分库,前者满足oid和buyer_uid的查询需求,后者满足seller_uid的查询需求

为什么要冗余数据?

互联网数据量很大的业务场景,往往数据库需要进行水平切分来降低单库数据量。

水平切分会有一个patitionkey,通过patition key的查询能够直接定位到库,但是非patitionkey上的查询可能就需要扫描多个库了。

此时常见的架构设计方案,是使用数据冗余这种反范式设计来满足分库后不同维度的查询需求。

  • 例如:订单业务,对用户和商家都有订单查询需求:

Order(oid,info_detail);

T(buyer_uid,seller_uid,oid);

如果用buyer_uid来分库,seller_uid的查询就需要扫描多库。

如果用seller_uid来分库,buyer_uid的查询就需要扫描多库。

此时可以使用数据冗余来分别满足buyer_uid和seller_uid上的查询需求:

T1(buyer_uid,seller_uid,oid)

T2(seller_uid,buyer_uid,oid)

同一个数据,冗余两份,一份以buyer_uid来分库,满足买家的查询需求;一份以seller_uid来分库,满足卖家的查询需求。

订单中心数据库切分方法|如何实现数据冗余

 

1.服务同步双写

  服务同步双写,即由服务层同步写冗余数据。

   流程如图:

   (1)业务应用代用服务层,写入数据

   (2)服务层将数据写入DB1

   (3)服务层将数据写入DB2

   (4)服务层返回新增数据成功给业务应用

  • 优点:
  1. 简单,服务层由单写,改为两次写人
  2. 数据一致性较高,双写成功后才返回
  • 缺点:
  1. 因为由单写变为了两次写入,请求时间增长
  2. 数据仍有可能不一致(数据写入DB1后,服务宕机或重启,则数据无法写人DB2)


2.线下异步双写

为了屏蔽“复杂性”,数据双写由线下服务或者任务来完成,不再由服务层完成。

流程如图:

 

   (1)业务应用代用服务层,写入数据

   (2)服务层将数据写入DB1

   (3)服务层返回新增数据成功给业务应用

   (4)数据会被写入到数据库的log中

   (5)线下服务或者任务读取数据库log

   (6)线下服务或者任务插入T2数据

  • 优点:
  1. 数据双写与业务完全解耦
  2. 请求处理时间短
  • 缺点:
  1. 返回业务新增成功时,会存在一个数据不一致的时间窗口,但能保证最终一致性
  2. 数据一致性依赖于线下服务或者任务的可凹陷


原文:https://blog.csdn.net/sunhuiliang85/article/details/78418546 

参考:https://blog.csdn.net/qq_18145031/article/details/77867853

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章