标签：处理 复杂度 中间件 查询 订单 数据量 电商 SpringCloudAlibaba 流程

一、订单业务复杂度分析

　　对于订单系统来说，业务复杂度主要体现在流程复杂、状态多、状态转换复杂等问题。

　　1、流程设计

　　　　从流程上说，订单系统有下单流程、退款流程、退货流程、换货流程、业务对账、业务订正等场景，场景复杂。

　　　　

 

 　　2、状态设计

　　　　对于各种状态以及各种状态的转换，使用状态机进行处理，同时这么多的状态，在前端应该怎么显示，也是需要进行设计的。

　　　　　　 

 　　3、拆单规则

　　　　对于不能放在一个订单内的商品，虽然是一起下单，一起生成了原始订单，但是在实际支付后，是需要进行拆单处理的，

　　　　常规的做法是对于跨商家、跨仓储、由于业务和合规需要拆单、订单金额超阈值、体积重量超阈值等情况需要进行拆单处理。

　　　　　　

 　　4、优惠拆分

　　　　对于优惠信息来说，下单时用户选的优惠券是统一使用的，如何将优惠券拆分到每个商家、以及发生售后时优惠券如何处理都是一个比较难处理的问题。

二、技术复杂度

　　1、单表数据量大

　　　　对于单表数据量大，主要方案就是进行分表处理，采用了分表，就会带来其他的问题，例如路由规则如何设定、分布式事务如何处理、分表中间件选型、全局唯一订单如何保证、查询时没有分片建怎么处理？针对这些问题的解决方案如下图所示：

　　　　　　

 　　2、TPS高

　　　　TPS高就是写入速率高，可以采用分库处理，一旦采用了分库，就会带来其他的问题，与分表不同的是，会存在分布式事务的问题

　　　　　　

　　3、QPS高

　　　　QPS高是读取速率高，那么可以采用增加缓存、使用数据库主从&读写分离的方式来提高QPS，那么就会带来新的问题，例如如何保证缓存一致性、主从数据库同步延迟怎么处理、读写分离的规则如何划定等

　　　　　　　　

　　4、 多维度查询复杂

　　　　采用了分库分表后，很难支持多维度复杂的查询，特别是没有分片建的一些查询，该场景可以使用ES进行处理，那么就会带来新的问题，例如如何保证数据一致性、ES数据延迟等情况

　　　　　　　

　　5、历史数据量大

　　　　随着订单数据量的不断增加，历史数据也会越来越多，但是历史数据又不会经常查询，如何解决历史数据同时又能保证历史数据的查询是一个问题。该场景可以使用hbase做数据归档，那么就需要考虑归档逻辑，归档数据查询的问题

　　　　　　 

 　　6、数据安全

　　　　在实际落地时，我们要考虑接口的幂等、并发锁、多租户、网络隔离等问题，例如：

　　　　　　幂等可以使用前端置灰防止重复提交、前端使用唯一ID标记一次提交、后端预生成订单号、redis记录临时提交、基于数据库唯一索引等方式进行保证

　　　　　　并发锁可以使用乐观锁和悲观锁进行保证并发安全，例如乐观锁用于状态更新、悲观锁用于订单创建

　　　　　　

 　　7、系统容灾

　　　　上面分分析，用到了ES、Mysql、Redis等中间件，对于中间件使用集群的方式保证高可用，从业务服务的角度，需要对服务进行集群部署，同时进行限流、熔断、降级等处理

　　　　　　

 　　8、系统容量及吞吐量

　　　　系统容量和吞吐量可以通过评估、扩容、异步等方式来保证

　　　　　　

 　　9、预警能力

　　　　一个系统是否是稳健的，可度量、可追踪、可视化是必备的能力之一，例如监控和告警等，预警能力可以从接口层、应用层、OS、中间件等各个维度进行监控

　　　　　　

　　10、其他

　　　　如果用户量大，其实还需要从机房的角度做高可用，例如用户分区和多机房等。 

 

标签：处理,复杂度,中间件,查询,订单,数据量,电商,SpringCloudAlibaba,流程
来源： https://www.cnblogs.com/liconglong/p/16521516.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。