<插曲>目前对key-value分布式集群数据库的认识（继续坚持）

通过论坛上大侠们的指点，以及跟“菜鸟”童鞋的交流，发现我原来的有些认识是错误的或有偏差的，如下：
1. 被cache所迷惑，误把distributed cache看成了distributed db，现在的理解是cache只是对db的增强（其实一直是这样，只是加上了个分布式就把我自己搞乱了）
2. 对cache进行事务处理，再由cache与storage同步是对事务的割裂，也就不能再称之为事务了
3. db不一定非得是server mode，一个db server + 一个app server与两个app server with local db是一样的道理

关于一致性哈希的最新认识：当一个节点宕掉时，对应区间的数据将会写到下一节点；因此就涉及到数据复制以及数据版本的问题。追加一句：Master/Slave模式并不是可靠的，呵呵
另一种就是B+树处理方式，需要进一步学习。现在先只看哈希方式。

同时，目前比较倾向于以下这种方案框架（在“菜鸟”的“勾引”和对dynamo的学习下形成的）：
1. app server + local storage（可加缓存机制，合称db）作为一个节点
2. 节点间的事务和数据同步由框架来完成，对APP是透明的
3. APP开发者只需要会使用框架的API即可，不需要关注数据存储方式（交由数据管理员配置）
4. 通过框架可进行各db的规则配置，比如A、B节点hash值等
5. N、W、R思想及数据版本处理（原来这才是局部一性，全部一致的问题啊，呵呵）
6. 前端的连接（如HTTP连接）具体到哪个节点由DNS负载均衡处理，分为两种方式：
   - 请求A节点时框架判定B节点更合适，那么由B节点提供给A节点数据，由A节点返回
   - 请求A节点时框架判定B节点更合适，将连接转交给B节点，由B节点返回
说的还是有些乱，东西太多，自己思路老是跑到如何实现上去了，先这么着吧，能把自己的目标先描述清楚了再说。