转账功能的设计 - 存储层

试想一下，一个巨大的订单量给你。要从中获取到某个订单，要如何操作呢？

首先便是分库分表，我们可以把一个大的数据集划分为小的数据集，这样根据不同订单的信息，可以从不同数据库不同表中获取。避免向单个数据库或单张表的请求量过大，容易崩溃。

那么分库分表的依据是什么呢？

首先容易想到的就是从时间上来分。我们可以按照年月来分。比如说按年分库，按月分表。由于订单会带有时间信息，这样我们根据时间信息，就可以马上知道这个订单在哪个库和哪张表了。

但是想想这样有什么不好的呢？

首先就是性能上。容易想到，一个系统关于订单的操作肯定是时间越新的需求性越高，而且增长的订单一般都是加入到确定的一张表上。这样很容易带来性能问题，可想而之，第一个月的第一天和最后一天的查询性能必然差异巨大（在订单量多的情况下）。

第二个就是扩展性的问题。由于按照年月固定的分库分表的方式，导致其无法平行扩容。数据没有做到冷热分离，系统对热数据的需求相对集中，而这部分数据库的压力较大，剩下部分的数据库压力较小。

所以按照年月分表的方式，对于需求量大的数据存储来说不太合适。

针对以上问题，我们容易想到我们需要一种方式负载均衡，它需要对所有的数据库的需求从理论上来说应该是相同的。

我们可以按照什么来分表呢？

首先可以按照天来分表，相比于年月，以天来分显然更方便。一般来说，30天前的数据访问量会很小，而且一般订单的状态不会做修改。我们可以使用主从同步，热数据在主数据库，冷数据在从数据库（主要提供查询）。另外我们也需要选取订单号的某些固定部分来作为分库分表的依据。

另外ÿ