多key业务,数据库水平切分架构一次搞定

简介: 数据库水平切分是一个很有意思的话题,不同业务类型,数据库水平切分的方法不同。本篇将以“订单中心”为例,介绍“多key”类业务,随着数据量的逐步增大,数据库性能显著降低,数据库水平切分相关的架构实践。

数据库水平切分是一个很有意思的话题,不同业务类型,数据库水平切分的方法不同。

本篇将以“订单中心”为例,介绍“多key”类业务,随着数据量的逐步增大,数据库性能显著降低,数据库水平切分相关的架构实践。

一、什么是“多key”类业务

所谓的“多key”,是指一条元数据中,有多个属性上存在前台在线查询需求。

订单中心业务分析

订单中心是一个非常常见的“多key”业务,主要提供订单的查询与修改的服务,其核心元数据为:

Order(oid, buyer_uid, seller_uid, time,money, detail…);

其中:

oid为订单ID,主键

buyer_uid为买家uid

seller_uid为卖家uid

time, money, detail, …等为订单属性

数据库设计上,一般来说在业务初期,单库单表就能够搞定这个需求,典型的架构设计为:

image.png

  • order-center:订单中心服务,对调用者提供友好的RPC接口
  • order-db:对订单进行数据存储

随着订单量的越来越大,数据库需要进行水平切分,由于存在多个key上的查询需求,用哪个字段进行切分,成了需要解决的关键技术问题:

  • 如果用oid来切分,buyer_uid和seller_uid上的查询则需要遍历多库
  • 如果用buyer_uid或seller_uid来切分,其他属性上的查询则需要遍历多库

总之,很难有一个完全之策,在展开技术方案之前,先一起梳理梳理查询需求。

二、订单中心属性查询需求分析
在进行架构讨论之前,先来对业务进行简要分析,看哪些属性上有查询需求。

前台访问,最典型的有三类需求:

  • 订单实体查询:通过oid查询订单实体,90%流量属于这类需求
  • 用户订单列表查询:通过buyer_uid分页查询用户历史订单列表,9%流量属于这类需求
  • 商家订单列表查询:通过seller_uid分页查询商家历史订单列表,1%流量属于这类需求

前台访问的特点:吞吐量大,服务要求高可用,用户对订单的访问一致性要求高,商家对订单的访问一致性要求相对较低,可以接受一定时间的延时。

后台访问,根据产品、运营需求,访问模式各异:

按照时间,架构,商品,详情来进行查询

后台访问的特点:运营侧的查询基本上是批量分页的查询,由于是内部系统,访问量很低,对可用性的要求不高,对一致性的要求也没这么严格,允许秒级甚至十秒级别的查询延时。

这两类不同的业务需求,应该使用什么样的架构方案来解决呢?

三、前台与后台分离的架构设计

如果前台业务和后台业务公用一批服务和一个数据库,有可能导致,由于后台的“少数几个请求”的“批量查询”的“低效”访问,导致数据库的cpu偶尔瞬时100%,影响前台正常用户的访问(例如,订单查询超时)。

image.png

前台与后台访问的查询需求不同,对系统的要求也不一样,故应该两者解耦,实施“前台与后台分离”的架构设计。

前台业务架构不变,站点访问,服务分层,数据库水平切分。

后台业务需求则抽取独立的web/service/db来支持,解除系统之间的耦合,对于“业务复杂”“并发量低”“无需高可用”“能接受一定延时”的后台业务:

  • 可以去掉service层,在运营后台web层通过dao直接访问数据层
  • 可以不需要反向代理,不需要集群冗余
  • 可以通过MQ或者线下异步同步数据,牺牲一些数据的实时性
  • 可以使用更契合大量数据允许接受更高延时的“索引外置”或者“HIVE”的设计方案

解决了后台业务的访问需求,问题转化为,前台的oid,buyer_uid,seller_uid如何来进行数据库水平切分呢?

多个维度的查询较为复杂,对于复杂系统设计,可以逐步简化。

四、假设没有seller_uid

订单中心,假设没有seller_uid上的查询需求,而只有oid和buyer_uid上的查询需求,就蜕化为一个“1对多”的业务场景,对于“1对多”的业务,水平切分应该使用“基因法”。

再次回顾一下,什么是分库基因?

通过buyer_uid分库,假设分为16个库,采用buyer_uid%16的方式来进行数据库路由,所谓的模16,其本质是buyer_uid的最后4个bit决定这行数据落在哪个库上,这4个bit,就是分库基因。

也再次回顾一下,什么是基因法分库?

在订单数据oid生成时,oid末端加入分库基因,让同一个buyer_uid下的所有订单都含有相同基因,落在同一个分库上。

image.png

如上图所示,buyer_uid=666的用户下了一个订单:

  • 使用buyer_uid%16分库,决定这行数据要插入到哪个库中
  • 分库基因是buyer_uid的最后4个bit,即1010
  • 在生成订单标识oid时,先使用一种分布式ID生成算法生成前60bit(上图中绿色部分)
  • 将分库基因加入到oid的最后4个bit(上图中粉色部分),拼装成最终64bit的订单oid(上图中蓝色部分)

通过这种方法保证,同一个用户下的所有订单oid,都落在同一个库上,oid的最后4个bit都相同,于是:

  • 通过buyer_uid%16能够定位到库
  • 通过oid%16也能定位到库

五、假设没有oid

订单中心,假设没有oid上的查询需求,而只有buyer_uid和seller_uid上的查询需求,就蜕化为一个“多对多”的业务场景,对于“多对多”的业务,水平切分应该使用“数据冗余法”。

image.png

如上图所示:

当有订单生成时,通过buyer_uid分库,oid中融入分库基因,写入DB-buyer库

通过线下异步的方式,通过binlog+canal,将数据冗余到DB-seller库中

buyer库通过buyer_uid分库,seller库通过seller_uid分库,前者满足oid和buyer_uid的查询需求,后者满足seller_uid的查询需求

数据冗余的方法有很多种:

  • 服务同步双写
  • 服务异步双写
  • 线下异步双写(上图所示,是线下异步双写)

不管哪种方案,因为两步操作不能保证原子性,总有出现数据不一致的可能,高吞吐分布式事务是业内尚未解决的难题,此时的架构优化方向,并不是完全保证数据的一致,而是尽早的发现不一致,并修复不一致。

最终一致性,是高吞吐互联网业务一致性的常用实践。保证数据最终一致性的方案有三种:

  • 冗余数据全量定时扫描
  • 冗余数据增量日志扫描
  • 冗余数据线上消息实时检测

这些方案细节在“多对多”业务水平拆分的文章里详细展开分析过,便不再赘述。

六、oid/buyer_uid/seller_uid同时存在

通过上述分析:

  • 如果没有seller_uid,“多key”业务会蜕化为“1对多”业务,此时应该使用“基因法”分库:使用buyer_uid分库,在oid中加入分库基因
  • 如果没有oid,“多key”业务会蜕化为“多对多”业务,此时应该使用“数据冗余法”分库:使用buyer_uid和seller_uid来分别分库,冗余数据,满足不同属性上的查询需求
  • 如果oid/buyer_uid/seller_uid同时存在,可以使用上述两种方案的综合方案,来解决“多key”业务的数据库水平切分难题

七、总结

任何复杂难题的解决,都是一个化繁为简,逐步击破的过程。

对于像订单中心一样复杂的“多key”类业务,在数据量较大,需要对数据库进行水平切分时,对于后台需求,采用“前台与后台分离”的架构设计方法:

  • 前台、后台系统web/service/db分离解耦,避免后台低效查询引发前台查询抖动
  • 采用前台与后台数据冗余的设计方式,分别满足两侧的需求
  • 采用“外置索引”(例如ES搜索系统)或者“大数据处理”(例如HIVE)来满足后台变态的查询需求

对于前台需求,化繁为简的设计思路,将“多key”类业务,分解为“1对多”类业务和“多对多”类业务分别解决:

  • 使用“基因法”,解决“1对多”分库需求:使用buyer_uid分库,在oid中加入分库基因,同时满足oid和buyer_uid上的查询需求
  • 使用“数据冗余法”,解决“多对多”分库需求:使用buyer_uid和seller_uid来分别分库,冗余数据,满足buyer_uid和seller_uid上的查询需求
  • 如果oid/buyer_uid/seller_uid同时存在,可以使用上述两种方案的综合方案,来解决“多key”业务的数据库水平切分难题。

数据冗余会带来一致性问题,高吞吐互联网业务,要想完全保证事务一致性很难,常见的实践是最终一致性。

任何脱离业务的架构设计都是耍流氓,共勉。

目录
相关文章
|
3月前
|
NoSQL 关系型数据库 MySQL
微服务架构下的数据库选择:MySQL、PostgreSQL 还是 NoSQL?
在微服务架构中,数据库的选择至关重要。不同类型的数据库适用于不同的需求和场景。在本文章中,我们将深入探讨传统的关系型数据库(如 MySQL 和 PostgreSQL)与现代 NoSQL 数据库的优劣势,并分析在微服务架构下的最佳实践。
|
3月前
|
设计模式 缓存 关系型数据库
探索微服务架构中的数据库设计挑战
微服务架构因其模块化和高扩展性被广泛应用于现代软件开发。然而,这种架构模式也带来了数据库设计上的独特挑战。本文探讨了在微服务架构中实现数据库设计时面临的问题,如数据一致性、服务间的数据共享和分布式事务处理。通过分析实际案例和提出解决方案,旨在为开发人员提供有效的数据库设计策略,以应对微服务架构下的复杂性。
|
3月前
|
消息中间件 缓存 监控
优化微服务架构中的数据库访问:策略与最佳实践
在微服务架构中,数据库访问的效率直接影响到系统的性能和可扩展性。本文探讨了优化微服务架构中数据库访问的策略与最佳实践,包括数据分片、缓存策略、异步处理和服务间通信优化。通过具体的技术方案和实例分析,提供了一系列实用的建议,以帮助开发团队提升微服务系统的响应速度和稳定性。
|
1月前
|
存储 SQL Apache
Apache Doris 开源最顶级基于MPP架构的高性能实时分析数据库
Apache Doris 是一个基于 MPP 架构的高性能实时分析数据库,以其极高的速度和易用性著称。它支持高并发点查询和复杂分析场景,适用于报表分析、即席查询、数据仓库和数据湖查询加速等。最新发布的 2.0.2 版本在性能、稳定性和多租户支持方面有显著提升。社区活跃,已广泛应用于电商、广告、用户行为分析等领域。
Apache Doris 开源最顶级基于MPP架构的高性能实时分析数据库
|
1月前
|
缓存 关系型数据库 MySQL
高并发架构系列:数据库主从同步的 3 种方案
本文详解高并发场景下数据库主从同步的三种解决方案:数据主从同步、数据库半同步复制、数据库中间件同步和缓存记录写key同步,旨在帮助解决数据一致性问题。关注【mikechen的互联网架构】,10年+BAT架构经验倾囊相授。
高并发架构系列:数据库主从同步的 3 种方案
|
1月前
|
存储 NoSQL 分布式数据库
微服务架构下的数据库设计与优化策略####
本文深入探讨了在微服务架构下,如何进行高效的数据库设计与优化,以确保系统的可扩展性、低延迟与高并发处理能力。不同于传统单一数据库模式,微服务架构要求更细粒度的服务划分,这对数据库设计提出了新的挑战。本文将从数据库分片、复制、事务管理及性能调优等方面阐述最佳实践,旨在为开发者提供一套系统性的解决方案框架。 ####
|
1月前
|
消息中间件 数据库 云计算
微服务架构下的数据库事务管理策略####
在微服务架构中,传统的单体应用被拆分为多个独立的服务单元,每个服务维护自己的数据库实例。这种设计提高了系统的可扩展性和灵活性,但同时也带来了分布式环境下事务管理的复杂性。本文探讨了微服务架构下数据库事务的挑战,并深入分析了几种主流的事务管理策略,包括Saga模式、两阶段提交(2PC)以及基于消息的最终一致性方案,旨在为开发者提供一套适应不同业务场景的事务处理框架。 ####
|
1月前
|
存储 Cloud Native NoSQL
云原生时代的数据库选型与架构设计
云原生时代的数据库选型与架构设计
25 0
|
1月前
|
设计模式 存储 缓存
微服务架构下的数据库设计策略
本文探讨了在微服务架构中进行数据库设计时,如何平衡数据的一致性、独立性与系统整体性能之间的关系。文章首先介绍了微服务架构的基本概念及其对数据库设计的影响,随后深入分析了三种主流的数据库设计模式——集中式、去中心化和混合模式,并结合实际案例讨论了它们的适用场景与优缺点。此外,还提出了一系列最佳实践建议,旨在帮助开发者更好地应对微服务环境下的数据管理挑战。
|
3月前
|
消息中间件 缓存 监控
优化微服务架构中的数据库访问:策略与实践
随着微服务架构的普及,如何高效管理和优化数据库访问成为了关键挑战。本文探讨了在微服务环境中优化数据库访问的策略,包括数据库分片、缓存机制、异步处理等技术手段。通过深入分析实际案例和最佳实践,本文旨在为开发者提供实际可行的解决方案,以提升系统性能和可扩展性。