写本文的初衷是由于最近在看《大规模分布式存储系统》，期间有不少疑问以及一些新的认识。这里就准备把自己的疑问和认识记录一下，供以后回炉知识点。这里行文的逻辑大致是以不同的数据库产品或者技术展开，可能会显得比较乱。而且，就目前来说，我对各种分布式数据库的理解都还很肤浅，本文权当自娱自乐了，摘抄很多。
1. Hbase/BigTable
作者在书中把Hbase定义为分布式表格系统，其实也没有什么毛病。Hbase的事务支持相当有限，只支持行级事务。Hbase的系统架构图如下：
Client：包含访问HBase的接口，并维护cache来加快对HBase的访问，比如region的位置信息
Master：为Region server分配region，负责Region server的负载均衡，发现失效的Region server并重新分配其上的region，管理用户对table的增删改查操作
Region Server : Regionserver维护region，处理对这些region的IO请求，Regionserver负责切分在运行过程中变得过大的region
Zookeeper：通过选举，保证任何时候，集群中只有一个master，Master与RegionServers 启动时会向ZooKeeper注册，存贮所有Region的寻址入口；实时监控Region server的上线和下线信息。并实时通知给Master；存储HBase的schema和table元数据
从上面的这些简单介绍就可以看出，Hbase的设计是绝对的AP设计。无论是多DataNode，还是多HRegionServer，还是引入ZooKeeper集群，都是为了Hbase的可扩展性和高可用性。
2. Spanner数据库
Google最早期的业务也是较多地使用了MySQL数据库。然而Google逐渐意识到MySQL的两个比较大的缺陷——扩展性缺失和可靠性缺失。扩展性缺失是指MySQL的主流用法仍然是单体应用，虽然业界也存在各种构建MySQL集群的中间件，但基本没有在数据一致性和完善事务支持两点上做的很好的。
Spanner相当于是BigTable以及MegaStore的升级版本。用阿里正祥前辈的说法，“Spanner在世界上首次实现了跨越地域尺度的ACID”，而且Spanner是支持水平扩展的。
Universe：一个Spanner部署实例称之为一个Universe。目前全世界有3个。一个开发，一个测试，一个线上。因为一个Universe就能覆盖全球，不需要多个。
Zones：每个Zone相当于一个数据中心，一个Zone内部物理上必须在一起。而一个数据中心可能有多个Zone。可以在运行时添加移除Zone。一个Zone可以理解为一个BigTable部署实例。
Universemaster：监控这个universe里zone级别的状态信息
Placement driver：提供跨区数据迁移时管理功能
Zonemaster：相当于BigTable的Master。管理Spanserver上的数据。
Location proxy：存储数据的Location信息。客户端要先访问他才知道数据在那个Spanserver上。
Spanserver：相当于BigTable的ThunkServer。用于存储数据。
Spanner的不同SpanServer之间是以Paxos协议联系起来了，Paxos保证了Spanner的强一致性。在这一点上，Spanner和Zookeeper很像，它们都是强一致性的。但是，Spanner的可用性其实也是非常高的。因此看来，CAP虽然不可完全兼得，但是工程进步还是可以扩充CAP的性能的。
3 OceanBase数据库
OceanBase是阿里巴巴的数据库产品，现在阿里云已经可以使用OceanBase数据库服务了。这说明OceanBase的技术已经比较成熟了。OceanBase的设计目标其实和Spanner非常相似的。
RootServer：管理集群中的所有服务器，子表（tablet）数据分布以及副本管理。 RootServer一般为一主一备，主备之间数据强同步。
UpdateServer：存储OceanBase系统的增量更新数据。UpdateServer一般为一主一备，主备之间可以配置不同的同步模式。部署时，UpdateServer进程和RootServer进程往往共用物理服务器。
ChunkServer：存储OceanBase系统的基线数据。
MergeServer：接收并解析用户的SQL请求，经过词法分析、语法分析、查询优化等一系列操作后转发给相应的ChunkServer或者UpdateServer。如果请求的数据分布在多台ChunkServer上，MergeServer还需要对多台ChunkServer返回的结果进行合并。客户端和MergeServer之间采用原生的MySQL通信协议，MySQL客户端可以直接访问MergeServer。
个人愚见，OceanBase和Spanner还是有很多相似之处的，尤其是在宏观结构上。OceanBase的一大特色是把数据分为基线数据 + 增量修改。
UpdateServer主要使用内存来完成更新操作（事务日志会写盘），所以并发事务处理能力非常强。然而，这样的结构存在一个问题，就是UpdateServer内存有限，不能长时间的顶住大量事务。为了应对这样的问题，OceanBase使用了多集群切换的方式，用“车轮战”的方式来应对高并发的事务。主集群顶住事务流量，其他集群则趁这个机会快速把修改增量合并到基线数据中，以准备接下来继续高效服务。
好吧！夜深了，就先写到这里。
最近又是非常的急躁、迷茫。希望自己能快点调整过来，找到属于我的出口！
发表评论