3.4 小结

分表分库的解决方案就讲完了，这也是业界常用的做法。这个方案实现以后，项目组对它做了一些压力测试，1亿订单量的情况下，基本上也能做到20毫秒之内响应。

后来，随着业务的发展，在分表分库系统上线的11个月后，日订单量达到了100万。事实证明，在大数据时代，提前考虑大数据量的到来是必要的。

不过系统在营销高峰期还是出了问题：宕机1小时。但问题不在订单数据库这边，而是出现在一个商品API服务的缓存上。订单数据库和商品API服务分别由订单组和商品组负责。

回到这个方案，它在订单读写层面基本是足够的，至少保证了数据库不会宕机，不会因为订单量大系统就撑不住。

不过该方案还有一些不足之处。

1）复杂查询慢：很多查询需要跨订单数据库进行，然后再组合结果集，这样的查询比较慢。业界的普遍做法是前面提到的查询分离。第2章讲了单独使用Elasticsearch做查询分离的方案，这里分表分库的二期项目也进行了查询分离，只是查询数据存到了Elasticsearch和HBase中。Elasticsearch存放订单ID、用来查询关键字的字段以及查询页面列表里用到的字段，HBase存放订单的全量数据。Elasticsearch先根据用户的查询组合返回查询结果到查询页面。用户点击特定的订单，就能根据订单ID去HBase获取订单的全量数据。

2）增量数据迁移的高可用性和一致性：如果是自己编写迁移的代码，那就参考前面冷热分离和查询分离的迁移逻辑；也可以使用开源工具，这个方案在后面数据同步的场景中会单独展开。

3）短时订单量大爆发：分表分库可以解决数据量大的问题，但是如果瞬时流量非常大，数据库撑不住怎么办？这一问题会在后面的缓存和秒杀架构等场景中专门展开。

至此，数据持久化层的所有场景就介绍完了。之后将进入缓存层场景实战。