【无中生有】---5---分布式数据访问层设计思路

分布式数据访问层有一个问题，那就是如何向同结构的多个数据库请求数据

如果是已存在的数据，则相对容易处理，就是根据数据的id的起始字，就是第一个数字判断位于哪个库

当然，这就要求每个库的起始id比较大，最好设置为千万级别。

由于系统设定目标为使用类型阿里云、卓越云这样的虚拟硬件环境，那种有钱买千万一台小型机的土豪的技术实现就不做讨论了，土豪们自有小型机下的实现。

既然是无中生有，当然是白手起家，坚决不拼硬件，所以假设数据库将实例所在服务器性能充分利用了，一台机器承载了一个库，就当机器便宜的只能承载一张表千万级别用户的数据.

这就涉及了系统切割的问题：是横向扩展还是垂直分离？

这里有一个关于编程逻辑实现位置的问题，那就是存储过程的实现。

许多人喜欢将功能逻辑实现在存储过程里，如果是蛮力式的横向扩展-------数据库同步复制相互间没有差异，问题不大，但是一旦是垂直切割型的分离式扩展，那么就悲剧了，存储过程所在库有可能使用的表不存在。所以存储过程实现复杂逻辑过程在单机数据库时性能好，容易维护，一旦分布式数据存储就不适应了。而这决定了存储过程也只能作为高性能数据简单查询的实现手段。

那么数据访问层面对差异化非蛮力的横向扩展时就面临一个问题，如何判断数据所在库。前面讨论了以id第一个起始字作为判断，但是如果数据是用户名或者guid的？莫非要做一个数据存储的索引？

那么就发产生一个问题，每次进行业务查询之前需要进行一次索引查询，不管索引是数据库还是分布式缓存方式存储的-----性能是浪费的。而比较简单的方法则是采用哈希分块或者模计算。

采用哈希方法，需要对哈希值分区，然后指定不同区哈希访问那些数据库，这还需要一个存储哈希分区的存储

最简单的就是对数据进行模计算，由于系统设定目标很小，就简单设为模10计算，能有10台数据库横向扩展对于小型公司业务系统也算可以了。

通常下，我们不可能一次上10台数据库的，初始的时候无论计算模值多少都是去一个库。

而配合着使用id首字取值的方式，就有了一个问题，在第一个数据库计算和存储能力到达极限时需要迁移模计算和id开头不是1的不属于一号库的数据出来。如果服务可以中断，就没什么好说的，挂上暂停接客的牌子，停止站点服务，复制数据导入，更改连接字符串的配置，然后测试上线就ok了。但是万一需要不中断服务怎么办？

这是一个问题，求解中......

此系列以技术积累一般（没有超级牛人）的组织为目标，数据量根本就不打算向阿里和企鹅的方向去想，设计目标够用就行，没成为GCC流传度软件那样的妄想。

所以，如果不是那种会害人产生经济损失或者技术上确实太丢人的bug，希望大家拿砖轻砸。