大数据量下的订单架构设计方案

终于找到丢了的CSDN账号了= =,趁最近找工作没啥事写写博客吧..顺便回顾下最近的项目

分库分表

存储大量的订单最长想到的就是分库分表了,这应该也是最为常见的手段.

最简单的策略是根据用户ID去分表,比如取用户的ID做模运算(用户ID % 表数量 or 用户ID % 库数量)

我们使用的 sharding-jdbc 进行分库分表操作,sharding-jdbc 它定位为轻量级Java框架,在Java的JDBC层提供的额外服务.它使用客户端直连数据库,以jar包形式提供服务,无需额外部署和依赖,可理解为增强版的JDBC驱动,完全兼容JDBC和各种ORM框架.就算程序写完在上线之前都很容易加入到系统中.

冷热数据分库

        当然数据量非常巨大的时候分库也不能满足需求的时候就可以把数据分为冷热数据了...什么是冷热数据不明白?那烧壶水就明白了吧..刚烧的水是热的过阵子凉了就是冷的.这只是举个小例子.其实是较为常用的数据是热数据,反之冷数据.在订单中用户一般只会查看最近的数据而一般不会查看之前的数据...跑题了..对于订单这类数据可以将近期的数据存到DB中定期将以前的数据放入HDFS系统中(使用Impala Hive等等),关键字查询的数据可以异构到solr索引系统中,这样用户做查询的时候可以查询出完整的数据.

数据库拆分

        一般来说数据不会单单存在一个表中,比如订单不会只存在订单这一张表,其中有些信息可能会分开存储(比如我用户看到订单可能其中有商户的信息,我商户在查询的时候往往是不会查看商户信息..自己看自己有啥用?).当查询的时候需要大量的join,当表很大的时候join是非常耗时和资源的.这时候可以将数据根据用户维度和需求分别存入不同的库中,比如我们商城的订单根据用户和商户的需求分别存入不同的表和库中.具体操作也很简单,正常的下单后正常存入DB中然后发送队列信息,由消费程序重构数据分别存入不同的表和库中.