推荐:我总结了72个面试问题，共3170页，首战30+互联网公司offer(含BATJM)2020。这次Java面试magic Plus版让我成功获得了阿里、JD.COM、字节跳动等大厂商的offer崇拜！阿里内部在推的K8S(kubernetes)学习指南，不能再详细了。当业务规模达到一定规模时，淘宝的日订单量在5000万以上，美团在3000万以上。 面对数据库的海量数据压力，需要对数据库和表进行划分。 但是数据库划分和表划分后的少量常规查询可能会产生问题，最常见的就是分页查询。 一般我们称子表的字段为shardingkey。例如，order表是根据客户ID的shardingkey。那么，如果查询条件中没有客户ID，如何对查询进行分页呢？比如没有shardingkey的多维查询比较多，怎么查询？唯一主键一般我们数据库的主键都是自增的，所以表拆分后主键冲突的问题是不可避免的问题。最简单的方法是使用唯一的业务字段作为唯一的主键，例如，订单表的订单号必须是全局唯一的。 有许多常见的分布式方法来生成唯一ID。最常见的雪花算法有雪花、滴滴Tinyid、美团叶子。 以雪花算法为例，一毫秒可以生成4194304多个id。 当不使用第一个数字时，默认为精确到毫秒的0.41位时间戳，可以容纳69年。10位工作机ID的前5位是数据中心ID，后5位是节点ID。每个节点每毫秒累加12位序列号，累计数可达2 ^ 12 ^ 4096个id。 第一步子表，如何保证子表后订单号的唯一性，现在考虑子表的问题。 首先根据自身业务量和增量考虑子表的大小。 比如我们现在的日订单量是10万单，估计一年后会达到100万单。根据业务属性，我们一般支持半年内订单的查询，超过半年的订单需要备案结算。 那么，以每天一百万半年的订单计算，如果不分表，我们的订单量将达到一百万x180 = 180亿。如果按这种数据顺序分表，单表是承受不了的。就算能拿RT时间，你也完全接受不了。 按照百万经验表的数量，对数据库没有压力，所以分256个表就够了，1.8亿/256 ≈ 70万。如果你想保险起见，也可以分成512桌。 然后考虑，如果业务量增加10倍到每天1000万单，子表1024是比较合适的选择。 加上半年多的数据归档，单个70万数据的表就足以应对大部分场景。 接下来散列订单号，然后取模256，能落到哪个表？ 然后因为唯一的主键是基于订单号的，你之前写的那些根据主键ID查询的就不能用了，这就涉及到少数历史查询函数的修改。 但这没什么，对吧？改成订单号就行了。 这不是问题，问题在于我们的标题。 c端查询聊了半天，终于说到了点子上。那么如何处理表拆分后的查询和分页查询呢？首先用shardingkey说一下查询，比如按订单号。不管你怎么分页还是什么，都可以直接定位到具体的表进行查询。显然，查询不会有问题。 如果不是shardingkey，如果把订单号作为shardingkey，就像上面例子里说的，app和小程序一般都是按客户ID查询的。此时，我们应该如何处理订单编号碎片？很多公司订单直接用客户ID作为shardingkey，所以很简单，直接查就行了。 那么如何处理订单号，一个很简单的方法就是取订单号上客户ID的属性。 举个很简单的例子，原来的41位时间戳是用不完的，客户ID是10位。订单编号的生成规则带有客户ID。进入具体表时，模块根据订单号中的10位客户ID进行哈希，这样无论订单号还是客户ID，查询效果都是一样的。 当然，这种方法只是一个例子。具体的订单号生成规则，多少位数，包含哪些因素，根据你自己的业务和实现机制来决定。 好了，所以不管你是订单号还是客户ID为shardingkey，都可以用上面两种方式处理问题。 那么还有一个问题:如果既不是订单号也不是客户ID查询怎么办？最直观的例子就是来自商家端或者卖家后端的查询。商家端以商家或卖家的ID作为查询条件，后端查询条件可能更复杂。比如我遇到的一些后端查询条件，可以有几十个。这个怎么查？？？别急，下面分别说一下B端和后端的复杂查询。 现实中的真实流量大部分来自客户端的C端，所以本质上处理了客户端的问题，解决了这个问题的大部分。来自商家卖家B端和后端支持业务的剩余查询流量不会很大，所以这个问题很容易解决。 对于B端的非shardingkey查询，有两种方法来处理其余的端查询。 双写，双写是指订单的数据分两份掉，C端和B端各存一份。对于C端，可以使用单号和客户ID作为shardingkey，对于B端，可以使用商家卖家的ID作为shardingkey。 有的同学会说，你的双写不会影响成绩吗？由于B端可以接受轻微延迟，因此B端订单可以异步下单。 想想吧。你去淘宝买东西，下了订单。卖家延迟一两秒收到订单有什么关系？如果你点了外卖商家，晚一两秒收到这个订单，影响大吗？这是一个处理方案，另一个方案是采取离线仓库或服务器ES查询。订单数据落入仓库后，无论你是通过binlog还是MQ消息将数据同步到仓库还是服务器ES，它们支持的数量级对于这个查询条件来说都是非常简单的。 同理，一定会有轻微的延迟，但这个可控的延迟是可以接受的。 对于管理后端的查询，比如运营、业务、产品等需要看数据的，自然需要复杂的查询条件，也可以通过ES或者几个仓库来完成。 如果不使用这个方案，并且需要无shardingkey的分页查询，兄弟这个只能扫描全表查询聚合数据，然后手工做分页，但是这样查出来的结果有限。 比如你有256块，查询的时候会循环扫描所有块，每块取20块数据。最后，聚集的数据将被手动分页，因此不可能找到所有的数据。 总结一下子库、子表之后的查询问题，有经验的同学其实都知道这个问题，但我相信，其实大部分同学的业务可能达不到这个量级，子库、子表可能都停留在概念阶段。被问到面试的事情后，他们不知所措，因为没有经验，不知道该怎么办。 首先，子数据库和子表是基于现有的业务量和未来的增量。比如拼多多，日单量5000万，半年数据要达到100亿的水平，那就得分4096桌了吧？但实际操作是一样的。没必要把你的业务分成4，096，根据你的业务适当选择。 对于基于shardingkey的查询，我们可以简单处理；对于非分片键查询，我们可以通过输入双数据、数据仓库和专家系统的方案来处理。当然，如果表拆分后的数据量很小，建立索引扫描整个表也不是问题。