数据路由，你造吗？

                                 云智慧（北京）科技有限公司柳东浩

最近互联网都涨思维了，移动互联网更是得瑟地不行，在风口上嗷嗷地飘，PE/VC没事儿就就往那儿蹭，而那物流网的天儿还刚蒙蒙亮，这就是我们这些攻城狮所处的有点儿雾霾的时代。这年头攻城狮总有不寐的夜，为啥纠结呢？还不是让数据给闹的。这里一篇小文只是一盘关于数据的小菜，一款关于数据的管弦谱，怎么演奏，那得看自己，看情况，不解决啥实质问题，该闹还得闹，该纠结还得纠结，谁让你拱呢。

说俩词儿
数据库：就叫D吧，就是你可以把东西放D那儿，回头儿你还可以从D把东西拿出来。跟火车站旁边那个存包的一回事儿，而且也得要身份证，别忘了哈。
机构：提供一个或多个服务的一组机器，他们协同完成一大类事。
下面就唠点正嗑儿，说点行话吧。

问题的产生
任何存储介质，其存储容量总归是有限的。因此，随着业务的发展，甚至突发的业务高峰，水平扩展能力总是不可回避的挑战。这也必然要求数据是分布式存储的，而解决问题的基本指导思想也必然是分而治之，否则那电费、流量费恐怕就不知道翻多少倍了，要命的是生意没法做了，这年头慢的东西就会被淘汰。

数据路由概念
在分布式环境中，对于一个请求而言，总是要决策到哪里去读/写，这就是数据路由问题，也是一个基本问题。写操作决定了读操作，因此写操作中针对具体的设计目标如何分而治之就成为了问题的关键。但是反过来说也是正确的，读的需求决定写的方式，而且应该这样考虑，因为写的目的不仅仅是存在那里，更是要考虑读的过程如何发挥价值。换句话说，数据路由首先要解决写到哪里和如何写的问题，但它是为如何读而准备的。关于写的设计应当是服从于读的方式、方法、形式和策略。就像接力赛一样，你把接力棒放在前面队友的手里就是写，他接到了，跑了，就是读，当你递过去的时候你在想什么？对了，就是应该像你此刻那样想。当你在使用、架构或自研某种广义数据库的时候，你首先考虑接棒了吗？当然这个问题涉及面更广，这里仅仅侃侃“到哪里”的问题-雅名“数据路由”。老是做海底捞，憋不？别淹着，当是潜伏哈。

问题的内在特质与归结
设：
 请求=R <