1背景订单系统存在于各行各业，电商订单、银行对账单、话务员话费等，是一个非常广泛而通用的系统。对于这类制度，在过去十年的发展过程中，已经形成了经典的做法。但是，随着互联网的发展和各企业对数据的重视，需要存储和持久化的订单量越来越大。数据的重要性和数据规模的扩大带来了新的挑战。首先，订单量大给数据存储、持久化、访问带来挑战，不仅增加了开发面临的难度，也给系统运维带来了挑战。其次，随着大数据技术的发展和运营水平的不断提升，流批处理、ETL等订单数据的后续数据分析越来越重要，这也对数据提出了更高的要求存储系统。本文提出了一种基于MySQL+Tablestore的大型订单系统设计方案。本方案基于分层存储的思想，利用Tablestore辅助MySQL共同完成订单系统支持。在系统中，利用MySQL的事务能力来处理需要强事务的写操作和部分读操作；利用Tablestore的检索能力和大数据存储能力来弥补MySQL的功能短板。详见文章：云应用系统数据存储架构的演进。本文作为MySQL+Tablestore分层存储架构的大型订单系统的架构。首先阐述一下大单系统存在哪些需求和痛点。然后对比一下传统的架构，它的现状是什么，各自的缺点是什么，不能满足什么需求。然后描述MySQL+Tablestore的架构，并说明这种架构如何满足大规模订单系统的需求。2需求场景订单系统面向C端。除了对系统性能要求高外，对数据存储、后续数据计算、实时数据处理、数据批处理等也有一定的要求。对于C端客户、产品运营、系统运维等不同角色，他们对系统的要求也不同。1C端需求对于C端客户和C端开发，系统首先需要支持高并发和高稳定性。其次，系统需要能够支持基于userid的搜索，可以搜索某个userid下包含特定关键词的记录。具体需求是：根据用户id查找用户近一个月的订单。根据订单号查询订单详情。搜索包含用户购买的关键字的产品。这对系统的索引和搜索能力有很高的要求。2操作要求操作类同学需要能够在不影响线上情况的情况下使用SQL分析实时数据，能够按照非主键字段进行检索；流批计算也需要系统支持，实时数据统计需要流数据处理，历史数据统计需要批处理。运维同学常见的需求场景包括：某旗舰店消费过的用户统计。统计消费过某种产品的客户，购买过哪些产品，然后向客户推荐产品。实时统计双十一开始后的实时成交额，用于宣传时的实时数据展示。过去10年一家店铺的营业额统计。依托订单数据做实时更新的客户画像分析，支持产品推荐。3运维要求运维同学更关注系统的稳定性和复杂性，期望运维成本低。基于MySQL+Tablestore的订单系统，可以将运维同学从繁琐的运维工作中解放出来，大大降低运维成本。可以实现：系统高可用，并发能力强。系统复杂度低，无需维护多个集群，无需关注集群间的数据同步过程。操作维护工作简单，使用方便。三种传统订单系统1订单系统架构演进最简单的订单系统是单点MySQL架构，但是随着订单规模的增长，用户开始使用分库分表的MySQL来替代单点MySQL方案。但是在这种方案下，当数据量达到当前MySQL集群的瓶颈时，集群扩容还是会相当困难，需要更大的集群和大量的数据迁移。数据迭代和扩容带来的麻烦对于分库分表的MySQL方案来说是无法克服的。NoSQL被引入，MySQL+HBase的方案应运而生。该解决方案将实时数据和历史数据分层存储。MySQL只存储实时数据，历史数据归档到HBase存储。该方案解决了数据膨胀带来的存储和运维问题，但缺点是存储在HBase中的数据难以合理使用，且方案整体不支持检索功能。于是在架构中引入了Elasticsearch，形成了MySQL+HBase+Elasticsearch的解决方案。本方案利用Elasticsearch提供的数据检索能力解决订单数据的搜索问题。但是在这种架构下，用户需要维护HBase和Elasticsearch这两个集群，还需要注意与HBase和Elasticsearch同步数据的任务，维护成本非常高。而且这种架构还不能支持流批处理、ETL等数据分析处理。MySQL分库分表方案MySQL本身具有强大的数据查询和分析功能。基于MySQL，可以创建订单系统，处理订单数据的多维查询和统计场景。随着订单数据量的增加，用户会采用分库分表的方案来处理。通过这种伪分布式方案，可以解决数据膨胀带来的问题。但一旦数据达到瓶颈，需要重新创建更大的分库+全量数据迁移，麻烦就会不断出现。数据迭代和扩展带来的麻烦是MySQL解决方案无法克服的。传统订单方案仅依赖MySQL的缺点凸显。1、数据垂直（数据规模）扩展：MySQL采用分库分表方案，部署时需要预估分库规模。一旦数据量达到上限，重新部署并进行全量数据迁移；2.数据横向（字段维度）扩展：需要预定义schema，迭代添加新字段复杂。当维度达到一定数量时，会影响数据库的性能；数据扩容也会增加系统运维的难度和成本。另外，MySQL集群一般采用双策略扩容。在存储量大、计算量少的场景下，CPU的浪费会很严重。引入双数据的MySQL+HBase解决方案应运而生。通过实时数据和历史数据存储的解决方案，可以在一定程度上解决数据量膨胀的问题。该方案将数据分为两部分进行存储：实时数据和历史数据。同时通过数据同步服务，将过期数据同步到历史数据中。1、实时订单数据（例如：近3个月的订单）：将实时订单存储在MySQL数据库中。实时订单总量扩展速度有限，同时保证实时数据的多维度查询分析能力；2、历史订单数据（例如：3个月前的订单）：将历史订单数据存储在HBase中，借助分布式NoSQL数据库HBase，有效应对订单数据膨胀的问题。也保证了历史订单数据的持久化；但是，该方案牺牲了历史订单数据对用户、商户、平台的使用价值，并假设对历史数据的需求频率极低。但是一旦有需求，需要进行全表扫描，查询速度慢，IO成本高。保持数据同步带来了数据一致性、同步运维成本飙升等问题；MySQL+HBase+Elasticsearch解决方案MySQL+HBase+Elasticsearch解决方案引入Elasticsearch集群解决其他解决方案无法应对的数据检索问题。1、实时订单数据（例如：近3个月的订单）：将实时订单存储在MySQL数据库中。实时订单总量扩展速度有限，同时保证实时数据的多维度查询分析能力；2、历史订单数据（例如：3个月前的订单）：将历史订单数据存储在HBase中，借助分布式NoSQL数据库HBase，有效应对订单数据膨胀的问题。也保证了历史订单数据的持久化；3、数据检索：数据同步任务将需要检索的字段从HBase同步到Elasticsearch，借助Elasticsearch的索引能力为系统提供数据检索能力。必要时再查看MySQL获取完整的订单信息；该方案虽然解决了数据扩容带来的扩容问题，但也可以支持数据检索。但可以看出，客户至少需要维护两套集群，专注于两个数据同步任务。这种方案的系统复杂度很高，运维成本也会很高。另外，该方案还不能提供对数据的流批处理和数据ETL再处理的支持。2传统订单结构总结总之，MySQL分库分表方案无法解决数据膨胀带来的膨胀问题。基于MySQL+HBase的架构在数据检索上存在明显的短板。MySQL+HBase+Elasticsearch的方案，虽然可以解决扩容和数据检索的问题，但是系统复杂，维护成本高；此外，该解决方案无法为数据分析和数据再处理ETL工作提供有效支持。MySQL+Tablestore不仅解决了扩容和检索的问题，还支持数据流批处理和ETL再处理，系统复杂度低，运维成本低，可以满足大规模订单系统的各种需求。4.MySQL+Tablestore解决方案Tablestore（Tablestore）是阿里云自研的多模型结构化数据存储，提供海量结构化数据存储和快速查询分析服务。MySQL+Tablestore之后，可以很好的满足大规模订单场景中遇到的各种需求。其整体结构图如图所示。MySQL处理订单的写入和近期数据的基础读取，并使用DTS等数据同步工具将数据实时同步到Tablestore。在Tablestore中，利用它的二级索引和多索引，可以处理检索需求。通过DLA，可以直接使用SQL查询Tablestore。Tablestore的Channel服务可以对接SparkStreaming和Flink，实现实时数据分析。通过对接Tablestore和ODPS，可以轻松实现对订单数据的ETL操作。结合OSS和Tablestore，可以实现订单数据的归档，在OSS中可以实现历史数据的全量分析。1数据同步在传统的订单架构中，开发者不可避免的需要处理数据同步到HBase或者Elasticsearch中。这不仅增加了开发者的开发工作，也增加了运维的难度。在Tablestore方面，阿里云提供了DataX、DataTransmissionService（DTS）、Canal等多种数据同步工具来完成MySQL到Tablestore的数据同步。用户只需做少量的开发和配置工作，即可完成实时数据同步。操作方便简单，实时性高，维护成本大大降低。2.数据检索Tablestore提供二级索引和多索引支持数据检索。二级索引可以完成基于主键列和预定义列的数据查询，比如查询用户近一个月的订单状态。多元素索引，在倒排索引和列式存储的基础上，对外提供了更强大的数据检索功能，解决了大数据复杂的查询问题。它可以满足搜索已购买产品的用户等需求。Tablestore的多索引弥补了MySQL、HBase等在搜索上的不足。与Elasticsearch相比，多索引不再需要用户维护集群和维护数据同步任务，成本更低。3基于SQL的数据分析Tablestore支持SQL以多种方式读写Tablestore中的数据。如果想直接读取Tablestore中的数据，建议使用Tablestore的SQL支持能力直接操作；如果要对多个数据存储进行联合查询，建议使用DLA支持的SQL。对于这两种形式的SQL，Tablestore都使用多索引进行了全面优化。借助SQL处理能力，开发人员可以更高效地开发和迁移代码。直接使用SQL查询Tablestore也可以为MySQLmaster卸载流量。4.实时数据分析Tablestore的通道服务可以将Tablestore库中数据的变化传递给通道。使用SparkStreaming或Flink等流式数据处理工具对接通道，可以实现实时营业额统计等实时数据分析需求。5历史数据分析Tablestore可以将数据下发给OSS系统，完成订单的归档需求，通过OSS系统连接Spark完成历史数据的全量分析。这样，最近的数据存储在Tablestore中，全量历史数据存储在OSS中，全量历史数据的分析工作由OSS支撑。6ETL数据再加工通过将Tablestore数据接入ODPS，您可以利用ODPS强大的数据处理能力，更方便地对数据进行ETL操作和数据再加工。五、总结本文简要介绍了基于MySQL结合Tablestore的大型订单系统解决方案。该方案支持大数据存储、高性能数据检索、SQL搜索、实时全量数据分析，易于部署，运维成本低。
