电子商务系统订购系统

01 概述

作为电子商务系统“链接”的订单系统贯穿整个电子商务系统的关键过程。其他模块围绕订单系统构建。订单系统的发展随着电子商务平台业务的变化而演变。接下来，我们将与您一起分析电子商务平台的“生命纽带”。

上帝查看订单系统

来源：提供商

订单系统的作用是管理订单类型，订单状态，收集订单，报价，用户，收据信息，支付信息等的一系列实时数据，并执行一系列操作，如库存更新和订单发行。订单系统业务的基本模型涉及用户，货物（库存），订单和付款。订单的基本流程是下订单——＆gt;减少库存。这两个步骤必须同时完成，订单不能扣除（超卖），或减少库存不生成订单（卖得少）。超卖商户的库存不足，消费者无法在订单下购买任何东西，经验不佳;少量销售业务库存积压或需要反复修改产品信息，反复遇到麻烦，经验不好。

02 订购基本概念

在设计订单系统时需要考虑几个主要方向，这决定了订单系统的稳定性和可持续性。

订单多样性功能

订单的多样性主要是由于来源和运营的多样性造成的。

订单字段

订单字段包含需要在订单中记录的信息。他的角色主要用于与其他系统通信，为下游系统提供信息。

订单信息

订单号用作订单标识的标识。它通常根据特定规则生成，并根据顺序的增加而递增。同时，在设计订单号时会考虑订单无序设置（阻止竞争对手或第三方估算订单数量）。订单号随后用作订单的唯一标识符，用于在对接WMS（仓库管理系统）和TMS（运输管理系统）时识别订单。

订单状态

订单状态将在以下各节中详细介绍

用户信息

指买家的信息，包括姓名，地址，手机号码。 O2O也会有更多的自我提升点，因此地址将成为接收点的地址。然后，地址信息将用于WMS和TMS，以区分区域和交付安排。

产品信息

商品的基本信息和库存，由于特殊金额的金额不同，所以我说金额是独立于产品信息的，但它在逻辑上属于商品信息的范畴。商品信息主要影响库存更新和WMS生成。

金额信息

订单生成的产品信息，除了要记录的最终金额外，还需要记录处理金额。例如，产品的金额，付款金额，应付金额等。在随后的订单结算，退货和换货，财务和其他方面需要使用。

时间信息

记录订单的每个状态节点的触发时间。

03 订单处理

订单处理是指从整个过程的生成到完成的整个订单的过程，包括正向和反向过程。

转发过程

这主要是关于主流电子商务系统中的一般订单流程，可以根据平台的特殊性调整一些细节。

注意事项

在订单生成过程中有一个超时失败的过程支付自动取消，并且在订单取消后将释放库存占用。

如果选择COD（货到付款），付款链接将转移到订单交付，并且与付款相关的所有逻辑将仅成为操作金额，并且结算和帐户将不会被退款。

金额分配需要项目

订单系统审核主要处理恶意用户或计费情况。系统可以基于白名单，黑名单，购买频率和促销项目的购买来制定风险控制规则。如果随后进入人工审查，规则可以适当宽泛。触发规则时，需要执行订单取消订阅操作。在此设计时，应特别注意用户体验。前台副本中经常声明当前节点处于审核状态或等待订单。

通过与第三方物流相关的物流信息来跟踪传统电子商务。

需要在SOA服务中进行预售和其他职位，以计算交易页面上的预计时间和预计到达时间。转移仓库的情况取决于仓库，它还涉及后续拆分和合并包的逻辑。

当订单生成时，有必要判断短缺的情况。如果存在短缺问题，有必要考虑整个报告的情况，部分是短缺，交换或变更（库存，仓促转移和退款）。报告差距分为系统短缺和实际报告，这两个环节是相互独立的两个环节。

电子商务系统应考虑7天无理由退货的情况，即在订单状态完成后申请退货。此时，主要关注的是计算一些财务程序（如发票）的金额和处理。

逆流

反向流程是指订单取消，退回等时触发的订单流程。

触发反向过程有几个触发器：

用户取消订单（完整订单）

风控系统触发订单取消（完整订单）

客户服务收到客户的诉讼后，将触发订单取消（整个订单）

不定时取消订单（完整订单）

替换报告将变为退款（完整订单，部分报告）

专注

订单状态（在某个节点之后，订单生成后订单无法取消）

当退款被商家拒绝时，需要将其转移到客户服务仲裁部门

部分退款订单促销通常仍在使用中，但金额将根据评估金额退还

订单状态

分析和理解订单状态设计目的和存在价值背后的设计机制：维度和维度粒度。

1.正向和反向过程尺寸

远期订单：已锁定，已确认，已付款，已发货，已结算，已完成，已取消等等。

转发预售订单：预付款尚未确认，已确认未付（更改）

转发问题清单：未经证实，未解锁，未发货，部分付款，未付款等。

反向退款：待结算，未收货，无存货，未通过质检，部分收货，取消，客户收货等。

逆向订单更改：已完成，已结算，已收到客户服务等

2.服务对象维度

客户/用户：待付款，待定交货，待定收货，待定评估，买方付款，交易成功/失败，卖家发货，退款成功，交易关闭，

其他交互式系统，如ERP：锁定，确认，装箱，分配，出站，接收，完成等。

等待买家付款，待付款和待处理订单，退款订单，已支付押金，买家付款，

卖家已发货，交易成功，交易失败，订单异常

订单推送

当状态发生变化时，相应的变更需要通知相关人员了解当前的顺序，这是订单推送的作用。

触发订单推送取决于状态机的更改，所涉及的信息包括

推送物品（用户，物流人员，商人）

推送方法（推送，短信，微信）

推节点（状态改变）

04 订单系统设计的挑战与实践 订单系统要求Evolution

第一步：实现购买流程

1.实现订单创建，交付，确认等信息的闭环。

2.支持订单审核（初始可以支持人工审核）

3.支持客户显示订单相关信息

4.支持促销金额的计算

第2步：提供服务

1.提供订单分发服务

2.支持跨平台交易订单生成（即同一大交易订单中的商品和自营商品或多个商家的商品）

3.支持拆分，合并逻辑（交货订单，付款订单等）

4.提供更丰富的订单推送服务并改善订单状态

第3步：支持不同营销方式下的订单类型

该平台已经发展到足够大的规模，效率和稳定性已成为一个重要的话题。可以在不同的营销方案下提供订单，例如：团购，预订等。

订单系统架构的演变

第一代：简单粗鲁

第一代问题

在第一代系统中，由于订单状态是在特定服务器上处理的，如果服务有问题，订单将丢失，订单处理将不会继续。

总结：

1.服务单点

2，数据库单点

第二代：无状态异步驱动器

第二代系统已针对第一代进行了改进，应用程序服务器不再保留订单状态。但是，这样的系统设计也会导致数据库服务器上的高频查询压力，导致数据库相对较弱。

总结：

状态扫描导致的负载

第三代：队列模式

第三代是第二代的升级版。订单的状态流不再依赖于高频查询数据库。通过队列模式，数据库的压力得到了很好的缓解，但第三代仍然存在问题，即系统中的server2。成为核心，该模块的维护将变得非常复杂，这是架构设计的关键。如果没有完整的完美架构，只能获得平衡的架构。

三代系统演化的最佳实践

练习1:重试和补偿

多台机器重试无法同步，需要随机跳转（抖动）和指数退避（

正在重试的服务也可能已关闭，您需要保存状态（State）

练习2:幂等性

你没有收到回复而且没有失败。

你没有回复别人，认为你成功了

重试必须带来唯一有意义的ID

每个服务呼叫必须是幂等的

非只读服务必须保存状态

练习3:一致性练习

订单系统具有很强的一致性要求

没有单点故障的分布式系统的一致性是一个非常困难的问题

现有算法: Paxos，现有的开源系统（例如Zookeeper）

有时单点故障并不可怕，常用，成熟的关系数据库解决方案也是不错的选择

云分布式系统，没有单点故障

练习4:工作流程（工作流程）

可伸缩性:

无状态工作者，分布式部署，分布式存储工作流状态

可靠性:

定时器，重试，幂等性，强一致性状态

可维护性:

工作流描述和执行活动描述是分开的，支持异步触发

支持版本和升级

系统优化;

数据库读写分离;

基本原则是让主数据库在处理来自数据库的SELECT查询时处理事务查询。数据库复制用于将事务查询引起的更改同步到集群中的辅助数据库。当然，主服务器也可以提供查询服务。使用读写分离的最大效果只不过是环境服务器的压力。

优点

增加冗余

提高机器的处理能力

对于面向读取的应用程序，使用读写分离是最佳方案，因为它可确保写入服务器的压力较小，并且读取可以接受延迟时间。

改进读写分离以提高性能的原因

物理服务器增加，负载增加

主人和奴隶只负责自己的写作和阅读，大大缓解了X锁定和S锁争用

从库中配置myisam引擎以提高查询性能并节省系统开销

库同步主库中的数据与主库直接不同。主库发送的binlog恢复数据。但是，最重要的区别是主库以异步方式将binlog发送到从属库。从库中恢复数据也是异步的。

读写分离的应用和读取远远超过写入方案。如果只有一个服务器，当有多个选择时，更新和删除将被select访问中的数据阻塞，等待select结束，并发性能不高。对于具有类似写入和读取比率的应用程序，应部署双主机以相互复制

您可以通过添加一些参数来提高从库中读取的性能，例如--skip-innodb， - skip-bdb， - low-priority-updates和--delay-key-write=ALL。当然，这些设置也需要根据具体的业务需求来确定，不一定使用

分享阅读。如果我们有1个主3个从站，不管上面1中提到的从属单边设置，假设在1分钟内有10次写入和150次读取。然后，1个主机3相当于总共40个写入，并且总读取数没有改变，因此平均而言，每个服务器承载10次写入和50次读取（主库不进行读取操作）。因此，尽管写入没有改变，但是大大地共享了读取，并且提高了系统性能。另外，当扩展读取时，间接地改善了写入的性能。因此，整体表现有所改善。说白了，就是拿机器和带宽来提高性能。

MySQL复制的另一个主要特性是增加冗余并提高可用性。当数据库服务器关闭时，它可以调整其他从属库以尽快恢复服务，因此您不能只查看性能，即1个主服务器。 1也是可能的。

实施计划

数据库子数据库

无论使用何种子数据库表或平台，核心思想是将最初存储在单个表中的数据拆分，并将数据分发到多个数据库中的多个表以避免因为单表数据的数量太多大，它给读取和写入性能带来了数据访问的问题。因此，在子数据库子表方案中，最重要的原则是将拆分数据尽可能均匀地拆分到后端数据库中。如果分割不均匀，也将生成数据访问热点，并且还将存在热数据。由于数据表上的快速增长和数据量过大的问题。

对于要拆分的数据的纬度，我们看到在许多情况下，业务数据的ID（在大多数情况下，此ID是自增长），HASH模数方法用于均匀地分割数据。在许多场景中，这种简单的方法确实是一种非常合适的分割方法，但它并不是在所有场景中以这种方式分割的最佳方法。也就是说，如何分割数据没有所谓的黄金法则，更需要结合业务数据和业务场景的结构来确定。

以下是每个人最熟悉的电子商务订单数据的细分。订单是任何电子商务平台的商业数据。每个平台用户提交订单并在平台的后端生成与订单相关的数据。通常，记录订单数据。数据库表结构如下：

订单数据主要由三个数据库表组成，主订单表对应于用户的订单，每次提交时，生成主订单表的数据。在一些情况下，用户可以在一个订单中选择不同卖家的产品，并且每个卖家将根据订单提供的产品（例如100元减10元）并根据不同的收据计算相关的产品折扣。货物地址设置不同的物流配送，因此将有一个相关的子订单概念，即一个主订单将由多个子订单组成，并且每个特定订单信息的实际对应保存在订单中细节表。

如果电子商务平台的业务健康发展，由于单个数据库表中的数据量过大导致性能瓶颈，订单数据相对容易出现，因此需要拆分数据库。此时，理论上可以通过两个纬度来执行分裂顺序。一个纬度由订单ID（通常是自增长ID）模数，即订单ID是子库表密钥;传递一个买方用户ID的纬度被哈希，即买方用户ID是子库表键。

比较两个选项：

1.如果它基于订单ID，例如模数1024，则可以保证主订单和相关子订单。订单详细信息数据属于后端1024数据库表，这原则上是令人满意的。数据分割的原则尽可能均匀。

2，通过采用买方ID模数法，例如，根据1024模数，技术上也可以确保将订单数据分成后端1024个数据库表，但会有一个业务场景带来的问题是，如果有些卖家具有非常大的交易量，那么这些卖家的订单数据量（尤其是订单详细信息表中的数据量）将大于其他卖家的订单数据量，即数据将不均匀。最终，这些卖家的订单数据库将进入其他数据库之前的数据存档（为了避免因在线交易数据库的数据增加而导致的数据库性能问题，3个月内的订单数据一般保存在在线交易数据库中，超过3个月的订单将归档后端专用存档数据库）。

因此，从“平均数据尽可能分割”的原则出发，根据订单ID模数的方法似乎保证了订单数据的平均分割，但我们不应该这么快得出结论，而且还要根据不同业务场景和最佳实践观点考虑了不同纬度的优缺点。

总结

对电子商务平台的需求一直在变化，订单系统的结构也会随之发生变化。架构设计是一个持续改进的过程。本文中有许多细节未提及。如果您想使订单系统更好，系统的每一步都需要加深。例如，需要慢慢雕刻灾难恢复，灾难恢复，交通分流和流量控制。建筑中没有完美的建筑。只有平衡的建筑，不需要追求完美的单点，而是追求更多的平衡。

随商信息技术（上海）有限公司 b2b2c多用户商城系统是基于PHP技术的企业级电子商务平台系统，系统支持平台自营、招商加盟和多商家入驻、集成微信商城、移动端APP商城、微信小程序于一体。公司主营业务包含商城系统定制开发、新零售系统解决方案、电商平台系统定制开发、商城网站建设服务等等，随商为大、中、小企业提供一个安全、高效、强大的电子商务解决方案，协助企业快速构建、部署和管理其电子商务平台，拓展企业销售渠道，致力于推动PHP技术和电子商务行业的发展而不断努力。