<插曲>目前对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节点返回
说的还是有些乱，东西太多，自己思路老是跑到如何实现上去了，先这么着吧，能把自己的目标先描述清楚了再说。

1. the new trend is to replace db with cache, because of performance and huge data set. But this depends on your particular app. If you don't need it, don't worry about it.

2. cache could have transactions, just most of the implementations don't. Gemstone and Tangosol both have. But where do we enforce transactions is more application dependent(e.g., at the service level, rather than DAO level), this is a very careful design decision.

3. Yes, there are a lot of combinations here, but again, this is application dependent and the design decision does make a big difference. Optimize it and don't overoptimize it(meaning causing the system unstable). There is an old saying, an exact measurement worths a thousand experts' opinion.

Just my two cents.

谢谢点评！我就不用英文回复了，因为我用五笔，打汉字很快，呵呵。我还在继续学习中，乱七八糟想的东西还需要大家多指点。