有哪些分布式数据库,实现最终一致性的(分布式数据库与集中式数据库的区别)

一个分布式数据库在用户面前为单个逻辑数据库，但实际上是由存储在多台计算机上的一组数据库组成

在几台计算机上的数据库通过网络可同时修改和存取，每一数据库受它的局部的DBMS控制

分布式数据库中每一个数据库服务器合作地维护全局数据库的一致性

在系统中的每一台计算机称为结点

如果一结点具有管理数据库软件，该结点称为数据库服务器

如果一个结点为请求服务器的信息的一应用，该结点称为客户

在ORACLE客户，执行数据库应用，可存取数据信息和与用户交互

在服务器，执行ORACLE软件，处理对ORACLE数据库并发、共享数据存取

ORACLE允许上述两部分在同一台计算机上，但当客户部分和服务器部分是由网连接的不同计算机上时，更有效

分布处理是由多台处理机分担单个任务的处理

在ORACLE数据库系统中分布处理的例子如：客户和服务器是位于网络连接的不同计算机上

单台计算机上有多个处理器，不同处理器分别执行客户应用

SQLNET是ORACLE网络接口，允许运行在网络工作站的ORACLE工具和服务器上，可存取、修改、共享和存储在其它服务器上的数据

SAQLNET可被认为是网络通信的程序接口

SQLNET利用通信协议和应用程序接口（API）为OARCLE提供一个分布式数据库和分布处理

SQLNET驱动器为在数据库服务器上运行的ORACLE进程与ORACLE工具的用户进程之间提供一个接口

参与分布式数据库的每一服务器是分别地独立地管理数据库，好像每一数据库不是网络化的数据库

每一个数据库独立地被管理，称为场地自治性

场地自治性有下列好处：◆系统的结点可反映公司的逻辑组织

◆由局部数据库管理员控制局部数据，这样每一个数据库管理员责任域要小一些，可更好管理

◆只要一个数据库和网络是可用，那么全局数据库可部分可用

不会因一个数据库的故障而停止全部 *** 作或引起性能瓶颈

◆故障恢复通常在单个结点上进行

◆每个局部数据库存在一个数据字典

◆结点可独立地升级软件

可从分布式数据库的所有结点存取模式对象，因此正像非分布的局部的DBMS，必须提供一种机制，可在局部数据库中引用一个对象

分布式DBMS必须提供一种命名模式，以致分布式数据库中一个对象可在应用中唯一标识和引用

一般彩在层次结构的每一层实施唯一性

分布式DVMS简单地扩充层次命名模型，实施在网络上唯一数据库命名

因此一个对象的全局对象名保证在分布式数据库内是唯一

ORACLE允许在SQL语句中使用佤对象名引用分布式数据库中的模式对象（表、视图和过程）

在ORACLE中，一个模式对象的全局名由三部分组成：包含对象的模式名、对象名、数据库名、其形式如：SCOTT

EMP@SALES

DIVISION3

ACME

COM其中SCOTT为模式名,EMP为表名,@符号之后为数据库名

一个远程查询为一查询,是从一个或多个远程表中选择信息,这些表驻留在同一个远程结点

一个分布式查询可从两个或多个结点检索数据

一个分布式更新可修改两个或两个以上结点的数据

一个远程事务为一个事务,包含一人或多个远程语句,它所引用的全部是在同一个远程结点上

一个分布式事务中一个事务,包含一个或多个语句修改分布式数据库的两个或多个不同结点的数据

在分布式数据库中,事务控制必须在网络上直辖市,保证数据一致性

两阶段提交机制保证参与分布式事务的全部数据库服务器是全部提交或全部回滚事务中的语句

ORACLE分布式数据库系统结构可由ORACLE数据库管理员为终端用户和应用提供位置透明性,利用视图、同义词、过程可提供ORACLE分布式数据库系统中的位置透明性

ORACLE允许在SELECT(查询)、INSERT、UPDATE、DELETE、SELECTFORUPDATE和LOCKTABLE语句中引用远程数据

对于查询，包含有连接、聚合、子查询和SELECTFORUPDATE，可引用本地的、远程的表和视图

对于UPDATE、INSERT、DELETE和LOCKTABLE语句可引用本地的和远程的表

注意在引用LONG和LONGRAW列、序列、修改表和封锁表时，必须位于同一个结点

ORACLE不允许作远程DDL语句

在单场地或分布式数据库中，所有事务都是用COMMIT或ROLLBACK语句中止

ORACLE提供两种机制实现分布式数据库中表重复的透明性：表快照提供异步的表重复；触发器实现同步的表的重复

在两种情况下，都实现了对表重复的透明性

可以的，将两台机器都接到路由上后，将80映射到一台电脑的内网IP上，另外一台映射8080端口，这样两台机器就可以架设两个不同的web服务器了，访问的时候一台机器直接输入ip地址因为80端口是默认web端口，另外一台访问时候需要在IP后加上 ：8080，例如:>

java的某些项目为什么要采用分布式开发，分布式开发

在数据库应用程序的开发过程中，网络已走到社会的各个角落。从金融行业的银行联网、交通行业的售票系统、公安系统的全国户籍管理等等，这些企业或行业单位之间地理分布性或业务分布性，使得一个企业或行业拥有多个网络服务器，如何在这种分布式的网络环境下实现高效的数据库应用程序的开发是一个重要的问题。

分布式应用开发简单的说，是指将用户界面、控制台服务、数据库管理三个层次部署在不同的位置上。其中用户界面是客户端实现的功能，控制台服务是一个专门的服务器，数据管理是在一个专门的数据库服务器上实现的。

提示：这里的Web服务器，都是指软件（如IIS等Web服务器软件），它和Web服务器应用以及其它程序等，共同存在于服务器计算机上。

控制台CGI应用：是一个独立的控制台EXE。它在一个标准输入设备上接收客户端的请求信息，在标准输出设备上将结果返回给服务器。

分布式数据库系统已经成为信息处理学科的重要领域，正在迅速发展之中，原因是什么？

1、它可以解决组织机构分散而数据需要相互联系的问题。比如银行系统，总行与各分行处于不同的城市或城市中的各个地区，在业务上它们需要处理各自的数据，也需要彼此之间的交换和处理，这就需要分布式的系统。

2、如果一个组织机构需要增加新的相对自主的组织单位来扩充机构，则分布式数据库系统可以在对当前机构影响最小的情况下进行扩充。

3、均衡负载的需要。数据的分解采用使局部应用达到最大，这使得各处理机之间的相互干扰降到最低。负载在各处理机之间分担，可以避免临界瓶颈。

4、当现有机构中已存在几个数据库系统，而且实现全局应用的必要性增加时，就可以由这些数据库自下而上构成分布式数据库系统。

5、相等规模的分布式数据库系统在出现故障的几率上不会比集中式数据库系统低，但由于其故障的影响仅限于局部数据应用，因此就整个系统来讲它的可靠性是比较高的。

转载表面上看，是一套基于B/S方式实现的分布式管理系统，但其实背后的架构是基于C/S完成的。你以为他是一只鞋吗？其实他是一个吹风机。作为界面化的系统，浏览器框架是不可或缺的，但更加重要的东西在Socket上面。

一、需要解决中央控制端到各节点服务器之间的通信。

这个其实牵扯到一个通信协议的问题，各语言都有自己的socket，thread的库，直接调用即可。但是这个通信协议就需要自己来完成了。既不能太简单，太简单了，明码传输，如果别人获知了这个接口，就很容易执行一些令人讨厌的 *** 作。也不能太复杂，太复杂了等于是给自己找麻烦，所以简单的数据包编解码的工作或者用token验证的方式是需要的。通信协议起码要两种，一种是传输命令执行的协议，一种是传输文件的协议。

二、跨语言的socket通信

为什么要跨语言，主控端和代理端通信，用什么语言开发其实无所谓。但是为了给自己省事，尽可能使用服务器上已经有了的默认语言，Ambari前期采用phppuppet的方式管理集群，这不是不可以，puppet自己解决了socket通信协议和文件传输的问题，可你需要为了puppet在每台服务器上都安装ruby。我是个有点服务器和代码洁癖的人。光是为了一个puppet就装个ruby，我觉得心里特对不起服务器的资源。所以我自己写了一个python的代理端。python是不管哪个linux系统在安装的时候就都会有了。然后主控端的通信，可以用python实现，也可以用php实现，但是考虑到对于更多的使用者来说，改php可能要比改tornado简单许多，所以就没用python开发。hadoop分支版本众多，发布出去，用户要自己修改成安装适合自己的hadoop发行版，就势必要改源码，会php的明显比会python的多。php里面的model封装了所有的 *** 作，而python只是个 *** 作代理人的角色而已。

所以也延伸出一个问题，什么语言用来做这种分布式管理系统的代理端比较合适，我自己觉得，也就是python比较合适了， *** 作系统自带，原生的package功能基本够用。用java和php也可以写agent，但是你势必在各节点预先就铺设好jre或者php运行环境。这就跟为什么用python和java写mapred的人最多是一样的。没人拦着你用nodejs写mapred，也可以写，就是你得在每个节点都装v8的解释引擎，不嫌麻烦完全可以这样干。原理参看map/rece论文，不解释。perl也是 *** 作系统原生带的，但是perl的可维护性太差了，还是算了吧。

所以这就牵扯到一个跨语言的socket问题，理论上来说，这不存在什么问题。但这是理论上的，实际开发过程中确实存在问题，比如socket长连接，通信数据包在底层的封装方式不同。我没有使用xml-rpc的原因之一就是我听说php的xmlrpc跟其他语言的xmlrpc有不同的地方，需要修改才能用,我就没有用这种办法。最早是自己定义的 *** 作协议，这时就遇到了这些问题，所以后来直接采用了thrift方式。就基本不存在跨语言的socket通信问题了。

三、代理端执行结果的获取

无论命令还是文件是否在代理端执行成功，都需要获取到执行结果返回给中央端。所以这里也涉及一个读取节点上的stdout和stderr的问题。这个总体来说不是很难，都有现成的包。当然这个时候你需要的是阻塞执行，而不能搞异步回调。

还有个问题是，我要尽可能使用python默认就带的包，而尽量不让服务器去访问internet下载第三方的包。

还有代理端最重要的一点，就是python的版本兼容性。centos5用python24，centos6用python26，ubuntu基本默认都是27。所以一定要最大限度的保证语言的跨版本兼容性，要是每个 *** 作系统和每一个版本我都写一个代理，我一个人就累死了。

四、浏览器端的model，view，controller

这里面你要封装好所有的通信协议，以及需要在节点上面执行的脚本。发送文件的 *** 作和数据库 *** 作也要在model里面完成。

如果对tcl/tk很熟，也可以写基于 *** 作系统界面方式的管理，不用浏览器就是了。

view对我来说是最痛苦的事，都是现学的jQuery怎么用，前端的工作太可怕了。关于这方面，没有太多可描述的，html和js带给我的只有痛苦的回忆，万恶的undefined。

五、跨 *** 作系统的安装文件封装。

要适应不同的 *** 作系统也是个很麻烦的事情，需要用agent提前获知 *** 作系统的发行分支，版本号。然后去找到对应的安装文件去执行。你不能保证一个分布式系统的集群中所有的节点都可以访问internet，更多的情况是这些节点都存在在一个安全的内网中。只有个别几个节点是可以访问外网的。所以，我势必要把所有的安装文件以及他们的依赖尽可能集中起来。我不确定安装 *** 作系统的lzo，yum或者apt-get会去下什么鬼东西，甚至无论是yum还是apt-get，里面都没有hadoop-lzo的库文件。所以，最好的办法是自己编译打包rpm和deb包。直接安装就好了，别去找repo下载什么。

这就是第五步工作，把需要的依赖的东西自己编译打包成rpm和deb。

deb包很好解决，但是rpm就没那么好办了，需要学习rpm的编译文件如何编写，这块是挺麻烦的，但是这玩意用好了还是挺不错的。现在我自制的安装包里面就已经包含了自己编译的lzo和snappy两种压缩库，以及hadoop-gpl-packaging的rpm和deb。下一个发布的easyhadoop将直接支持centos5,6，suse，以及ubuntu/debian的系统上安装hadoop。已经自带了lzo和snappy以及lzop和snzip。

六、把这些所有东西，整合到一个系统里面。

关联这些所有事情间的联系，整合到一个浏览器界面里面去。写一个分布式的管理脚本不难，写一个界面也不难，但是也许是我的水平不行，这两件事结合起来让他们协同工作还是有点难度的。对我来说，写界面的工作可能更难一点。

Cloudera可能是十来个人在写Manager的东西，ambari也是放到github和apachesvn上面，apache基金会的各种committer在写。easyhadoop没他们功能那么强大，一年来只有我一个人设计架构，功能，各种语言的编码，测试，发布。Fortheloveofgod,WhathaveIdone(英文部分请站在山顶仰天长啸)T_T。从前台到后台，到hadoop和生态系统以及他们的依赖软件的单独patch、编译打包。(系统yum或者apt-get的包不如自己打的好使。)

从时间上来看，全球第一款开源的hadoop部署管理系统应该还是属于ambari，2011年8月开始写的，2012年9月底进入apache的incubator。我是大概2012年8月开始写的easyhadoop，全球第一没赶上，估计国内第一个开源的hadoop管理系统还是可以排上的。

集群服务器
集群，英文名称为Cluster，通俗地说，集群是这样一种技术：它至少将两个系统连接到一起，使两台服务器能够像一台机器那样工作或者看起来好像一台机器。采用集群系统通常是为了提高系统的稳定性和网络中心的数据处理能力及服务能力。
举个例子来说，我们架设了一台>