数据复制的几种方案

     清明节，居然下雨，正好有时间看电影，在youku上把<<将爱>>看完了。

     先留个位置，抛出几个点来，以便以后补充。最近一阵子时间，看了 hbase,tair,redis 项目的代码，加上之前的一些积累，在数据复制上这几个项目有些不同，其中 hbase 与 hadoop 是一样的， redis 与 tair 较相似。主要有以下几种方案：

1.         一种是典型的数据仓库架构，一次写多次读。时间拉的比较长，一般的分布式系统都会选择三个副本，因此在这种设计时，会一次性写三个副本，只要其中有个副本失败了，就需要重写。这样的优点就是，一旦写完了三个副本后，基本上不会丢失数据，故可靠性要高，但是一致性要差一些，写三个副本的时间是很长的，因此读操作需要等三个副本都写完后，才能进行读操作。

2.         另外一种就是分布式内存缓存架构，一般是先将数据写到主结点上，然后由主结点去同步到从结点。像 memcache,tair,redis 等，都是这种方式。但是这会有个问题，如果数据还没有同步到其他结点，而主结点挂了，那么数据就会丢失。所以牺牲可靠性，增加可用性。而对于内存缓存这种架构，就是可以接受数据丢失。

3.         对于第二种，还有一种办法，可以使得数据不会丢失，保证数据的可靠性，那就是分布式 mysql 集群的方法，在主结点上记上日志，哪怕数据丢失，也可以通过日志找回。但是写日志是要消耗性能，同时 mysql 又再次利用日志来减少主从结点的数据传输，这样又利用起了日志，来减少网络传输时间等。

综上所述，任何一种系统都有利弊存在的，关键点就是要把握系统的根本目的或者说需要解决的问题。

另外一致性对于分布式来说也是非常重要的一点，与关系型数据库有非常明显的区别。接下来攻克 zookeeper ，了解分布式一致性的解决方案。

题外话：昨晚看 hive 最新进展时，发现 hive 加入了表锁的机制，还有一个 bitmap index 的实现，二个新特性在实际的应用背景都是很实在的东西。还有一点，当大家用 hive 多了，对用户与表进行分组管理，显得很重要，这样大家能够共享一个元数据库，好处很多，要是可以达到关系型数据库那种表和用户的管理模式，那将会是hive的一大进步啊。

       另外，最近大家都讨论流处理以及实时计算，而目前这种处理方式都是像 KV 内存系统来完成的。还没有发现有可以作汇总和复杂统计处理的系统，更多的人或许会倾向 s4 或者 google 的那个增量处理框架。