分布式数据访问与同步场景浅析

阅读更多

分布式数据访问与同步场景浅析(Simple Ideas on Distributed Data Manipulation Things)

王福强(Darren.Wang)


Table of Contents

1. FK Data Store From The Front
2. FK Data Store From The Backend
3. The end

其实不想说这东西, 因为我也不知道正宗不正宗,完善不完善, 而且, 往简单了说,就2点, 简单的要死, 不过,我感觉我要真的不说,有些人可能也真的不知道我在说什么,而且今天有点儿小破事儿, 也促使我 就此 嚼嚼舌头 。当然一家之言, 看官自己掂量。

随着应用数据规模的增长, 相应的数据库集群自然而然的浮出水面, 进而, 为了应用和管理位于这些数据库集群中的海量数据,你通常会提供一个分布式的数据访问层, 由这一层来屏蔽分布式环境下数据库集群的数据访问复杂度,此为一;另外,你要保证系统的高可用性, 或许会对数据库集群整体或者某些节点进行备份, 这些备份或许发生在在同一个数据中心,或许发生在位于不同地理区域内的数据中心, 因此,你或许会寻求数据复制技术来达此目的,此为二;另外,面对海量的数据,不同的应用有不同的使用角度,如何将同一份数据有效的分发给不同的应用来使用,也是需要你来考虑的问题。

要处理这些东西, 我们可以以数据存储为中心, 从前面和后面两个角度来解决。 Just like this:

分布式数据访问与同步场景浅析_第1张图片

 

1. FK Data Store From The Front

不用说大家都知道, 要做数据访问(不管他是不是分布式的), 指定得从数据存储前面进行。 分布式的数据访问解决方案大都如此, 要是我漏了啥,欢迎补充,呵呵。

尽管都是为了做分布式的数据访问, 大家的具体解决方案可能会稍有不同, 比如, 我们的DAL或许只是一个简单的jar随应用一同部署, 又或许我们的DAL是一个独立的服务, 比如MySQL Proxy, Ameoba等。

不过, DAL不单单就这点儿料儿, 我们还可以让它帮我们做数据同步与数据备份之类的事情, 打个比方, 在做数据访问的同时,我们可以将同一笔数据的更新分发给其它服务节点, 这包括(但不限于):

  • 分发数据给search index builder, 以便实时的构建search index;

  • 分发数据给备份节点, 以便做数据冗余备份;

  • 分发数据给其它应用的数据存储,以便应用可以根据情况来进行相应的数据处理, 而不用对主要的数据服务造成访问压力;

 

当然, 从DAL这一层或者说数据存储前端处理我们之前提到的那些关注点,最好提前对整个系统的状况进行评估,以便DAL的设计可以在后期不会受到很大的冲击。而且,像避免DAL成为单点之类的HA关注点,也都是需要在设计DAL的时候要考虑的。

2. FK Data Store From The Backend

从数据存储服务的屁股后面当然没法做数据访问啦,但我们可以做除了数据访问之外的事情,比如我们在前面提到的一些功能,像实时构建search index啦, 数据的备份啦之类。

那么如何从数据存储服务的屁股后面扣东西那? 以RDBMS为例, 大部分vendor的产品都会包含事务日志的记录, 比如Oracle的redo log, MySQL的binlog等, 数据库会将数据的变更记录到他们相应的事务日志中,而我们也就可以通过监听相应事务日志的变化来获取数据的变化, 拿到这些数据的变化,你还用担心不知道怎么用它们吗?

不过这种方式有些时候也不见得行得通, 像MySQL这样开源的数据库,它的内部实现以及协议之类的资料都可以找到,这种方式显然行的同;而像Oracle这样的商业产品, 它的内部实现以及相关协议是不公开的, 要强行走这条路,你或许要花费很大的力气去hack它的内部协议,而且还不见得最终hack出来的东西完全正确。

总之, 有些路并非总是一路坦途,呵呵

3. The end

应该说, 这两个角度的方案都不见得尽美, 但合适的场景选择合适的方案, 甚至结合起来使用, 这些方案完全可以帮助你达成目标。

What do u think about what I said? bullshit(fucking easy)? or something that's useful to you? Your feedback will be welcome.

  • 分布式数据访问与同步场景浅析_第2张图片
  • 大小: 30.6 KB
  • 查看图片附件

你可能感兴趣的:(MySQL,Oracle,Gmail,F#)