订单系统设计 —— 订单管理

本文介绍了订单管理系统的设计与演进,从单一的MySQL架构到结合NoSQL,再到对NewSQL的展望。文章讨论了数据量增长、多维查询需求以及性能挑战等因素,详细阐述了读写分离、垂直拆分、数据归档、分库分表等策略,并探讨了MySQL+ES+HBase的解决方案,最后提出了NewSQL对未来订单管理的潜在影响。
摘要由CSDN通过智能技术生成

一、方案背景

  订单系统是存在于各行各业的一个很基础、核心的业务系统。随着互联网的发展,订单系统的管理方案也在不断变化,订单数据规模的膨胀、用户对数据的重视,以及新的技术等都会影响订单管理方案。

1.1 考虑因素

  • 数据量: 订单的特点是只增不减,随着时间推移,订单量会越来越多;

  • 多维查询分析: 能够灵活的支持不同角色用户多种维护的查询和分析;
    在这里插入图片描述

  • 性能: 订单管理服务需要只能高并发、低延迟;

1.2 数据特点

  订单数据具有明显的时间属性,主要呈现出两个特点:

  • 特点1:时间越久的订单被访问到的概率越低;
  • 特点2:订单规模随着时间推移不断变大,GB、TB,甚至PB等;
    在这里插入图片描述

二、方案演进

  技术架构不是设计出来的,是演化出来的。订单管理方案也是随着业务和技术的发展,不断演化的,如下图所示。按照技术架构特点,大致分为三类:

  • MySQL架构:通过扩展库表数量来提升读写能力和存储容量;
  • MySQL + NoSQL架构:MySQL提供事务能力,NoSQL保障海量数据的存储和多维查询分析能力;
  • NewSQL架构:期待成熟的产品出现,兼容MySQL、NoSQL二者优势;
    在这里插入图片描述

说明: 订单是个性化的数据,每个用户的订单数据都不同,不适合使用缓存;

三、MySQL架构

<

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值