订单表的分库分表方案设计

发布时间:2017-7-9 7:33:56编辑:www.fx114.net 分享查询网我要评论
本篇文章主要介绍了"订单表的分库分表方案设计 ",主要涉及到订单表的分库分表方案设计 方面的内容,对于订单表的分库分表方案设计 感兴趣的同学可以参考一下。

原创文章,转载注明出处

 

一、两种方案分库分表

 一般业界,对订单数据的分库分表,笔者了解,有两类思路:按照订单号来切分、按照用户id来切分。

方案一、按照订单号来做hash分散订单数据

     把订单号看作是一个字符串,做hash,分散到多个服务器去。

     具体到哪个库、哪个表存储数据呢?订单号里面的数字来记录着。

    现在的微信红包。它的订单分库分表,是对订单号进行hash计算。不是什么取模、取整数。这样数据是均匀分散的。

    然后订单号的末尾3个数,里面是包含了库名称、表名称的。

     如果要查询某用户的所有订单呢?

     由于是根据订单号来分散数据的。他的订单分散在了多个库、多个表中。

     总不能去所有的库,所有的表扫描吧。这样效率很低。

      其实按照uid切分订单,一样会遇到查询的问题。比如要查询a订单的信息。分库分表的规则是按照uid,都不知道数据在哪个库,无从查。

      后续说明解决思路。

     一般使用方案二的比较多,一个用户的所有订单,都在一张表里面,那么做分页展示的时候,就容易。

方案二、按照用户id打散订单数据。

 

以uid来切分数据,有两种思路:

一种是,某个范围的uid订单到哪些库。0到2千万uid,对应的订单数据到a库、a表。2千万到4千万对应的订单到b库。

为什么这种方案用得比较少呢?

容易出现瓶颈吗。某个范围内的用户,下单量比较多,那么造成这个库的压力特别大。其他库却没什么压力。

第二种是,使用uid取模运算。第二种方案业界用得比较多。

一方面、处理简单,程序上做取模运算就好了。

另一方面、使用取模的方式,数据比较均匀分散到多个库去了。不容易出现单个库性能瓶颈。

但是不好处也有:即要扩容的时候,比较麻烦。就需要迁移数据了。

要扩容的时候,为了减少迁移的数据量,一般扩容是以倍数的形式增加。比如原来是8个库,扩容的时候,就要增加到16个库,再次扩容,就增加到32个库。这样迁移的数据量,就小很多了。这个问题不算很大问题,毕竟一次扩容,可以保证比较长的时间,而且使用倍数增加的方式,已经减少了数据迁移量。

 

下面笔者,分析一下按照用户id取模的方式分库分表。

按照用户id作为key来切分订单数据,具体如下:

1、 库名称定位:用户id末尾4位 Mod 32。

  Mod表示除以一个数后,取余下的数。比如除以32后,余下8,余数就是8。

  代码符号是用%表示:15%4=3。

2、表名称定位:(用户id末尾4位 Dev 32) Mod 32。

  Dev表示除以一个数,取结果的整数。比如得到结果是25.6,取整就是25。

  代码用/来表示:$get_int = floor(15/4)。15除以4,是一个小数3.75,向下取整就是3。一定是向下取整,向上取整就变成了4了。

 按照上面的规则:总共可以表示多少张表呢?32个库*每个库32个表=1024张表。如果想表的数量小,就把32改小一些。

上面是用计算机术语来表示, 下面用通俗的话描述。

 

1、库名称计算

用户id的后4位数,取32的模(取模就是除以这个数后,余多少)。余下的数,是0-31之间。

这样可以表示从0-31之间,总共32个数字。用这个32个数字代表着32个库名称:order_db_0、order_db_2.........................order_db_31

2、表名称计算

   最后要存储定到哪个表名里面去呢?

  用户id的最后4位数,除以32,取整数。将整数除以32,得到余数,能够表示从0-31之间32个数字,表示表名称。

  表名称类似这样:order_tb_1、order_tb_2..........................order_tb_31。一个库里面,总共32个表名称。

  比如用户id:19408064,用最后4位数字8064除以32,得到是251.9,取它的整数是251。

  接着将251除以32,取余数,余数为27。

  为了保持性能,每张表的数据量要控制。单表可以维持在一千万-5千万行的数据。1024*一千万。哇,可以表示很多数据了。

三、思考优点和缺点

优点

订单水平分库分表,为什么要按照用户id来切分呢?

好处:查询指定用户的所有订单,避免了跨库跨表查询。

 因为,根据一个用户的id来计算节点,用户的id是规定不变的,那么计算出的值永远是固定的(x库的x表)

  那么保存订单的时候,a用户的所有订单,都是在x库x表里面。需要查询a用户所有订单时,就不用进行跨库、跨表去查询了。

缺点

 这种方式也不是没有缺点。

  缺点在于:数据分散不均匀,某些表的数据量特别大,某些表的数据量很小。因为某些用户下单量多,打个比方,1000-2000这个范围内的用户,下单特别多,

  而他们的id根据计算规则,都是分到了x库x表。造成这个表的数据量大,单表的数据量撑到极限后,咋办呢?

  总结一下:每种分库分表方案也不是十全十美,都是有利有弊的。目前来说,这种使用用户id来切分订单数据的方案,还是被大部分公司给使用。实际效果还不错。程序员省事,至于数据量暴涨,以后再说呢。毕竟公司业务发展到什么程度,不知道的,项目存活期多久,未来不确定。先扛住再说。

比较好的方案是不是:又能均匀分散、又能避免单表数据量暴涨方便扩容。以前看过一篇文章介绍过使用节点来存储分库分表。笔者暂时没完整的思路。

二、查询需求的考虑

 

  

方案一的查询问题

   方案一的情况下,由于是按照订单号做分散数据到多个库、多个表。如果需要查询a用户的所有订单,咋办?需要跨库、跨表查询。

   这样效率低。不可行。

   

方案二的查询问题

如果是按照uid来切分订单数据,在实际应用中一些很频繁的查询需求像下面这样:

1、后台、前台,往往是输入一个订单号,查询这个订单的数据。select操作

2、然后修改这个订单的相关状态。update操作。

  由于是,按照用户编号将订单数据分散在各个库、各个表中。

  那输入订单号,怎么知道去哪个库、哪个表查询呢?不可能所有的库、所有表都查询一遍,效率太低,不可行。

 三、解决办法:建立用户id和订单号的索引关系表

      无论是根据用户id来切分订单,还是根据订单号切分数据。总不能十全十美的。

     

      写到这里,发现真的没有一种技术方案是十全十美的,看,使用用户id来切分订单,好处是有了,坏处也出来了。

      不过没关系,早要有心里承受:不要觉得技术是完美无缺的。针对这种情况,想办法去解决办法。

    思路:既然是根据订单号分散订单数据,如果需要知道某个用户所有的订单。只要我能知道了a用户的所有的订单号,那么就可以根据订单号定位到表名称了。

    思路:既然是根据用户id来分散订单数据的。那么只要知道了这个订单号是谁的(得到了用户id),就能知道去哪个库、哪个表查询数据了。

   

      那怎么知道是谁的呢?建立一个索引关系表,暂且叫做订单用户关系索引表order_user_idx。咱们命名为了保持维护性,还是一看能够知道是干嘛用的。

     存储的数据包括两项:订单号、用户编号。

     这样输入订单号,可以去查询索引关系表,获取到用户编号。

     得到了用户编号,问题解决了。订单信息是根据用户编号分库分表的,可以直接定位到x库x表了。

     当创建订单的时候,就要把关系插入到表里面去了。保存关系记录时,为了减低用户等待时间,不需要实时,做成异步。加入到消息队列中去操作。

    

     订单用户索引关系表的性能优化

 

     

     考虑到,一个用户的下的订单可能是几十个,也可能是几百个,随着时间的推移,会越来越多。这个索引关系表,也不能使用单表存储。

     所以对这个订单用户关系索引表,也要进行分库分表:直接根据订单号取模进行分库分表。是不是感觉挺麻烦了。确实麻烦。不过能解决问题就好。暂时没想到其他办法了。

    一个订单,在创建的时候,就已经分配好给指定用户了。只是一个关系对应,以后也不会变化。

    根据这个特点。订单用户索引关系表,其实可以放到内存中缓存起来应对查询需求(数据库那张索引关系表也要有,数据要持久化)。

    平时查询的时候,走内存缓存查询。如果查询不到,再走数据库查询一下关系。这样速度就很快了。

    结语:水平分表,其实折腾起来工作量挺大的,切分了后,出现新的问题,代码查询又得改,要提供其他解决办法。所以经常看到别人说,能不水平分表,尽量不要分,业务没达到瓶颈,先用硬件扛住,后面再考虑水平切分数据。看银行、联通这些有钱的企业,使用性能强劲的oracle搭配小型机服务器,单表的数据量达到十多亿。小型机是专门定制的,几十万一台。性能很强。分库分表是很耗费时间、当你交易量做到上亿规模的时候,那时,公司的实力应该可以了,经济方面有足够的实力聘请经验丰富的技术来重构。

思考一、b2b平台的订单分卖家和买家的时候,选择什么字段来分库分表呢?

上面讨论的情况是,b2c平台。订单的卖家就一个,就是平台自己。

b2b平台,上面支持开店,买家和卖家都要能够登陆看到自己的订单。

先来看看,分表使用买家id分库分表和根据卖家id分库分表,两种办法出现的问题

如果按买家id来分库分表。有卖家的商品,会有n个用户购买,他所有的订单,会分散到多个库多个表中去了,卖家查询自己的所有订单,跨库、跨表扫描,性能低下。

如果按卖家id分库分表。买家会在n个店铺下单。订单就会分散在多个库、多个表中。买家查询自己所有订单,同样要去所有的库、所有的表搜索,性能低下。

所以,无论是按照买家id切分订单表,还是按照卖家id切分订单表。两边都不讨好。

淘宝的做法是拆分买家库和卖家库,也就是两个库:买家库、卖家库。

买家库,按照用户的id来分库分表。卖家库,按照卖家的id来分库分表。

实际上是通过数据冗余解决的:一个订单,在买家库里面有,在卖家库里面也存储了一份。下订单的时候,要写两份数据。先把订单写入买家库里面去,然后通过消息中间件来同步订单数据到卖家库里面去。

买家库的订单a修改了后,要发异步消息,通知到卖家库去,更改状态。

思考二:那可以按订单号来分库分表吗?  

这样分库分表的话,用户有10个订单,订单不见得都在一个库、一个表里面。查询a用户的所有订单,就会变得麻烦了。尤其是要进行分页展示,分散在不同的表,甚至不同的数据库服务器,也比较耗费性能。

那么订单号里面,最好是要有分库分表信息。淘宝的是在订单号里面添加了卖家id末2位、买家id末2位。这样的好处是干嘛呢?直接定位到具体的库、具体的表去了?

怎么根据这个呢。因为分库、分表的规则,买家库是按照卖家id末尾2位数分,卖家库是按照卖家id末尾两位分。

所以,只要从订单号里面拿到了这些数字信息,就知道在哪个库,哪个表了。

这种办法,与微信的红包订单号是类似的,末尾三位数包含了库信息、表信息。

按照这样,其实就没必要使用订单号来计算了?

如果是按照用户id的后4位数取模分散订单数据。那么订单号的生成,可以在后面加上用户id的后4位数。

那么,虽然是按照用户id来对订单表分库分表的。其实可以直接根据订单号,知道这个订单在哪个库哪个表了。

如果是b2b系统,涉及到卖家和买家。那么可以把卖家和买家的id后面4位都加进去。不过是不是订单号太长了?

思考三、按照订单的时间来分表如何?

一月一张表。一年一张表。用户的所有订单,会分散在不同的库、不同的表中。

按照时间分,在切分订单数据的时候,业界用得比较少。

出现如下两个问题:

1、如果需要分页查询某个用户的所有订单数据,就会出现跨库、跨表查询。效率低。

    可以做折中:限制只能查一个范围内的订单,比如一次只能查询,一年以内或者一个月以内的订单。

2、某个时间集中写入数据,出现瓶颈。如一个月一张表。这个月的订单量暴涨呢。那么写入新的订单数据都会操作这张表。造成性能低下。影响整个业务系统交易。

真正好的分表方案,尽量将写数据分散到多个表去,达到分流效果,系统的并发能力就提高了。


上一篇:bugly中批量隐藏版本

相关文章

相关评论

本站评论功能暂时取消,后续此功能例行通知。

一、不得利用本站危害国家安全、泄露国家秘密,不得侵犯国家社会集体的和公民的合法权益,不得利用本站制作、复制和传播不法有害信息!

二、互相尊重,对自己的言论和行为负责。

好贷网好贷款