关于分库策略，大多有三种：
- 业务逻辑
- 流水 id
- hash
而三种策略各有利弊，一般都采用三种策略进行混合运用让数据库进行有效扩容。但不管怎样，以上策略方式都无法实现一个统一让数据库逻辑化和统一化，需要一个单一主服务器进行定位、分流、存放索引。
Google 有句名言，「The datacenter as a computer」。而这个「computer」，应该是众多 Node 的做功的综合体。但是，如果基于上面逻辑，主服务器本身就是一个瓶颈，需要强大的带宽与巨大的内存才能胜任。如果这样的话，假设我有众多小型服务器，我希望它能胜任高性能的查询，于是我还得购买一台终极服务器作为主服务器路由。这至少在经济上说是划不来，对于 datacenter 本身可能在一定程度上违反「The datacenter as a computer」精神。
获得唯一信息场景：
我们设想这么一个场景。有一个班级有 254 个人。我忽然有个比较棘手的问题需要解答，而这 254 个人只有一个人知道答案。我应该怎么做呢？
那我当然不可能一个一个问，我只要站在讲台上：谁知道现在一台笔电要多少钱？
现在我只要等待那个知道答案的人站起来告诉我答案就可以了。
存放信息场景：
设想这么一个场景。有一个班级有 254 个人。这 254 个人每个人都有一个口袋可以装10个东西。
现在我手上有一个东西（笔电），需要给他们其中一个人放着，日后我再跟他要回来。
我只要站在讲台上：这东西我放这儿了，你们谁有空间就来拿走吧。
于是口袋有空间的人上来取得这个东西。当然只有一个人可以拿走。
存放场景2：
我有一个东西，但需要100个口袋才能装得下。这时我放到了讲台，让有剩余口袋的人上来取得。来了20个人。
于是我把东西从头到脚，拆了20份，每一份上面贴个编号，分发给20个人。
当下一次我需要这东西的时候，我再次喊话：那玩意谁有？
20个人上来，我按照编号一一组装起来变成大物件。
到这里就叙述完毕了。这里的「我」，可以是班级中 254 个人的任何一个。每个人都能进行喊话以及分发任务。
这种方式十分适合在局域网中利用广播进行。具体方式就不详细了。
ps: 我发现这基本跟MapReduce差不多。不过也有明显的差异：
没有主服务器记录节点数据，也就无所返回（或许可以有Hit记录进行单点加速优化），所以采取的是 Server 主动连接 Client 的方式（广播地址含有 Client 的信息）。
还有一个没有说明，可以专门设置广播机器（与所有服务器具有长连接属性）。但数据读取与传输方式是 Client 和云之间直接进行无需通过广播器。