基于DTS+Tablestore的海量订单系统架构设计

本文涉及的产品
对象存储 OSS,20GB 3个月
对象存储 OSS,恶意文件检测 1000次 1年
对象存储 OSS,内容安全 1000次 1年
简介: DTS支持MySQL同步Tablestore Beta版上线,合力打造完善的订单系统。本文主要介绍一套基于DTS与Tablestore实现一套完善的订单系统架构。实时订单数据主要针对用户侧的实时生产与修改,实例订单数据则是基于数据同步服务DTS,全、增量订阅TP库中的订单数据,从而保证Tablestore中数据与TP库数据的最终一致性。异步同步的方式不可避免的存在延时,但历史订单库在实时性上要求会适当放宽,但其派生出来的数据在服务能力与功能扩展上得到了极大的提升,尤其是Tablestore这种分布式服务能力强、下游计算生态丰富的NoSQL存储服务。

订单系统概述

订单场景是人们高频接触的一类场景,无论是线下商场购物、吃喝玩乐消费,还是线上淘宝、会员充值、外卖预定。只要涉及人就会有交易,只要有交易就会产生订单。毫不夸张的讲,所有的应用都会涉及到支付与订单的管理,因此,完善的订单管理架构是每一个架构师或开发人员都要直面的挑战。

对于订单系统,保证事务与强一致是前提,架构师们通常都会选择MySQL等TP型数据库。但是遇到大规模数据场景下也不得不面临一定的问题。首先,需要通过分库分表等方式提供一个分布式能力提升数据库数据存储、吞吐量,其次数据量大对于查询与聚合等需求难以支持,严重会影响表服务能力与性能。但是在大规模数据下,订单的多维检索、订单分析、以及周期性报表等需求,也是不能够舍弃的。因此需要一个历史订单库,将订单数据派生到其他存储引擎,从而拓展数据的查询、分析、聚合等能力。

这时,用户会考虑数据双写、数据同步等方式将数据派生一份到搜索引擎或其他NoSQL分布式数据存储,来扩展MySQL性能成本非常高的使用场景。多写的方案一般很少,这对写入一致性项目运维成本与写入性能会有很大的挑战。当前,更被大众所接受的是基于TP数据库的binlog订阅做数据同步,虽然数据同步上会有延时(通常秒级别甚至更低),但是在运维成本、能力扩展、数据一致性上表现优异。

DTS+Tablestore方案

本文主要介绍一套基于DTS与Tablestore实现一套完善的订单系统架构。实时订单数据主要针对用户侧的实时生产与修改,实例订单数据则是基于数据同步服务DTS,全、增量订阅TP库中的订单数据,从而保证Tablestore中数据与TP库数据的最终一致性。异步同步的方式不可避免的存在延时,但历史订单库在实时性上要求会适当放宽,但其派生出来的数据在服务能力与功能扩展上得到了极大的提升,尤其是Tablestore这种分布式服务能力强、下游计算生态丰富的NoSQL存储服务。

系统架构设计

系统架构如下图,架构基于订单数据的使用功能与实时性分两部分:实时在线订单数据与历史订单数据。

  • • 在线订单数据:存储在TP型数据库,如MySQL、PolarDB等,用于保证订单的强事务能力;
  • • 历史订单数据:存储在Tablestore,分布式存储,支持多维检索与聚合能力,拥有完善的大数据生态;
  • • 同步链路:DTS(数据传输服务),支持全量数据迁移与实时数据同步,实时同步延时秒级别;
    image.png

Tablestore的能力与生态

Tablestore的服务性能、分析查询能力以及下游生态,值得着重强调,丰富的能力扩展正是数据派生的核心价值。这里主要展示多元索引、大数据生态两个亮点,更多Tablestore场景与功能,请参考《表格存储Tablestore权威指南》

  • • 多元索引:
    基于倒排索引和列式存储,可以解决大数据的复杂查询难题,包括非主键列查询、全文检索、前缀查询、模糊查询、多字段自由组合查询、嵌套查询、地理位置查询等功能。适用于元数据管理、历史订单维护、地理围栏等场景。

深入了解多元索引:多元索引官网文档、《TableStore发布多元索引功能,打造统一的在线数据平台》

  • • 大数据架构
    Tablestore 作为一款高性能低成本的存储引擎,海量的数据存储伴随的就是大数据生态对接,并已经形成了一套稳定、高性能的大数据架构,产品在核心功能的升级迭代的过程中,也不断的加强计算引擎对接,目前已经对接了阿里云几个核心计算引擎,包含:MaxCompute、EMR Spark、Blink、DLA 、FC,更总结出一套流批一体处理框架(Lambda plus)。

深入了解数据中台、大数据体系:《数据中台之结构化大数据存储设计》、《基于 Tablestore 的大数据分析 Lambda 架构 - 云原生、弹性、流批一体》
架构搭建实战

准备工作

1、服务准备

  • • 开通RDS服务:并购买MySQL实例,此处不做详细介绍,可参考《文档》;
  • • 开通Tablestore服务:创建实例(免费),不做详细介绍,可参考《文档》;
  • • 开通DTS服务:并购买MySQL同步Tablestore实例
    目前仅上线MySQL、PolarDB到Tablestore,其中PolarDb需要主动开启binlog开关才能支持增量同步。Tablestore暂时开发上海、北京、深圳,本例使用上海实例。

image.png

2、资源准备

创建子账号AccessKey

并对子账号实例级别授权,权限为操作Tablestore资源权限,让DTS有权限操作用户该实例资源(注意region跟实例名)

  • • 创建子账号
    image.png
  • • Tablestore实例授权
{
    "Version": "1",
    "Statement": [
        {
            "Action": "ots:*",
            "Resource": "acs:ots:[myInstanceRegion]:*:instance/[myInstanceName]/*",
            "Effect": "Allow"
        },
        {
            "Action": [
                "ots:ListInstance",
                "ots:GetInstance"
            ],
            "Resource": "*",
            "Effect": "Allow"
        }
    ]
}

建表语句

/******************************************/
/*   DatabaseName = dts_demo   */
/*   TableName = order_contract   */
/******************************************/
CREATE TABLE `order_contract` (
  `oId` varchar(20) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL COMMENT '订单id',
  `createTime` datetime NOT NULL COMMENT '下单时间',
  `payTime` datetime DEFAULT NULL COMMENT '支付时间',
  `hasPaid` tinyint(1) NOT NULL COMMENT '是否支付',
  `cId` varchar(20) NOT NULL COMMENT '消费者id',
  `cName` varchar(20) NOT NULL COMMENT '消费者姓名',
  `pBrand` tinytext NOT NULL COMMENT '产品品牌',
  `pCount` mediumint(10) NOT NULL COMMENT '产品数量',
  `pId` varchar(20) NOT NULL COMMENT '产品id',
  `pName` varchar(20) NOT NULL COMMENT '产品名',
  `pPrice` decimal(10,2) NOT NULL COMMENT '产品价格',
  `sId` varchar(20) NOT NULL COMMENT '售货员id',
  `sName` varchar(20) NOT NULL COMMENT '售货员姓名',
  `totalPrice` decimal(10,2) NOT NULL COMMENT '总价格',
  PRIMARY KEY (`oId`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='在线订单表';

用户下单

直接通过sql写入,模拟用户下单与应用订单数据写入

INSERT INTO order_contract (oId, payTime, createTime, hasPaid, cId, cName, pBrand, pCount, pId, pName, pPrice, sId, sName, totalPrice)
VALUES 
("00000001", null, "2020-08-05 11:11:11", false, "c00001", "消费者1", "iphone", 1, "p00001", "iphone 7 plus",  9999.80, "s00001", "售货员1", 9999.80),
("00000002", null, "2020-08-05 12:11:11", false, "c00001", "消费者1", "iphone", 1, "p00002", "iphone 8 plus",  10999.80, "s00001", "售货员1", 10999.80),
("00000003", null, "2020-08-05 13:11:11", false, "c00002", "消费者2", "小米", 2, "p00010", "小米 7 plus",  999.81, "s00001", "售货员1", 1999.62);

同步配置

  • • 配置DTS实例
    image.png
  • • 配置目标、源配置
    image.png
  • • 配置同步表、字段与类型转换
    image.png

字段类型映射不建议全部选用默认,根据需求做定制,其中Boolean在MySQL中表现为tinyint(1),需要主动设置成Boolean,时间默认使用String如需转换为时间戳,目标类型主动配置成Integer类型。
image.png

启动任务

启动并进入预检

image.png
image.png

预检完成会自动进入结构迁移(初始化建表)、全量迁移、增量同步阶段。然后用户可以基于DTS控制台查看结构迁移与同步状态。

目标检查

结构迁移

结构迁移完成,Tablestore实例下表初始化成功,主键符合预期
image.png

存量数据

进入存量阶段,开始同步MySQL库已有数据,同步成功后目标库数据可见。
image.png

增量校验

使用样例中的SQL模拟下单、更新订单、删除订单等操作,观察Tablestore实例中表的数据变化

下单

INSERT INTO order_contract (oId, payTime, createTime, hasPaid, cId, cName, pBrand, pCount, pId, pName, pPrice, sId, sName, totalPrice)
VALUES ("00000004", null, "2020-08-05 11:11:11", false, "c00003", "消费者3", "iphone", 1, "p00001", "iphone 7 plus",  9999.80, "s00001", "售货员1", 9999.80);

支付修改订单状态

update order_contract set payTime = "2020-08-05 21:11:11", hasPaid = true WHERE oId = "00000004";

删除数据

DELETE FROM order_contract WHERE oId = "00000004";

扩展能力

多元索引聚合查询

多元索引对于历史订单的管理,我们曾给出过最佳实践,用户可以参考《基于Tablestore打造亿量级订单管理解决方案》与控制台样例了解功能使用的详细方案。您只需在Tablestore相应的表中直接创建多元索引,便可完成历史订单数据的多条件组合查询、模糊查询、地理位置查询、存在性查询、简单的统计聚合与分析等。通过对产品名做分词,支持模糊查询能力,实例中查询"iphone"关键字,会从全量订单数据中检索出相应的2行数据。
image.png

多元索引的订单实战样例,可以参考文章《基于Tablestore打造亿量级订单管理解决方案》,并提供了直观感受的demo样例,如下图。用户可以参考借鉴。

image.png

除了多维组合查询,多元索引还是统计、聚合的能力,该能力没有在控制台上暴露,需要通过sdk使用,这里暂不距离,具体使用,可以参考《文档:多元索引的统计聚合》。
使用统计聚合功能可以实现求最小值、求最大值、求和、求平均值、统计行数、去重统计行数、按字段值分组、按范围分组、按地理位置分组、按过滤条件分组、嵌套查询等;同时多个统计聚合功能可以组合使用,满足复杂的查询需求。

流批一体的电商大屏

订单对于电商场景的最根本数据源,如何让海量的订单数据易分析、易可视化是场景的重要需求点,电商大屏或周期交易报表是最直接的数据价值挖掘的方式。这里以大屏为例,大屏可以包含全量订单、实时订单的聚合,全量订单的聚合提供的是全景的综合数据视图,而实时订单的聚合展示的是实时的运营指标数据。
谈完流批计算对数据价值挖掘的作用,就要见一下实现。Tablestore已经拥有较多的实战案例与架构文章,这里不做重复输出,用户可以直接前往文章《Tablestore结合Spark的流批一体SQL实战》,了解构建方案与效果。大屏效果如下图。
image.png

免费专家服务

欢迎加入Tablestore社区了解产品或参与讨论,更多文章欢迎前往《表格存储Tablestore权威指南》。
表格存储 (Tablestore) 提供专业的免费的技术咨询服务,期待您的加入。群号 : 23307953
image.png

相关实践学习
阿里云表格存储使用教程
表格存储(Table Store)是构建在阿里云飞天分布式系统之上的分布式NoSQL数据存储服务,根据99.99%的高可用以及11个9的数据可靠性的标准设计。表格存储通过数据分片和负载均衡技术,实现数据规模与访问并发上的无缝扩展,提供海量结构化数据的存储和实时访问。 产品详情:https://www.aliyun.com/product/ots
目录
相关文章
|
存储 SQL 运维
基于Tablestore 实现大规模订单系统海量订单/日志数据分类存储的实践
前言:从最早的互联网高速发展、到移动互联网的爆发式增长,再到今天的产业互联网、物联网的快速崛起,各种各样新应用、新系统产生了众多订单类型的需求,比如电商购物订单、银行流水、运营商话费账单、外卖订单、设备信息等,产生的数据种类和数据量越来越多;其中订单系统就是一个非常广泛、通用的系统。而随着数据规模的快速增长、大数据技术的发展、运营水平的不断提高,包括数据消费的能力要求越来越高,这对支撑订单系统的数据库设计、存储系统也提出了更多的要求。在新的需求下,传统的经典架构面临着诸多挑战,需要进一步思考架构优化,以更好支撑业务发展;
671 0
基于Tablestore 实现大规模订单系统海量订单/日志数据分类存储的实践
|
存储 SQL 运维
基于 MySQL + Tablestore 分层存储架构的大规模订单系统实践-架构篇
本文简要介绍了基于 MySQL 结合 Tablestore 的大规模订单系统方案。这种方案支持大数据存储、高性能数据检索、SQL搜索、实时与全量数据分析,且部署简单、运维成本低。
基于 MySQL + Tablestore 分层存储架构的大规模订单系统实践-架构篇
|
存储 SQL 运维
基于 MySQL + Tablestore 分层存储架构的大规模订单系统实践-架构篇
背景订单系统存在于各行各业,如电商订单、银行流水、运营商话费账单等,是一个非常广泛、通用的系统。对于这类系统,在过去十几年发展中已经形成了经典的做法。但是随着互联网的发展,以及各企业对数据的重视,需要存储和持久化的订单量越来越大,数据的重视程度与数据规模的膨胀带来了新的挑战。首先,订单量对于数据的存储、持久化、访问带来了挑战,这不仅增加了开发面对的困难,也为系统的运维带来了挑战。其次,随着大数据技
2350 0
基于 MySQL + Tablestore 分层存储架构的大规模订单系统实践-架构篇
|
canal 存储 SQL
基于 MySQL + Tablestore 分层存储架构的大规模订单系统实践-数据同步 DTS 篇
前言 前文架构篇,可以看到 MySQL + Tablestore 非常适合大规模订单系统这一类需求场景。那么,我们首先要做的是,利用 CDC(Change Data Capture) 技术将订单数据实时从 MySQL 同步到 Tablestore 中。对于订单系统的数据同步,我们需要关注同步的稳定性、实时性。目前,存在多款工具可以实现这一功能,他们有的是开源工具如 Canal,有的是阿里云端服务如
974 0
基于 MySQL + Tablestore 分层存储架构的大规模订单系统实践-数据同步 DTS 篇
|
canal 弹性计算 监控
基于 MySQL + Tablestore 分层存储架构的大规模订单系统实践-数据同步 Canal 篇
前言 在基于 MySQL + Tablestore 分层存储架构的大规模订单系统中,利用 CDC 技术将 MySQL 数据同步到 Tablestore 是不可缺少的一步。前文已经详细讲述了如何使用 DTS 向 Tablestore 同步数据。对于中小规模的数据库,或者个人开发者,还可以使用 Canal 从 MySQL 向 Tablestore 同步数据。Canal 部署简单,易于运维,且相比于 D
623 0
基于 MySQL + Tablestore 分层存储架构的大规模订单系统实践-数据同步 Canal 篇
|
存储 SQL 运维
基于 MySQL + Tablestore 分层存储架构的大规模订单系统实践-订单搜索篇
背景在大规模订单系统中,存在以下常见需求:查询某店铺过去一段时间成交额查询某品牌商品在过去一周内的成交额查询在某店铺购物的客户列表……因此,开发者对于数据库在非主键查询、多列的自由组合查询等复杂查询需求上会有比较高的要求。传统的订单系统会使用 Elasticsearch 或者 Solr 来实现这一需求,但伴随而来的是更高的系统复杂度和更加昂贵的系统维护成本。Tablestore 的多元索引,能够支
908 0
基于 MySQL + Tablestore 分层存储架构的大规模订单系统实践-订单搜索篇
|
SQL 存储 NoSQL
基于 MySQL + Tablestore 分层存储架构的大规模订单系统实践-SQL 查询和分析
前言前面我们介绍了基于 MySQL + Tablestore 分层架构的订单系统。订单数据储存进入 Tablestore 后,用户可以使用 SDK 中的 API 访问数据,也可以继续使用 SQL 访问 Tablestore 中的数据。Tablestore 提供了多种 SQL 的接入方式,客户可以通过 DLA 访问 Tablestore,也可以利用 Tablestore 自身对 SQL 的支持能力,
854 0
基于 MySQL + Tablestore 分层存储架构的大规模订单系统实践-SQL 查询和分析
|
存储 SQL 运维
基于 MySQL + Tablestore 分层存储架构的大规模订单系统实践-基于 DLA 的联邦查询
前言在订单系统中,基于订单数据对客户和商家商品进行画像分析是一种常见的需求。常见的分析需求有:基于主键、分区键数据的条件组合检索,例如获取某用户最近 30 的订单列表。根据非主键列、分区键的条件组合检索工作,例如查询过去一天异常订单列表、查询过去一天成交额最大的10 笔订单。聚合统计类需求,比如统计某店铺过去一个月各商品销售额排名;统计双十一期间销售额前 10 的店铺;统计双十一期间某店铺每天订单
533 0
基于 MySQL + Tablestore 分层存储架构的大规模订单系统实践-基于 DLA 的联邦查询
|
存储 SQL 分布式计算
基于 MySQL + Tablestore 分层存储架构的大规模订单系统实践-数据处理ETL篇
前言大数据计算服务 MaxCompute(原名 ODPS)是一种快速、完全托管的EB级数据仓库解决方案。随着数据收集手段不断丰富,行业数据大量积累,数据规模已增长到了传统软件行业无法承载的海量数据(TB、PB、EB)级别。MaxCompute 致力于批量结构化数据的存储和计算,提供海量数据仓库的解决方案及分析建模服务。它具有大规模计算存储、多种计算模型、强数据安全、低成本、免运维、极致弹性扩展的优
495 0
基于 MySQL + Tablestore 分层存储架构的大规模订单系统实践-数据处理ETL篇
|
存储 SQL 运维
基于 MySQL + Tablestore 分层存储架构的大规模订单系统实践-历史数据分析篇
前言在大规模订单系统中,离线的数据分析必不可少。工程师和运营人员使用批处理工具如 Spark 对历史数据进行计算分析,其计算结果可以用于用户画像、产品推荐等多个场景。传统的 MySQL 分库分表架构是无法应对这种需求的,一般会引入 Hive 对数据进行归档存储,然后利用 Hive 来对接 Spark 或者 HiveSQL 等分析工具。这样的架构会带来很高的维护成本,首先 Hive、HDFS、Had
609 0
基于 MySQL + Tablestore 分层存储架构的大规模订单系统实践-历史数据分析篇