数据库集群好处

① 数据库集群技术有哪些

数据库集群技术
1)提高数据库处理速度的技术
目前有四种提高数据库处理速度的办法：
◆ 提高磁盘速度：这包括RAID和其他磁盘文件分段的处理。主要的思想是提高磁盘的并发度（多个物理磁盘存放同一个文件）。尽管实现方法各不相同，但是它们最后的目的都是提供一个逻辑数据库的存储映象。我们要评价的六个系统都能有效地利用这些技术。由于ICX已经有最大的磁盘冗余度，RAID 磁盘系统的设置应该侧重于速度，而不是数据冗余。这样磁盘利用的效益就会提高。
◆ 分散数据的存放：主要思想是利用多个物理服务器来存放数据集的不同部分（一个数据库表格分散到多个服务器或者每个服务器分管几个内容不同的表格）。这些办法不但可以扩展数据集（数据集的可扩性），而且使得不同的服务器进行并行计算成为可能。例如，对于ORACLE的RAC来讲，由于它是共享磁盘的体系结构，你只需要简单地增加一个服务器节点，RAC就能自动地将这节点加入到它的集群服务中去。RAC会自动地将数据分配到这节点上，并且会将接下来的数据库访问自动分布到合适的物理服务器上，而不用修改应用程序。对于UDB来讲，因为它是非共享磁盘的体系结构，因此就必须手工修改数据的分区，MSCS和ASE也是同样的情况。Mysql也需要手工分区，并且是这几种数据库中支持分区的自动化程度最低的，也就是说，应用程序需要自己负责数据库的分布式访问。不管数据存放是如何实现的，分布式存放数据的缺点是对数据库的可用性有负面影响。任何一台服务器的损坏都会影响整个系统的可用性。但是，这是迄今为止各大数据库厂商能提供的业界最好的数据库集群技术了。ICX是一种基于中间件的数据库集群技术，它对客户端和数据库服务器都是透明的。因此，ICX可以用来集群几个数据库集群（一个逻辑数据库），也可以用于集群几个物理数据库服务器（来增强一个分管关键数据的物理服务器）。
◆ 对称多处理器系统：此技术的思想是利用多处理机硬件技术来提高数据库的处理速度。但是，除了ICX，所有其它的数据库集群技术只支持单一的可修改的逻辑数据库。绝大部分的数据库事务处理是磁盘密集型的，纯计算负荷很小的，对称多处器技术在数据库上的应用的实际收益是很有限的。这也说明了为什么实际应用中最多只用了四个CPU的原因。所有的基于数据库引擎的集群都支持这个技术，ICX对SMP技术是中性的，因为它能把多个数据库服务器集合在一起构成一个集群，也能将多个现存的数据库集群集合在一起，构成集群的集群。
◆ 交易处理负载均衡：此技术的思想是在保持数据集内容同步的前提下，将只读操作分布到多个独立的服务器上运行。因为绝大多数的数据库操作是浏览和查询,，如果我们能拥有多个内容同步的数据库服务器，交易负载均衡就具有最大的潜力（可以远远大于上面叙述的最多达四个处理器的对称多处理器系统）来提高数据库的处理速度，同时会具有非常高的数据可用性（真正达到5个9，即99.999%）。所有基于数据库引擎的集群系统都只支持一个逻辑数据库映象和一个逻辑或物理的备份。这个备份的主要目的是预防数据灾难。因此，备份里的数据只能通过复制机制来更新，应用程序是不能直接更新它的。利用备份数据进行交易负载均衡只适用于一些非常有限的应用，例如报表统计、数据挖掘以及其它非关键业务的应用。只有ICX能够做到同步复制多个数据库服务器从而达到在保持数据一直性前提下的真正的负载平衡。
上述所有技术在实际部署系统的时候可以混合使用以达到最佳效果。
2）提高数据库可用性的技术
根据物理法则，提高冗余度是提高数据库可用性的唯一途径。
提高数据库冗余度大致有四种方法：
◆ 硬件级的冗余：主要思想是让多处理机同时执行同样的任务用以屏蔽瞬时和永久的硬件错误。有两种具体的实现方法：构造特殊的冗余处理机和使用多个独立的数据库服务器。冗余处理机的造价昂贵，效益很低。实际应用日渐减少。基于数据库的集群系统都是用多个独立的数据库服务器来实现一个逻辑数据库，在任意瞬间，每台处理器运行的都是不同的任务。这种系统可以屏蔽单个或多个服务器的损坏，但是因为没有处理的冗余度，每次恢复的时间比较长，它们需要把被损坏的服务进程在不同的服务器上从新建立起来。ICX让多个独立的数据库服务器作同样的处理。发现处理器问题时的切换不需要重建进程的状态，所以故障屏蔽是极快的。
◆ 通讯链路级的冗余：冗余的通讯链路可以屏蔽瞬时和永久的通讯链路级的错误。基于数据库引擎的集群系统有两种结构：共享磁盘和独立磁盘。RAC, MSCS 和 MySQL CS可以认为是共享磁盘的集群系统。UDB和ASE 是独立磁盘的集群系统。共享磁盘集群系统对网络系统的要求很高，所以通讯的冗余度最小。独立磁盘集群系统可以把磁盘系统独立管理，通讯冗余度较高。 ICX的通讯链路级的冗余度最高，因为它使用的是多个独立的数据库服务器和独立的磁盘系统。 ICX也可以用于共享磁盘系统。 但是冗余度会相应降低。
◆ 软件级的冗余：由于现代操作系统和数据库引擎的高度并发性，由竞争条件、死锁、以及时间相关引发的错误占据了非正常停机服务的绝大多数原因。采用多个冗余的运行数据库进程能屏蔽瞬时和永久的软件错误。基于数据库引擎的集群系统都用多个处理器来实现一个逻辑数据库，它们只能提供部分软件冗余，因为每一瞬间每个处理器执行的都是不同的任务。只有ICX可以提供最大程度的软件级冗余。
◆ 数据冗余：有两类冗余数据集。
被动更新数据集：所有目前的数据复制技术(同步或异步)，例如磁盘镜像（EMC的TimeFinder系列）、数据库文件复制（如DoubleTake, Veritas and Legato）以及数据库厂商自带的数据库备份工具都只能产生被动复制数据集。通常，为了实现复制功能，需要消耗掉主服务器5%（异步）到30%（同步）的处理能力。被动更新的数据一般只用于灾难恢复.被动更新数据集还有两个致命的问题：一旦主处理机故障造成数据损坏，被动更新的数据集也会被破坏。另外，和主动更新系统相比，被动更新系统对数据网络的带宽要求更高。这是因为它缺少交易的信息，很多数据复制是盲目的。
主动更新数据集：这种数据集需要一台（或多台）独立的备份数据库服务器来管理，由于这种数据集及时可用，它可以有多种用途，例如报表生成，数据挖掘，灾难恢复甚至低质量负载均衡。 同样地，这里也有同步和异步两种技术。
◆ 异步主动复制数据集：这种技术是先把事务处理交给主服务器来完成，然后这些事务处理再被串行地交给备份服务器以执行同样的操作来保证数据的一致性。这种技术生成的数据集和主数据集有一个时间差，所以仅适用于灾难恢复、数据挖掘、报表统计以及有限的在线应用。所有的商用数据库都支持异步主动复制技术。这种办法的难度在于复制队列的管理上，这个队列是用来屏蔽主服务器和备份服务器之间的速度差异的。因为主服务器可以尽可能地利用所有软硬件的并发性来处理并发的事务，而备份服务器只能串行地复制，在高负荷事务处理的情况下，复制队列经常可能溢出。因为没有任何办法来控制事务处理请求的速度，在高负荷事务处理的情况下，复制队列只能经常性地重建。因为所有现代数据库系统都支持热备份和LOG SHIPPING。通过精心策划，应该可以实现不关闭主服务器而重建队列。ICX也支持异步主动复制. ICX的复制队列的重建是通过ICX的自动数据同步软件来完成的，所以不需要人工操作。
◆ 同步主动复制数据集：这种技术要求所有的并发事务处理在所有的数据库服务器上同时完成。一个直接的好处就是没有了队列的管理问题，同时也可以通过负载均衡实现更高的性能和更高的可用性。这种技术也有两种完全不同的实现方法：完全串行化和动态串行化。完全串行化的事务处理来自于主数据库的事务处理引擎，RAC, UDB, MSCS (SQL Server 2005) 和 ASE是用完全串行化并结合两阶段提交协议来实现的，这种设计的目标就是为了获得一份可用于快速灾难恢复的数据集。这种系统有两个关键的问题。第一，两阶段提交协议是一种“ALL OR NOTHING”的协议。仔细研究两阶段提交协议后就能发现，为了获取这备份数据集，事务处理的可用性会降低一半。第二，完全串行化的做法又引进了主-从数据库服务器速度不匹配的问题。强制同步造成整个系统的速度被降低到完全串行化的水平。相反，ICX-UDS采用了动态串行复制引擎。这设计可以充分利用多个独立数据库的处理能力。ICX避免了使用两阶段提交协议，因此一个事务处理只有在集群中的所有服务器全都同时崩溃的情况下才会回滚。
为了防灾，必须使用远程网络。 所以我们在这里讨论远程数据复制的办法。这里大概有四种办法。
◆ 动态远程异步复制：这种办法是指主服务器通过远程网串行地把交易复制到备份服务器上。由于主-副之间的速度不匹配，队列管理的问题就很突出。 由于远程网的速度一般都比较慢，队列溢出的概率大大增加。所有的集群系统都支持这种复制办法，只是队列管理的办法不同而已。DM，FM和RAID都不能支持这种办法。RAID只能在局域网内工作。
◆ 动态远程同步复制.：这种办法是指主服务器通过远程网并行地把交易复制备份服务器上。只有ICX 具有这种能力。
◆ 静态远程异步复制.：这种办法是指通过远程网把数据串行地复制（不通过数据库服务器）到异地。DM和FM支持这种复制办法。因为串行处理和队列管理的关系，这对于处理量大的系统不适用。但是这种复制办法对应用是透明的，所有集群系统都可采用.
◆ 静态远程同步复制.：这种办法也是指通过远程网把数据串行地复制（不通过数据库服务器）到异地。不同的是，这里没有队列管理。取代队列管理的是发送端的一个新的协议：每次发送都要等接受端确认复制成功。否则回滚。DM和FM都支持这种复制办法。这种办法只能在短距离范围内工作， 大约5 英里光纤的样子。如果超出这个距离范围的话，显然事务处理回滚的概率就会很高。但是这种复制办法对应用是透明的，所有集群系统都可采用。
3）提高数据库安全和数据集可扩展的技术
在提高数据库安全性和数据集可扩性这两方面，可以创新的空间是很小的。数据库最常见的安全办法是口令保护，要么是分布式的，要么是集中式的。在数据库前面增加防火墙会增加额外的延迟，因此，尽管许多安全侵犯事件是来自于公司内部，但是数据库防火墙还是很少被采用。如果数据库集群技术是基于中间件技术实现的，就有可能在不增加额外延迟的情况下 ，在数据经过的路径上实现防火墙功能。ICX完全实现了这种思想。
数据库数据集的可扩性只能通过将数据分布到多个独立的物理服务器上来实现。为了弥补可用性的损失，ICX能被用来提高整个逻辑数据库或者部分重要服务器的处理速度，可用性和安全性。

② 浅谈数据库集群软件优缺点有哪些

集群（Cluster）是由两台或多台节点机（服务器）构成的一种松散耦合的计算节点集合，为用户提
供网络服务或应用程序(包括数据库、Web服务和文件服务等)的单一客户视图，同时提供接近容错机的故
障恢复能力。集群系统一般通过两台或多台节点服务器系统通过相应的硬件及软件互连，每个群集节点都
是运行其自己进程的独立服务器。这些进程可以彼此通信，对网络客户机来说就像是形成了一个单一系统，
协同起来向用户提供应用程序、系统资源和数据。除了作为单一系统提供服务，集群系统还具有恢复服务
器级故障的能力。集群系统还可通过在集群中继续增加服务器的方式，从内部增加服务器的处理能力，并
通过系统级的冗余提供固有的可靠性和可用性。
二、集群的分类：
1、高性能计算科学集群：
以解决复杂的科学计算问题为目的的IA集群系统。是并行计算的基础，它可以不使用专门的由十至
上万个独立处理器组成的并行超级计算机，而是采用通过高速连接来链接的一组1/2/4 CPU的IA服务器，
并且在公共消息传递层上进行通信以运行并行应用程序。这样的计算集群，其处理能力与真正超级并行
机相等，并且具有优良的性价比。
2、负载均衡集群：
负载均衡集群为企业需求提供更实用的系统。该系统使各节点的负载流量可以在服务器集群中尽可
能平均合理地分摊处理。该负载需要均衡计算的应用程序处理端口负载或网络流量负载。这样的系统非
常适合于运行同一组应用程序的大量用户。每个节点都可以处理一部分负载，并且可以在节点之间动态
分配负载，以实现平衡。对于网络流量也如此。通常，网络服务器应用程序接受了大量入网流量，无法
迅速处理，这就需要将流量发送给在其它节点。负载均衡算法还可以根据每个节点不同的可用资源或网
络的特殊环境来进行优化。

③ 如何保证数据库集群中id的唯一性，假设每秒钟并发20万次

用雪花算法的工具类,1秒内可以生成26万不重复的值,数据库的主键不要自增,手动设置

java">packageentity;

importjava.lang.management.ManagementFactory;
importjava.net.InetAddress;
importjava.net.NetworkInterface;

/**
*<p>名称：IdWorker.java</p>
*<p>描述：分布式自增长ID</p>
*<pre>
*Twitter的SnowflakeJAVA实现方案
*</pre>
*核心代码为其IdWorker这个类实现，其原理结构如下，我分别用一个0表示一位，用—分割开部分的作用：
*1||0------00000---00000---000000000000
*在上面的字符串中，第一位为未使用（实际上也可作为long的符号位），接下来的41位为毫秒级时间，
*然后5位datacenter标识位，5位机器ID（并不算标识符，实际是为线程标识），
*然后12位该毫秒内的当前毫秒内的计数，加起来刚好64位，为一个Long型。
*这样的好处是，整体上按照时间自增排序，并且整个分布式系统内不会产生ID碰撞（由datacenter和机器ID作区分），
*并且效率较高，经测试，snowflake每秒能够产生26万ID左右，完全满足需要。
*<p>
*64位ID(42(毫秒)+5(机器ID)+5(业务编码)+12(重复累加))
*
*@authorPolim
*/
publicclassIdWorker{
//时间起始标记点，作为基准，一般取系统的最近时间（一旦确定不能变动）
privatefinalstaticlongtwepoch=1288834974657L;
//机器标识位数
=5L;
//数据中心标识位数
=5L;
//机器ID最大值
=-1L^(-1L<<workerIdBits);
//数据中心ID最大值
=-1L^(-1L<<datacenterIdBits);
//毫秒内自增位
=12L;
//机器ID偏左移12位
=sequenceBits;
//数据中心ID左移17位
=sequenceBits+workerIdBits;
//时间毫秒左移22位
=sequenceBits+workerIdBits+datacenterIdBits;

=-1L^(-1L<<sequenceBits);
/*上次生产id时间戳*/
=-1L;
//0，并发控制
privatelongsequence=0L;

privatefinallongworkerId;
//数据标识id部分
privatefinallongdatacenterId;

publicIdWorker(){
this.datacenterId=getDatacenterId(maxDatacenterId);
this.workerId=getMaxWorkerId(datacenterId,maxWorkerId);
}
/**
*@paramworkerId
*工作机器ID
*@paramdatacenterId
*序列号
*/
publicIdWorker(longworkerId,longdatacenterId){
if(workerId>maxWorkerId||workerId<0){
(String.format("workerIdcan'tbegreaterthan%dorlessthan0",maxWorkerId));
}
if(datacenterId>maxDatacenterId||datacenterId<0){
(String.format("datacenterIdcan'tbegreaterthan%dorlessthan0",maxDatacenterId));
}
this.workerId=workerId;
this.datacenterId=datacenterId;
}
/**
*获取下一个ID
*
*@return
*/
publicsynchronizedlongnextId(){
longtimestamp=timeGen();
if(timestamp<lastTimestamp){
thrownewRuntimeException(String.format("Clockmovedbackwards.Refusingtogenerateidfor%dmilliseconds",lastTimestamp-timestamp));
}

if(lastTimestamp==timestamp){
//当前毫秒内，则+1
sequence=(sequence+1)&sequenceMask;
if(sequence==0){
//当前毫秒内计数满了，则等待下一秒
timestamp=tilNextMillis(lastTimestamp);
}
}else{
sequence=0L;
}
lastTimestamp=timestamp;
//ID偏移组合生成最终的ID，并返回ID
longnextId=((timestamp-twepoch)<<timestampLeftShift)
|(datacenterId<<datacenterIdShift)
|(workerId<<workerIdShift)|sequence;

returnnextId;
}

privatelongtilNextMillis(finallonglastTimestamp){
longtimestamp=this.timeGen();
while(timestamp<=lastTimestamp){
timestamp=this.timeGen();
}
returntimestamp;
}

privatelongtimeGen(){
returnSystem.currentTimeMillis();
}

/**
*<p>
*获取maxWorkerId
*</p>
*/
(longdatacenterId,longmaxWorkerId){
StringBuffermpid=newStringBuffer();
mpid.append(datacenterId);
Stringname=ManagementFactory.getRuntimeMXBean().getName();
if(!name.isEmpty()){
/*
*GETjvmPid
*/
mpid.append(name.split("@")[0]);
}
/*
*MAC+PID的hashcode获取16个低位
*/
return(mpid.toString().hashCode()&0xffff)%(maxWorkerId+1);
}

/**
*<p>
*数据标识id部分
*</p>
*/
(longmaxDatacenterId){
longid=0L;
try{
InetAddressip=InetAddress.getLocalHost();
NetworkInterfacenetwork=NetworkInterface.getByInetAddress(ip);
if(network==null){
id=1L;
}else{
byte[]mac=network.getHardwareAddress();
id=((0x000000FF&(long)mac[mac.length-1])
|(0x0000FF00&(((long)mac[mac.length-2])<<8)))>>6;
id=id%(maxDatacenterId+1);
}
}catch(Exceptione){
System.out.println("getDatacenterId:"+e.getMessage());
}
returnid;
}


publicstaticvoidmain(String[]args){
//推特26万个不重复的ID
IdWorkeridWorker=newIdWorker(0,0);
for(inti=0;i<2600;i++){
System.out.println(idWorker.nextId());
}
}

}

④ 阿里云分布式数据库服务DRDS谁使用过 简单讲讲！

淘宝开源的TDDL和cobar的结合，放到了阿里云上就是DRDS，是商品，服务，可以购买使用的。可以在阿里云官网上注册免费试用。

=====================================================
随着互联网时代的到来，计算机要管理的数据量呈指数级别地飞速上涨，而我们却完全无法对用户数做出准确预估。我们的系统所需要支持的用户数，很可能在短短的一个月内突然爆发式地增长几千倍，数据也很可能快速地从原来的几百GB飞速上涨到了几百个TB。如果在这爆发的关键时刻，系统不稳定或无法访问，那么对于业务将会是毁灭性的打击。
伴随着这种对于系统性能、成本以及扩展性的新需要，以HBase、MongoDB为代表的NoSQL数据库和以阿里DRDS、VoltDB、ScaleBase为代表的分布式NewSQL数据库如雨后春笋般不断涌现出来。
本文将会介绍阿里DRDS的技术理念、发展历程、技术特性等内容。
DRDS设计理念
从20世纪70年代关系数据库创立开始，其实大家在数据库上的追求就从未发生过变化：更快的存取数据，可以按需扩缩以承载更大的访问量和更大的数据量，开发容易，硬件成本低，我们可以把这叫做数据库领域的圣杯。
为了支撑更大的访问量和数据量，我们必然需要分布式数据库系统，然而分布式系统又必然会面对强一致性所带来的延迟提高的问题，因为网络通信本身比单机内通信代价高很多，这种通信的代价就会直接增加系统单次提交的延迟。延迟提高会导致数据库锁持有时间变长，使得高冲突条件下分布式事务的性能不升反降（这个具体可以了解一下Amdahl定律），甚至性能距离单机数据库都还有明显的差距。
从上面的说明，我们可以发现，问题的关键并不是分布式事务做不出来，而是做出来了却因为性能太差而没有什么卵用。数据库领域的高手们努力了40年，但至今仍然没有人能够很好地解决这个问题，Google Spanner的开发负责人就经常在他的Blog上谈论延迟的问题，相信也是饱受这个问题的困扰。
面对这个难题，传统的关系数据库选择了放弃分布式的方案，因为在20世纪70~80年代，我们的数据库主要被用来处理企业内的各类数据，面对的用户不过几千人，而数据量最多也就是TB级别。用单台机器来处理事务，用个磁盘阵列处理一下磁盘容量不够的问题，基本上就能解决一切问题了。
然而，信息化和互联网的浪潮改变了这一切，我们突然发现，我们服务的对象发生了根本性变化，从原来的几千人，变成了现在的几亿人，数据量也从TB级别到了PB级别甚至更多。存在单点的单机系统无论如何努力，都会面对系统处理能力的天花板。原来的这条路，看起来是走不下去了，我们必须想办法换一条路来走。
可是，分布式数据库所面对的强一致性难题却像一座高山，人们努力了无数个日日夜夜，但能翻越这座山的日子看来仍然遥遥无期。
于是，有一群人认为，强一致性这件事看来不怎么靠谱，那彻底绕开这个问题是不是个更好的选择？他们发现确实有那么一些场景是不需要强一致事务的，甚至连SQL都可以不要，最典型的就是日志流水的记录与分析这类场景。而去掉了事务和SQL，接口简单了，性能就更容易得到提升，扩展性也更容易实现，这就是NoSQL系统的起源。
虽然NoSQL解决了性能和扩展性问题，但这种绕开问题的方法给用户带来了很多困扰，系统的开发成本也大大提升。这时候就有另外一群人，他们觉得用户需要SQL，觉得用户也需要事务，问题的关键在于我们要努力地往圣杯的方向不断前进。在保持系统的扩展性和性能的前提下，付出尽可能小的代价来满足业务对数据库的需要。这就是NewSQL这个理念的由来。
DRDS也是一个NewSQL的系统，它与ScaleBase、VoltDB等系统类似，都希望能够找到一条既能保持系统的高扩展性和高性能，又能尽可能保持传统数据库的ACID事务和SQL特性的分布式数据库系统。
DRDS发展历程
在一开始，TDDL的主要功能就是做数据库切分，一个或一组SQL请求提交到TDDL，TDDL进行规则运算后得知SQL应该被分发到哪个机器，直接将SQL转发到对应机器即可（如图1）。

图1 TDDL数据库切分
开始的时候，这种简单的路由策略能够满足用户的需要，我们开始的那些应用，就是通过这样非常简单的方式完成了他所有的应用请求。我们也认为，这种方案简单可靠，已经足够好用了。
然而，当我们服务的应用从十几个增长到几百个的时候，大量的中小应用加入，大家纷纷表示，原来的方案限制太大，很多应用其实只是希望做个读写分离，希望能有更好的SQL兼容性。
于是，我们做了第一次重大升级，在这次升级里，我们提出了一个重要的概念就是三层架构，Matrix对应数据库切分场景，对SQL有一定限制，Group对应读写分离和高可用场景，对SQL几乎没有限制。如图2所示。

图2 数据库升级为三层架构
这种做法立刻得到了大家的认可，TDDL所提供的读写分离、分库分表等核心功能，也成为了阿里集团内数据库领域的标配组件，在阿里的几乎所有应用上都有应用。最为难得的是，这些功能从上线后，到现在已经经历了多年双11的严酷考验，从未出现过严重故障（p0、p1级别故障属于严重故障）。数据库体系作为整个应用系统的重中之重，能做到这件事，真是非常不容易。
随着核心功能的稳定，自2010年开始，我们集中全部精力开始关注TDDL后端运维系统的完善与改进性工作。在DBA团队的给力配合下，围绕着TDDL，我们成功做到了在线数据动态扩缩、异步索引等关键特征，同时也比较成功地构建了一整套分布式数据库服务管控体系，用户基本上可以完全自助地完成整套数据库环境的搭建与初始化工作。
大概是2012年，我们在阿里云团队的支持下，开始尝试将TDDL这套体系输出到阿里云上，也有了个新的名字：阿里分布式数据库服务（DRDS），希望能够用我们的技术服务好更多的人。
不过当我们满怀自信地把自己的软件拿到云上的时候，却发现我们的软件距离用户的要求差距很大。在内部因为有DBA的同学们帮助进行SQL review，所以SQL的复杂度都是可控的。然而到了云上，看了各种渠道提过来的兼容性需求，我们经常是不自觉地发出这样的感叹：“啊？原来这种语法MySQL也是可以支持的？”
于是，我们又进行了架构升级，这次是以兼容性为核心目标的系统升级工作，希望能够在分布式场景下支持各类复杂的SQL，同时也将阿里这么多年来在分布式事务上的积累都带到了DRDS里面。
这次架构升级，我们的投入史无前例，用了三年多才将整个系统落地完成。我们先在内部以我们自己的业务作为首批用户上线，经过了内部几百个应用的严酷考验以后，我们才敢拿到云上，给到我们的最终用户使用。
目前，我们正在将TDDL中更多的积累输出到云上，同时也努力优化我们的用户界面。PS：其实用户界面优化对我们这种专注于高性能后端技术的团队来说，才是最大的技术挑战，连我也去学了AngularJS，参与了用户UI编。
DRDS主要功能介绍
发展历史看完了，下面就由我来介绍一下目前我们已经输出到云上的主要功能。
【分布式SQL执行引擎】
分布式SQL引擎主要的目的，就是实现与单机数据库SQL引擎的完全兼容。目前我们的SQL引擎能够做到与MySQL的SQL引擎全兼容，包括各类join和各类复杂函数等。他主要包含SQL解析、优化、执行和合并四个流程，如图3中绿色部分。

图3 SQL引擎实现的主要流程
虽然SQL是兼容的，但是分布式SQL执行算法与单机SQL的执行算法却完全不同，原因也很简单，网络通信的延迟比单机内通信的延迟大得多。举个例子说明一下，我们有份文件要从一张纸A上誊写到另外一张纸B上，单机系统就好比两张纸都在同一个办公室里，而分布式数据库则就像是一张纸在北京，一张纸在杭州。
自然地，如果两张纸在同一个办公室，因为传输距离近，逐行誊写的效率是可以接受的。而如果距离是北京到杭州，用逐行誊写的方式，就立刻显得代价太高了，我们总不能看一行，就打个“飞的”去杭州写下来吧。在这种情况下，还是把纸A上的信息拍个照片，【一整批的】带到杭州去处理，明显更简单一些。这就是分布式数据库特别强调吞吐调优的原因，只要是涉及到跨机的所有查询，都必须尽可能的积攒一批后一起发送，以减少系统延迟提高带来的不良影响。
【按需数据库集群平滑扩缩】
DRDS允许应用按需将新的单机存储加入或移出集群，DRDS则能够保证应用在迁移流程中实现不停机扩容缩容。

图4 DRDS按需进行平滑扩缩
在内部的数据库使用实践中，这个功能的一个最重要应用场景就是双11了。在双11之前，我们会将大批的机器加入到我们的数据库集群中，抗过了双11，这批机器就会下线。
当DRDS来到云上，我们发现双11其实不仅仅只影响阿里内部的系统。在下游的各类电商辅助性系统其实也面对巨大压力。在双11前5天，网聚宝的熊总就找到我说，担心撑不过双11的流量，怕系统挂。于是我们就给他介绍了这个自动扩容的功能怎么用，他买了一个月的数据库，挂接在DRDS上。数据库能力立刻翻倍，轻松抗过了双11，也算是我印象比较深刻的一个案例了。
因为我们完全无法预测在什么时间点系统会有爆发性的增长，而如果在这时候系统因为技术原因不能使用，就会给整个业务带来毁灭性的影响，风口一旦错过，就追悔莫及了。我想这就是云计算特别强调可扩展能力的原因吧。
【小表广播】
小表广播也是我们在分布式数据库领域内最常用的工具之一，他的核心目的其实都是一个——尽可能让查询只发生在单机。
让我们用一个例子来说明，小表广播的一般使用场景。

图5 小表广播场景
图5中，如果我想知道买家id等于0的用户在商城里面买了哪些商品，我们一般会先将这两个表join起来，然后再用where平台名=”商城” and buyerID = 0找到符合要求的数据。然而这种join的方式，会导致大量的针对左表的网络I/O。如果要取出的数据量比较大，系统延迟会明显上升。
这时候，为了提升性能，我们就必须要减少跨机join的网络代价。我们比较推荐应用做如下处理，将左表复制到右表的每一个库上。这样，join操作就由分布式join一下变回到本地join，系统的性能就有很大的提升了，如图6所示。

图6
【分布式事务套件】
在阿里巴巴的业务体系中存在非常多需要事务类的场景，下单减库存，账务，都是事务场景最集中的部分。
而我们处理事务的方法却和传统应用处理事务的方案不大一样，我们非常强调事务的最终一致性和异步化。利用这种方式，能够极大地降低分布式系统中锁持有的时间，从而极大地提升系统性能。

图7 DRDS分布式事务解决套件
这种处理机制，是我们分布式事务能够以极低成本大量运行的最核心法门。在DRDS平台内，我们将这些方案产品化，为了DRDS的分布式事务解决套件。
利用他们，能够让你以比较低的成本，实现低延迟，高吞吐的分布式事务场景。
DRDS的未来
阿里分布式数据库服务DRDS上线至今，大家对这款产品的热情超出了我们的预期，短短半年内已经有几千个申请。
尽管还在公测期，但是大家就已经把关系到身家性命的宝贵在线数据业务放到了DRDS上，我能够感受到这份沉甸甸的信赖，也不想辜负这份信赖。
经过阿里内部几千个应用的不断历练，DRDS已经积累出一套强大的分布式SQL执行引擎和和一整套分布式事务套件。
我也相信，这些积累能够让用户在基本保持单机数据库的使用习惯的前提下，享受到分布式数据库高性能可扩展的好处。
在平时的DRDS支持过程中，我面对最多的问题就是，DRDS能不能够在不改变任何原有业务逻辑和代码的前提下，实现可自由伸缩和扩展呢？十分可惜的是，关系数据库发展至今，还没有找到既能保留传统数据库一切特性，又能实现高性能可扩展数据库的方法。
然而，虽不能至，吾心向往之！我们会以“可扩展，高性能”为产品核心，坚定地走在追寻圣杯的路上，并坚信最终我们一定能够找寻到它神圣的所在。
作者简介：王晶昱，花名沈询，阿里巴巴资深技术专家。目前主要负责阿里的分布式数据库DRDS（TDDL）和阿里的分布式消息服务ONS（RocketMQ/Notify）两个系统。

⑤ php 是什么是什么

PHP，是英文超文本预处理语言Hypertext Preprocessor的缩写。
一、概念。
PHP 是一种 HTML 内嵌式的语言，是一种在服务器端执行的嵌入HTML文档的脚本语言，语言的风格有类似于C语言，被广泛地运用。
二、解析。
PHP 独特的语法混合了C、Java、Perl以及PHP自创的语法。它可以比CGI或者Perl更快速地执行动态网页。用PHP做出的动态页面与其他的编程语言相比，PHP是将程序嵌入到HTML文档中去执行，执行效率比完全生成HTML标记的CGI要高许多；PHP还可以执行编译后代码，编译可以达到加密和优化代码运行，使代码运行更快。
三、特点。
1、PHP 独特的语法混合了 C、Java、Perl 以及 PHP 自创新的语法。
2、PHP安装它可以比 CGI或者Perl更快速的执行动态网页。用PHP做出的动态页面与其他的编程语言相比。
3、PHP是将程序嵌入到HTML文档中去执行，执行效率比完全生成htmL标记的CGI要高许多； PHP具有非常强大的功能，所有的CGI的功能PHP都能实现。
4、支持几乎所有流行的数据库以及操作系统。最重要的是PHP可以用C、C++进行程序的扩展。

⑥ oracle数据库的优势有哪些

oracle 优势很多，大部分银行保险电信大部分是用oracle处理的
优势主要 有
1、处理速度快，非常快
2、安全级别高。支持快闪以及完美的恢复，即使硬件坏了 也可以恢复到故障发前的1s
3、几台数据库做集群数据库，可以做到几秒s以内故障转移，而且数据物理完全一致，现在集群一直是最优秀的解决方案，对于银行保险没有其他太多的选项{数据不丢，快速切换，负载均衡}
4、网格控制，以及 数据仓库方面 也非常强大
对了免费 以及 开源的 言论 都是错误的。。。oracle产品及服务都是付费的，而且价格不菲。比其他数据库要贵，物有所值。oracle不是开源的。不过可以在redhat 或者其他开源操作系统上安装。
mysql在sun没被oracle收购是开源的,免费的,之后oracle公司打算 把mysql打造成不开源，收费模式的。

⑦ 如何在虚拟机中创建共享磁盘用来做数据库集群

一、使用目的a. 模拟现有集群中的环境，快速定位故障原因，处理运维集群故障。b. 在虚拟环境中模拟集群，对初学者的学习集群知识有很大的帮助。c. 对想研究集群技术的人来讲，这是一个很好的帮助工具。 二、技术背景1、 iSCSI基础iSCSI是一种新兴的存储协议，全称是Internet SCSI，和传统的SCSI设备不同，iSCSI存储设备使用IP网络来进行数据的传输。这样的好处就是网络中的任何一台主机都可以使用iSCSI存储设备作为自己的存储设备，缺点就是比较依赖IP网络的传输性能，所以通常情况下推荐在1000M网络中使用iSCSI存储设备。首先介绍一下iSCSI存储中所使用的组件。iSCSI存储使用以下三个组件：发起方（Initiator）：安装在需要使用iSCSI存储设备的主机上的客户端软件，提供连接iSCSI存储设备并进行数据读写的驱动程序；目标（Target）：iSCSI存储设备，提供数据存储服务；入口（Portal）：由IP地址和端口（默认为TCP 3260）组成，发起方通过入口来连接目标。连接过程：发起方通过入口来连接目标，目标通常通过发起方的IQN（发起方完全限定名称）来识别发起方的连接。此外，你还可以配置CHAP身份验证和IPSec加密，通常情况下，不推荐使用IPSec加密，更占用服务器性能。 从实验的目的简单来讲，就是在一台服务器上用ISCSI工具建立一个共享存储，其他的客户端通过ISCSI客户端工具来建立和服务器端的连接，这样，所有的客户端就共享这一个存储，从而达到我们实验的目的（因为建立数据库集群需要共享磁盘做支撑） 三、工具介绍1、 建立共享存储磁盘的工具。主要介绍两种在服务器中创建共享磁盘的工具Wintarget和StarWind。其中Wintarget是微软公司研发的，而StarWind是由Rocket Division Software LTD研发的。2、 客户端连接工具主要是Microsoft iSCSI Initiator，简称Initiator。3、 工具使用组合a.Wintarget+ Initiator组合b.StarWind+ Initiator 四、操作步骤1、使用组合a的操作指南在这里使用两台虚拟机来做实验，一个作为提供共享存储的服务端，IP地址：192.168.200.191，一个作为连接存储的客户端，IP地址：192.168.200.200。此时虚拟机的NetWorking中Adapter选择是local only.a. 在IP地址是192.168.200.191的服务器上，安装服务端软件Wintarget.使用默认配置，选择下一步，直到完成安装。b. 在IP地址是192.168.200.200的服务器上，安装客户端软件Initiator.使用默认配置，选择下一步，直到完成安装。c. 配置服务端共享磁盘，在IP地址为192.168.200.191的服务器上配置。步骤1、从“开始--所有程序—管理工具”列表中找到Microsoft ISCSI Software Target工具，并打开，打开以后的界面如下图所示：步骤2、新建一个ISCSI Targets,也就是供客户端连接的目标。右键单击“iscsi targets”节点，选择“create iscsi target”,则进入创建iscsi目标向导的界面，如下图：点击“下一步”，在视图中的“ISCSI Target Name”输入框中输入一个唯一的供客户端连接的目标名，比如clientISCSI,而Description输入框可以忽略。如下图：点击“下一步”，设置访问“clientISCSI”目标的客户端的标识，如下图所示：设置客户端连接的标识有很多，可以是DNS名称，IP地址，MAC地址等，在这里选择IP地址来设置，点击“advanced”,则弹出“advanced identifiers”对话框，再点击对话框上的“Add”，则出现“Add/Edit identifier”对话框，在identifier Type列表中选择：IP Address,在value中输入客户端访问的ip地址：192.168.200.200。如下图所示：点击“OK”，返回“advanced identifiers”对话框，点击“OK”，回到设置访问“clientISCSI”客户端访问标识界面，点击“下一步”，直到点击“完成”。在点击“完成”按钮以后，将在在控制台中的“Iscsi targets”列表中出现“clientISCSI”节点。如下图：步骤3、设置“clientISCSI”目标连接的共享虚拟磁盘，右键单击“clientISCSI”节点，选择“Create Virtual Disk for Iscsi Target”,则进入“Create Virtual Disk for Iscsi Target”创建向导。如下图：点击“下一步”，设置虚拟共享磁盘的文件存储路径，如下图所示：点击“下一步”，设置虚拟共享磁盘的存储大小，如下图：点击“下一步”，设置虚拟磁盘描述，如下图：点击“下一步”，直到点击“完成”。在创建完成以后，在控制台列表中的显示如下：此时，所创建的虚拟共享磁盘的状态是“idle(空闲)”，当如果有客户端连接到服务端以后，则该状态显示为：这样，服务端的设置就基本完成。d. 配置客户端的连接，在IP地址为192.168.200.200的服务器上配置。在未进行客户端连接设置之前，我们来看一下客户端磁盘管理里磁盘情况，如下图：下面讲述客户端的设置。步骤1、打开“Microsoft iSCSI Initiator”管理控制台。如下图所示：点击“Discovery”选项卡，在此选项卡中，点击“Add”按钮，则弹出“Add Target Portal”对话框，在“IP address or DNS name”文本框中输入需要连接的服务端的IP地址，和端口号（一般端口默认为3260），使用缺省的端口设置。如下图：点击“OK”，返回“Iscsi Initiator”属性界面，然后点击“Targets”选项卡，则在此选卡的“Targets”列表框显示了连接的状态，如下图：此时的状态是“inactive”,表示是“不活动的”，说明还没有和服务端连接上，这时我们需要点击“log on”按钮，则弹出“log on to target”对话框，同时选择“automatically restore this connection when the system boots”，如下图所示：点击“OK”，返回属性界面，则在此选卡的“Targets”列表框显示了连接的状态为：connected，如下图：步骤2、在完成以上设置以后，再来看一下客户端磁盘管理里磁盘情况，如下图：此时，出现了一个没有初始化的磁盘，这样按照磁盘管理的方式，初始化磁盘，建立分区，即可。如下图：这样组合a的操作指南就完毕了，如果有多个客户端连接服务端，则需要在服务端对应“iscsi targets”中设置客户端访问的IP地址，如有多个客户端访问“clientISCSI”则需要在节点“clientISCSI”属性中，添加客户端访问的权限，如下图：同时在客户端的配置，就和上面讲述的客户端设置一样，即可完成。2、使用组合b的操作指南同样在这里使用两台虚拟机来做实验，一个作为提供共享存储的服务端，IP地址：192.168.200.191，一个作为连接存储的客户端，IP地址：192.168.200.200。此时虚拟机的NetWorking中Adapter选择是local only.a. 在IP地址是192.168.200.191的服务器上，安装服务端软件StarWind.使用默认配置，选择下一步，直到完成安装。安装过程省略。b. 在IP地址是192.168.200.200的服务器上，安装客户端软件Initiator.使用默认配置，选择下一步，直到完成安装。c. 配置服务端共享磁盘，在IP地址为192.168.200.191的服务器上配置。步骤1、从“开始”－“所有程序”－“Rocket Division Software”－“StarWind”选择“StarWind”，打开StarWind的管理界面如下图：右键单击“connections”节点下的localhost:3260，选择“connect”，如图所示：选择“connect”以后，灰色的图标变成了蓝色的可用图标，如图下图所示：即此时可以此连接的端口下建立共享的虚拟磁盘，即localhost:3260,也就是安装该软件的服务器端。右键单击“localhost:3260”，选择“Add device”,则进入建立虚拟磁盘向导界面，选择“Image File Device”,如下图所示：点击“下一步”，选择“Create new Image”，如下图所示：点击“下一步”，为建立的虚拟磁盘文件选择存储路径，其他的选项采用缺省设置，如下图：点击“下一步”，选择通过iscsi客户端访问的mode,一般选择下列设置，如下图所示：点击“下一步”，选择一个“target name”(此命名好像不能有下划线)，主要用于客户端连接服务端时，会显示出来。输入我们命名为：iscsig，如下图：点击“下一步”，直到向导完成。则刷新节点“localhost:3260”,则会出现如下图所示的虚拟磁盘列表。这样，在服务器端的设置，就完毕了，而客户端的设置如同组合a中客户端的设置一样，在这里就不做介绍了。 说明：本文介绍两种工具最基本的配置共享虚拟磁盘的方法的目的在于为了虚拟机做数据库群集，而并不是讲解这两种工具本身的，如果真正想对这两种工具有深入的研究，请参考以下资料。 写的比较匆忙，文档里难免没有错误，如果有，还请谅解，希望大家可以相互交流，谢谢。 转载自

⑧ 服务器宕机会有什么样的后果安全可靠的服务器要怎么选择

服务器宕机有可能是网络故障，有可能是突发的访问量暴增、服务器处理不过来的问题。

服务器处理和响应不过来，会导致丢弃部分请求不予处理，更严重的会导致服务端崩溃。

防止由于服务器宕机可能导致的数据丢失问题的解决办法有：

一、数据备份与“多云”

如果是物理机，要做好数据备份，比如做raid；如果是选择的公有云，则最好把数据分存在不同的服务商那里。

二、web服务器配置优化

对Web服务器进行配置优化，比如：调整内存数量、线程数量等；提供多个能提供相同服务的Web服务器，以实现负载均衡；仔细规划Web服务器上部署的应用规模；对Web服务器进行集群。

三、数据库集群，进行读写分离

⑨ postgreSQL数据库有什么用啊

优点事实上， PostgreSQL 的特性覆盖了 SQL-2/SQL-92 和 SQL-3/SQL-99，首先，它包括了可以说是目前世界上最丰富的数据类型的支持，其中有些数据类型可以说连商业数据库都不具备， 比如 IP 类型和几何类型等；其次，PostgreSQL 是全功能的自由软件数据库，很长时间以来，PostgreSQL 是唯一支持事务、子查询、多版本并行控制系统、数据完整性检查等特性的唯一的一种自由软件的数据库管理系统。直到最近才有 Inprise 的 InterBase 以及 SAP 等厂商将其原先专有软件开放为自由软件之后才打破了这个唯一。最后，PostgreSQL拥有一支非常活跃的开发队伍，而且在许多黑客的努力下，PostgreSQL 的质量日益提高。
从技术角度来讲，PostgreSQL 采用的是比较经典的 C/S （client/server）结构，也就是一个客户端对应一个服务器端守护进程的模式，这个守护进程分析客户端来的查询请求，生成规划树，进行数据检索并最终把结果格式化输出后返回给客户端。为了便于客户端的程序的编写，由数据库服务器提供了统一的客户端 C 接口。而不同的客户端接口都是源自这个 C 接口，比如 ODBC，JDBC，Python，Perl ，Tcl，C/C++，ESQL 等， 同时也要指出的是，PostgreSQL 对接口的支持也是非常丰富的，几乎支持所有类型的数据库客户端接口。这一点也可以说是 PostgreSQL 一大优点。
缺点
从 Postgres 开始，PostgreSQL 就经受了多次变化。
首先，早期的 PostgreSQL 继承了几乎所有 Ingres, Postgres, Postgres95 的问题：过于学院味，因为首先它的目的是数据库研究，因此不论在稳定性， 性能还是使用方便方面，长期以来一直没有得到重视，直到 PostgreSQL 项目开始以后，情况才越来越好，目前，PostgreSQL 已经完全可以胜任任何中上规模范围内的应用范围的业务。目前有报道的生产数据库的大小已经有 TB 级的数据量，已经逼近 32 位计算的极限。不过学院味也给 PostgreSQL 带来一个意想不到的好处：大概因为各大学的软硬件环境差异太大的缘故，它是目前支持平台最多的数据库管理系统的一种，所支持的平台多达十几种，包括不同的系统，不同的硬件体系。至今，它仍然保持着支持平台最多的数据库管理系统的称号。
其次，PostgreSQL 的确还欠缺一些比较高端的数据库管理系统需要的特性，比如数据库集群，更优良的管理工具和更加自动化的系统优化功能 等提高数据库性能的机制等。