互联网电商系统数据库分库本表带来问题

随着互联网电商系统订单量爆发式增长,原有一个库一个订单表无法满足公司业务,需要重新考虑记录订单数据问题。

现在公司订单数据情况:

前端一套订单库放在IDC机房(通过VPN连接到公司局域网服务器)

后端两套订单库(放在公司机房),一套是写的库,一套是只读数据库,两套库以写的库为主库进行同步到从库只读库

现有订单库包含:订单及订单相关的表;优惠券表,促销表,商品表,地区等基础数据表,财务表,仓库系统表,运输物流系统,表用户系统表

1.简单办法:初步讨论需要对订单历史数据进行归档

2.最终办法:实现订单数据库水平和垂直进行分库分表,彻底解决互联网公司订单爆发式增长导致数据库服务器的资源不够用

订单一套表分别为:1.订单主表,2.订单商品明细表,3.订单支付明细表,4.订单商品商品促销折扣明细记录表,5.订单发票表

分别设计两套表:一套是记录订单维度5张表数据(按照订单Guid转换64位整型唯一长整型)

另外一套:用户订单关系表(记录订单主要信息和用户信息及取模维度(是按用户取模还是按照订单取模));

原订单库分成16个库,每个库有16套表,订单表有256个表去存储订单数据;

按照原订单Guid 转换64位长整型对256进行取模得到具体是哪个表tbIndex,然后数据库id: tbIndex/16 = dbIndex

然后把前端生成的订单数据256个表数据同步到后端一个数据库,就会有插入主键重复的问题出现;

分库分表:是按照订单主表的Guid来取模,确定是16个库哪个库256个表的那个表;

一套表都是按照订单Guid进行取模;

引起问题:

1.提交订单出现网络异常(服务端创建成功,返回到客户端因为网络异常导致客户端得到的反馈信息是没有成功,客服端继续点提交),

重复提交订单导致DB保存重复的订单信息,如果订单Guid在客户端生成,每次提交都会有个新的Orderid号出现,导致服务端一直以为是新订单(订单Guid即使是有唯一索引也会出现,记录在不同表去了,同步数据到后端库就会有);然后把前端生成的订单数据256个表数据同步到后端一个数据库,就会有插入主键重复的问题出现;

解决办法:对应订单及订单明细表的主键要是全局唯一,及时客户端重复提交也要保证提交的订单Guid及订单明细表的唯一主键要唯一不变化;

如果Guid一直唯一全局不变,即使客户端重复提交到创建订单服务 只认为是一个订单,创建时候会提示保存重复,或者创建提示已下成功。

2.由于公司订单大部分来自天猫超市平台;拉取天猫订单数据到公司数据库是以天猫超市店铺名为UserId;导致天猫订单全部散列到256各个表里面;

小用户的订单也会散列到不同表中;对于一个小用户来说根据用户去查询订单信息就需要 检索256个标示,至少要查询16次,其中每次要聚合16个表union all 查询;因为有16个库每个库有16个表

解决办法:分库分表还要以用户维度进行分库分表。用户订单关系表(记录订单主要信息和用户信息及取模维度(是按用户取模还是按照订单取模));

如果是大用户在订单维度分库分表: 按照订单Guid去取模,按照订单Guid散列,这样大用户的订单会均匀散列到256各个表中;在用户维度取模方式为大用户按照订单Id维度取模,小用户按照用户Id取模;这样能集中知道小用户的订单在用户维度分库分表是存储在一张表,能取到订单信息 去关联查询 订单维度分库分表去分别查询订单信息。

3.数据需要同步,数据库修改需要数据库中间件,消息发布订阅功能。

4.很多涉及到订单查询的服务全部要使用聚合256表去查询订单数据;

时间: 2024-11-10 14:18:21

互联网电商系统数据库分库本表带来问题的相关文章

小型电商系统数据库中的价格类型设计

今天分享一个小型电商系统的数据库价格字段的数据类型设计.附上通用四舍五入转换方法 我们知道,价格字段使用的类型,最佳的有两个,分别为:decimal,money:而money小数部分只能精确到4位,虽然money在内存上是比decimal少那么一个字节,但是现在硬盘那么大,不用计较了. 个人喜欢,我全部直接用decimal(18,5),小数部分我直接用了5位: 但是对于一个商品来说,我最多只会用到两位小数,百分比也只会用到4位,5位的只能是更小的佣金比例计算. 但我觉得这样算起来的数,小数实在是

“大型票务系统”和“实物电商系统”的数据库选型

讨论请移步至:http://www.zhiliaotech.com/ideajam/idea/detail/423 相关文章: <今天你买到票了吗?--从铁道部12306.cn站点漫谈电子商务站点的"海量事务快速处理"系统> 不能简单套用"实物电商系统"对"大型票务系统"做需求分析 "大型票务系统"和"实物电商系统"在不能提供商品(服务)时给消费者带来的影响有巨大差异 "大型票务系统&

如何来合理解决电商系统数据承载过大的问题呢?

原文地址:http://whosmall.com/?post=431 初创企业在发展过程中,一般不会遇到类似问题,但是随着业务量的增加,特别是电商系统,由于每日的订单数量过多,导致数据库的承载量过大,更换服务器的成本很大,所以如何来合理解决电商系统数据承载过大的问题呢? 1.从初始阶段,这应该是属于系统架构师应该考虑进去的事情,所以这项工作应该由架构师来完成: 2.如果没有合理的架构,那么在需要解决这个问题的时候,可以通过数据库分库,分表.切片的方式来进行.(再次强调这是个技术问题,产品不背锅)

程序员如何开发独立电商系统?

当社会发展进入"互联网+"时代,传统的PC电商已经不能满足电商运营者的需求,打造独立的移动电商系统是必然的趋势. 随着移动电商热度的不断增加,许多的商家是开始慢慢的加入到移动电商的行列当中,那么你们知道设计开发移动电商系统的吗?延誉电商为您答疑解惑! 1.规划阶段 前规划阶段的主要任务是进行建立数据库的必要性及可行性分析,确定数据库系统在组织中和信息系统中的地位,以及各个数据库之间的联系.规划工作完成后应写出详尽的可行性分析报告和数据库系统规划纲要.可行性分析报告的主要内容包括信息范围

电商系统架构——系统鸟瞰图

在看到图(一)这样的图,我们是否有一种探究系统的冲动?这样一个花花绿绿的界面,背后隐藏着什么样的奥秘!用户输入某个域名的时候,比如www.taobao.com的时候,页面是如何展示的,用户在搜索框搜宝贝的时候,系统又是如何处理的,用户在参加秒杀活动的时候,系统又是如何处理的.经过两年多的互联网从业经验,以及自己的思考,在这里我就抛砖引玉对电商系统架构进行探究,探究系统是如何设计的,以及设计这个系统的各种权衡. 图(一) 隐藏在花花绿绿的界面之后,是一个庞大复杂的系统,图(二)是这个系统的鸟瞰图.

优秀的开源电商系统有哪些

信息技术的迅速发展,商家想在众多的电商系统中选择一款合适的并不是那么轻易的事情,那么为了能够让商家在选择上减少时间,小编为你介绍几款好的开源电商系统. ECSHOP电商系统 基于PHP语言及MYSQL数据库构架开发的跨平台开源电商系统,因其强大功能拥有着大批粉丝.ECSHOP开源的电商系统最大的特色之一是功能健全,有着较为全面的商品管理.订单处理.会员管理等功能,其操作简易性更是成为国内多数从事电商行业的企业或个人的首选.ECSHOP是我国较为经典的一款老牌开源电子商务系统. MAGENTO电商

“大型票务系统”和“实物电商系统”在接入管理方面的差异

讨论请移步:http://blog.csdn.net/hu_zhenghui/article/details/27584047 相关文章: <今天你买到票了吗?--从铁道部12306.cn站点漫谈电子商务站点的"海量事务快速处理"系统> 不能简单套用"实物电商系统"对"大型票务系统"做需求分析 "大型票务系统"和"实物电商系统"在不能提供商品(服务)时给消费者带来的影响有巨大差异 "大

“大型票务系统”和“实物电商系统”按系统边界分析各种业务形式

讨论请移步至:http://www.zhiliaotech.com/ideajam/idea/detail/191 相关文章: <今天你买到票了吗?--从铁道部12306.cn站点漫谈电子商务站点的"海量事务快速处理"系统> 不能简单套用"实物电商系统"对"大型票务系统"做需求分析 "大型票务系统"和"实物电商系统"在不能提供商品(服务)时给消费者带来的影响有巨大差异 "大型票务系统&

“大型票务系统”和“实物电商系统”的系统边界之间的差别与联系

讨论请移步至:http://www.zhiliaotech.com/ideajam/idea/detail/118 相关文章: <今天你买到票了吗?--从铁道部12306.cn站点漫谈电子商务站点的"海量事务快速处理"系统> 不能简单套用"实物电商系统"对"大型票务系统"做需求分析 "大型票务系统"和"实物电商系统"在不能提供商品(服务)时给消费者带来的影响有巨大差异 "大型票务系统&