高并发订单系统架构设计(二)
来源:互联网 发布:育儿软件下载排行 编辑:程序博客网 时间:2024/05/16 09:15
高并发下单主要包括以下几个方面:
- 分库分表
- 多应用实例全局唯一订单号
- 数据库连接
- 买家查询订单
- 卖家查询订单
- 扩容问题
- 业务拆分
一、分库分表
随着订单量的增长,数据库的发展主要经历以下几个步骤:
- 1主-1从架构
- 双主-多从架构,读写分离
- 表分区,提高并发
- 分表,提高并发
- Master更换SSD
- 分库,分表,提高并发
分库分表实现过程
订单分成16个库,每个库64个表进行存储,总共1024个表,mysql单表性能超过千万级别会导致性能严重下降,假设按千万计算,最高可以存储百亿级订单。随着存储问题的解决,但复杂度会随着增加:
首先是多库怎么保证生成的订单号全局唯一;
其次查询复杂度的增加;
买家查询订单时,应该去哪个库哪个表里查找,卖家应该去哪查;
再大的存储量,随着数据量的增长,终究是会遇到瓶颈,该怎么扩容。
二、全局唯一订单号
这里采用Twitter snowflake方案,全剧唯一ID生成由:时间戳+机器ID+自增序列(+userid后两位);
订单的生成过程直接在应用实例中生成,直接在内存中计算,且计算过程分散到每台应用实例中,解决性能问题,userid后两位在后面解释。
三、数据库连接问题
分库分表后,要连接数据库变的复杂起来,分为两种方案:
一、jdbc直连
此种方式需要在应用代码中,自己计算订单应该进入哪个库,可取订单的后两位,先对库16进行取模,再对表64取模,从而确定。优点是直连数据库性能更好,缺点是代码复杂度增加。
二、通过中间价连接
中间价可以使用阿里的mycat连接,具体使用查看mycat文档。优点:代码实现简单,跟分库前差不多
四、买家查询订单
订单成交后,买家需要查询订单的时候,只有userid,并不知道订单存在哪个库哪张表中,从每个库每个表中遍历一遍不现实。所以还要对订单号进行改进,之前是:时间戳+机器ID+自增序列。现在此订单号的后面加上userid的后两位,时间戳+机器ID+自增序列+userid后两位。订单入库取模的后两位即userid后两位,即同一个买家的所有订单都会存入同一个表中,通过此设计买家即可找到订单号应该在哪个表中。
五、卖家查询订单
卖家查询订单不能像买家一样,卖家的订单分散在订单表的各个表中。卖家订单需要在业务拆分过程中,将订单按卖家维度存入到别的库和表中。此维度不仅卖家可以查询到对应所有订单,并且方便统计、分析。
六、扩容问题
由于此方案已经不是单纯的通过订单号查找订单,还需要通过userid查找订单,其次是订单具有时间特性,用户查询的大部分都是最近的订单,3月前的订单很少会查看,所以不适合进行扩容,特别适合迁移历史数据,将3个月前的数据迁移到历史数据库中,从而解决容量增长的问题。
七、业务拆分
下订单过程,业务极其复杂,不只是订单号的生成插入等,还要减库存、支付等一系列的操作。所以应该通过消息队列将业务进行拆分,本步骤只做订单生成的操作,通过消息队列实现数据的最终一致性。
- 高并发订单系统架构设计(二)
- 转】大访问量系统的设计(二)——高并发高流量网站架构
- 【转】大访问量系统的设计(二)——高并发高流量网站架构
- 高并发系统数据库架构设计
- 高并发高流量的大型网站架构设计(二)
- 高并发高流量的大型网站架构设计(二)
- 大型高并发、高负载网站的系统架构设计
- 高并发高性能仓库库存系统的架构设计
- 高并发高性能仓库库存系统的架构设计
- 高性能、高并发网络通信系统的架构设计
- 每秒处理10万高并发订单的乐视集团支付系统架构分享
- 每秒处理10万高并发订单的乐视集团支付系统架构分享
- 每秒处理10万高并发订单的乐视集团支付系统架构分享
- 每秒处理10万高并发订单的乐视集团支付系统架构分享
- 每秒处理10万高并发订单的乐视集团支付系统架构分享
- 每秒处理10万高并发订单的某集团支付系统架构分享
- 高并发系统设计
- 高并发系统设计
- D. Lakes in Berland
- 公众号网页授权接口开发,实现微信公众号网页授权登录
- java大数值学习笔记
- 820 种职业、2,069 项业务中,34%(710 项工作)的比重将会被机器人替代!!!
- GAN系列学习(1)——前生今世
- 高并发订单系统架构设计(二)
- GO
- 折叠字符串
- 环境变量
- 模拟赛总结A
- 解决WINCE6.0 error C2220: warning treated as error问题
- 欢迎使用CSDN-markdown编辑器
- ArXiv 网页的HTML内容
- 从基础小白到业内大神,ps高手的成长之路