1. 数据库恢复的数据库恢复的三种方式
数据库可能因为硬件或软件（或两者同时）的故障变得不可用，不同的故障情况需要不同的恢复操作。我们必须决定最适合业务环境的恢复方法。在数据库中恢复有3种类型或方法，即应急（crash）恢复、版本（version）恢复和前滚（rool forward）恢复。 应急恢复用于防止数据库处于不一致或不可用状态。数据库执行的事务（也称工作单元）可能被意外中断，若在作为工作单位一部分的所有更改完成和提交之前发生故障，则该数据库就会处于不一致和不可用的状态。这时，需要将该数据库转化为一致和可用的状态。
为此，需要回滚未完成的事务，并完成当发生崩溃时仍在内存中的已提交事务。如在COMMIT语句之前发生了电源故障，则在下一次重新启动并再次访问该数据库时，需要回滚到执行COMMMIT语句前的状态。回滚语句的顺序与最初执行时的顺序相反。 这种恢复技术是版本恢复的一个扩展，使用完整的数据库备份和日志相结合，可以使一个数据库或者被选择的表空间恢复到某个特定时间点。如果从备份时刻起到发生故障时的所有日志文件都可以获得的话，则可以恢复到日志上涵盖到的任意时间点。前滚恢复需要在配置中被明确激活才能生效。
2. 有哪些分布式数据库,实现最终一致性的(分布式数据库与集中式数据库的区别)
一个分布式数据库在用户面前为单个逻辑数据库，但实际上是由存储在多台计算机上的一组数据库组成
在几台计算机上的数据库通过网络可同时修改和存取，每一数据库受它的局部的DBMS控制
分布式数据库中每一个数据库服务器合作地维护全局数据库的一致性
在系统中的每一台计算机称为结点
如果一结点具有管理数据库软件，该结点称为数据库服务器
如果一个结点为请求服务器的信息的一应用，该结点称为客户
在ORACLE客户，执行数据库应用，可存取数据信息和与用户交互
在服务器，执行ORACLE软件，处理对ORACLE数据库并发、共享数据存取
ORACLE允许上述两部分在同一台计算机上，但当客户部分和服务器部分是由网连接的不同计算机上时，更有效
分布处理是由多台处理机分担单个任务的处理
在ORACLE数据库系统中分布处理的例子如：客户和服务器是位于网络连接的不同计算机上
单台计算机上有多个处理器，不同处理器分别执行客户应用
sql*NET是ORACLE网络接口，允许运行在网络工作站的ORACLE工具和服务器上，可存取、修改、共享和存储在其它服务器上的数据
SAQL*NET可被认为是网络通信的程序接口
SQL*NET利用通信协议和应用程序接口（API）为OARCLE提供一个分布式数据库和分布处理
SQL*NET驱动器为在数据库服务器上运行的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提供两种机制实现分布式数据库中表重复的透明性：表快照提供异步的表重复；触发器实现同步的表的重复
在两种情况下，都实现了对表重复的透明性
3. 数据库原理中，介质故障的恢复方法有哪些（最少五种）
发生介质故障后，磁盘上的物理数据和日志文件被破坏，这是最严重的一种故障，恢复方法是重装数据库，然后重做已完成的事务。具体地说就是：
1. 装入最新的数据库后备副本（离故障发生时刻最近的转储副本），使数据库恢复到最近一次转储时的一致性状态。
对于动态转储的数据库副本，还须同时装入转储开始时刻的日志文件副本，利用恢复系统故障的方法（即REDO+UNDO），才能将数据库恢复到一致性状态。
2. 装入相应的日志文件副本（转储结束时刻的日志文件副本），重做已完成的事务。即：
首先扫描日志文件，找出故障发生时已提交的事务的标识，将其记入重做队列。
然后正向扫描日志文件，对重做队列中的所有事务进行重做处理。即将日志记录中“更新后的值”写入数据库。
这样就可以将数据库恢复至故障前某一时刻的一致状态了。
数据库镜像
4. 数据库恢复的基本原则
要使数据库具有可恢复性，基本原理就是 “冗余”，即数据的重复存储。
数据库恢复实现方法：
(1) 数据转储(mp)(又称“倒库”) 转储是指DBA将整个数据库复制到磁带或另 一个磁盘上保存起来的过程。这些备用的数 据文本称为后备副本或后援副本。一时发生 故障，可以将后备副本重新装入。
(2) 建立“日志”文件（logging)。 日志文件是用来记录事务对数据库的更新操 作的文件。对于数据库的每次插入、删除或 修改，记下改变前后 的值，写到““日志” 文件，以便有案可查。
5. 如何进行事务故障恢复，系统故障恢复，介质故障恢
1)事务故障恢复。由系统自动完成，对用户是透明的。
DBMS执行恢复操作的步骤如下：
①反向扫描日志文件(即从最后向前扫描日志文件)，查找该事务的更新操作。
②对该事务的更新操作执行逆操作，即将日志记录中“更新前的值”写入数据库。
③继续反向扫描日志文件，做同样处理。
④如此处理下去，直至读到此事务的开始标记，该事务故障的恢复就完成了。
(2)系统故障恢复。系统故障可能会造成数据库处于不一致性状态：一是未完成事务对数据库的更新可能已写入数据库；二是已提交事务对数据库的更新可能还留在缓冲区，没来得及写入数据库。因此，恢复操作就是要撤销故障发生时未完成的事务，重做已完成的事务。
系统故障的恢复步骤如下：
①正向扫描日志文件，找出在故障发生前已经提交的事务队列(REDO队列)和未完成的事务队列(UNDO队列)。
②对撤销队列中的各个事务进行UNDO处理。进行UNDO处理的方法是，反向扫描日志文件，对每个UNDO事务的更新操作执行逆操作，即将日志记录中“更新前的值”写入数据库。
③对重做队列中的各个事务进行REDO处理。进行REDO处理的方法是，正向扫描日志文件，对每个REDO事务重新执行日志文件登记的操作，即将日志记录中“更新后的值”写入数据库。
(3)介质故障恢复。介质故障是最严重的一种故障。恢复方法是重装数据库，然后重做已完成的事务。具体过程如下：
①DBA装入最新的数据库后备副本(离故障发生时刻最近的转储副本)，使数据库恢复到转储时的一致性状态。
②DBA装入转储结束时刻的日志文件副本。
③DBA启动系统恢复命令，由DBMS完成恢复功能，即重做已完成的事务。
6. 分库分表 VS newsql数据库
最近与同行 科技 交流，经常被问到分库分表与分布式数据库如何选择，网上也有很多关于中间件+传统关系数据库（分库分表）与NewSQL分布式数据库的文章，但有些观点与判断是我觉得是偏激的，脱离环境去评价方案好坏其实有失公允。
本文通过对两种模式关键特性实现原理对比，希望可以尽可能客观、中立的阐明各自真实的优缺点以及适用场景。
首先关于“中间件+关系数据库分库分表”算不算NewSQL分布式数据库问题，国外有篇论文pavlo-newsql-sigmodrec，如果根据该文中的分类，Spanner、TiDB、OB算是第一种新架构型，Sharding-Sphere、Mycat、DRDS等中间件方案算是第二种（文中还有第三种云数据库，本文暂不详细介绍）。
基于中间件（包括SDK和Proxy两种形式）+传统关系数据库（分库分表）模式是不是分布式架构？我觉得是的，因为存储确实也分布式了，也能实现横向扩展。但是不是"伪"分布式数据库？从架构先进性来看，这么说也有一定道理。"伪"主要体现在中间件层与底层DB重复的SQL解析与执行计划生成、存储引擎基于B+Tree等，这在分布式数据库架构中实际上冗余低效的。为了避免引起真伪分布式数据库的口水战，本文中NewSQL数据库特指这种新架构NewSQL数据库。
NewSQL数据库相比中间件+分库分表的先进在哪儿？画一个简单的架构对比图：
这些大多也是NewSQL数据库产品主要宣传的点，不过这些看起来很美好的功能是否真的如此？接下来针对以上几点分别阐述下的我的理解。
这是把双刃剑。
CAP限制
想想更早些出现的NoSQL数据库为何不支持分布式事务（最新版的mongoDB等也开始支持了），是缺乏理论与实践支撑吗？并不是，原因是CAP定理依然是分布式数据库头上的颈箍咒，在保证强一致的同时必然会牺牲可用性A或分区容忍性P。为什么大部分NoSQL不提供分布式事务？
那么NewSQL数据库突破CAP定理限制了吗？并没有。NewSQL数据库的鼻主Google Spanner（目前绝大部分分布式数据库都是按照Spanner架构设计的）提供了一致性和大于5个9的可用性，宣称是一个“实际上是CA”的，其真正的含义是 系统处于 CA 状态的概率非常高，由于网络分区导致的服务停用的概率非常小 ，究其真正原因是其打造私有全球网保证了不会出现网络中断引发的网络分区，另外就是其高效的运维队伍,这也是cloud spanner的卖点。详细可见CAP提出者Eric Brewer写的《Spanner, TrueTime 和CAP理论》。
完备性 ：
两阶段提交协议是否严格支持ACID，各种异常场景是不是都可以覆盖？
2PC在commit阶段发送异常，其实跟最大努力一阶段提交类似也会有部分可见问题，严格讲一段时间内并不能保证A原子性和C一致性（待故障恢复后recovery机制可以保证最终的A和C）。完备的分布式事务支持并不是一件简单的事情，需要可以应对网络以及各种硬件包括网卡、磁盘、CPU、内存、电源等各类异常，通过严格的测试。之前跟某友商交流，他们甚至说目前已知的NewSQL在分布式事务支持上都是不完整的，他们都有案例跑不过，圈内人士这么笃定，也说明了 分布式事务的支持完整程度其实是层次不齐的。
但分布式事务又是这些NewSQL数据库的一个非常重要的底层机制，跨资源的DML、DDL等都依赖其实现，如果这块的性能、完备性打折扣，上层跨分片SQL执行的正确性会受到很大影响。
性能
传统关系数据库也支持分布式事务XA，但为何很少有高并发场景下用呢？ 因为XA的基础两阶段提交协议存在网络开销大，阻塞时间长、死锁等问题，这也导致了其实际上很少大规模用在基于传统关系数据库的OLTP系统中。
NewSQL数据库的分布式事务实现也仍然多基于两阶段提交协议，例如google percolator分布式事务模型，
采用原子钟+MVCC+ Snapshot Isolation（SI），这种方式通过TSO(Timestamp Oracle)保证了全局一致性，通过MVCC避免了锁，另外通过primary lock和secondary lock将提交的一部分转为异步，相比XA确实提高了分布式事务的性能。
但不管如何优化，相比于1PC，2PC多出来的GID获取、网络开销、prepare日志持久化还是会带来很大的性能损失，尤其是跨节点的数量比较多时会更加显着，例如在银行场景做个批量扣款，一个文件可能上W个账户，这样的场景无论怎么做还是吞吐都不会很高。
虽然NewSQL分布式数据库产品都宣传完备支持分布式事务，但这并不是说应用可以完全不用关心数据拆分，这些数据库的最佳实践中仍然会写到，应用的大部分场景尽可能避免分布式事务。
既然强一致事务付出的性能代价太大，我们可以反思下是否真的需要这种强一致的分布式事务？尤其是在做微服务拆分后，很多系统也不太可能放在一个统一的数据库中。尝试将一致性要求弱化，便是柔性事务，放弃ACID(Atomicity,Consistency, Isolation, Durability)，转投BASE(Basically Available,Soft state,Eventually consistent)，例如Saga、TCC、可靠消息保证最终一致等模型，对于大规模高并发OLTP场景，我个人更建议使用柔性事务而非强一致的分布式事务。关于柔性事务，笔者之前也写过一个技术组件，最近几年也涌现出了一些新的模型与框架（例如阿里刚开源的Fescar），限于篇幅不再赘述，有空再单独写篇文章。
HA与异地多活
主从模式并不是最优的方式，就算是半同步复制，在极端情况下（半同步转异步）也存在丢数问题，目前业界公认更好的方案是基于paxos分布式一致性协议或者其它类paxos如raft方式，Google Spanner、TiDB、cockcoachDB、OB都采用了这种方式，基于Paxos协议的多副本存储，遵循过半写原则，支持自动选主，解决了数据的高可靠，缩短了failover时间，提高了可用性，特别是减少了运维的工作量，这种方案技术上已经很成熟，也是NewSQL数据库底层的标配。
当然这种方式其实也可以用在传统关系数据库，阿里、微信团队等也有将MySQL存储改造支持paxos多副本的，MySQL也推出了官方版MySQL Group Cluster，预计不远的未来主从模式可能就成为 历史 了。
需要注意的是很多NewSQL数据库厂商宣传基于paxos或raft协议可以实现【异地多活】，这个实际上是有前提的，那就是异地之间网络延迟不能太高 。以银行“两地三中心”为例，异地之间多相隔数千里，延时达到数十毫秒，如果要多活，那便需异地副本也参与数据库日志过半确认，这样高的延时几乎没有OLTP系统可以接受的。
数据库层面做异地多活是个美好的愿景，但距离导致的延时目前并没有好的方案。 之前跟蚂蚁团队交流，蚂蚁异地多活的方案是在应用层通过MQ同步双写交易信息，异地DC将交易信息保存在分布式缓存中，一旦发生异地切换，数据库同步中间件会告之数据延迟时间，应用从缓存中读取交易信息，将这段时间内涉及到的业务对象例如用户、账户进行黑名单管理，等数据同步追上之后再将这些业务对象从黑名单中剔除。由于双写的不是所有数据库操作日志而只是交易信息，数据延迟只影响一段时间内数据，这是目前我觉得比较靠谱的异地度多活方案。
另外有些系统进行了单元化改造，这在paxos选主时也要结合考虑进去，这也是目前很多NewSQL数据库欠缺的功能。
Scale横向扩展与分片机制
paxos算法解决了高可用、高可靠问题，并没有解决Scale横向扩展的问题，所以分片是必须支持的。NewSQL数据库都是天生内置分片机制的，而且会根据每个分片的数据负载(磁盘使用率、写入速度等)自动识别热点，然后进行分片的分裂、数据迁移、合并，这些过程应用是无感知的，这省去了DBA的很多运维工作量。以TiDB为例，它将数据切成region，如果region到64M时，数据自动进行迁移。
分库分表模式下需要应用设计之初就要明确各表的拆分键、拆分方式（range、取模、一致性哈希或者自定义路由表）、路由规则、拆分库表数量、扩容方式等。相比NewSQL数据库，这种模式给应用带来了很大侵入和复杂度，这对大多数系统来说也是一大挑战。
这里有个问题是NewSQL数据库统一的内置分片策略（例如tidb基于range）可能并不是最高效的，因为与领域模型中的划分要素并不一致，这导致的后果是很多交易会产生分布式事务。 举个例子，银行核心业务系统是以客户为维度，也就是说客户表、该客户的账户表、流水表在绝大部分场景下是一起写的，但如果按照各表主键range进行分片，这个交易并不能在一个分片上完成，这在高频OLTP系统中会带来性能问题。
分布式SQL支持
常见的单分片SQL，这两者都能很好支持。NewSQL数据库由于定位与目标是一个通用的数据库，所以支持的SQL会更完整，包括跨分片的join、聚合等复杂SQL。中间件模式多面向应用需求设计，不过大部分也支持带拆分键SQL、库表遍历、单库join、聚合、排序、分页等。但对跨库的join以及聚合支持就不够了。
NewSQL数据库一般并不支持存储过程、视图、外键等功能，而中间件模式底层就是传统关系数据库，这些功能如果只是涉及单库是比较容易支持的。
NewSQL数据库往往选择兼容MySQL或者PostgreSQL协议，所以SQL支持仅局限于这两种，中间件例如驱动模式往往只需做简单的SQL解析、计算路由、SQL重写，所以可以支持更多种类的数据库SQL。
SQL支持的差异主要在于分布式SQL执行计划生成器，由于NewSQL数据库具有底层数据的分布、统计信息，因此可以做CBO，生成的执行计划效率更高，而中间件模式下没有这些信息，往往只能基于规则RBO（Rule-Based-Opimization），这也是为什么中间件模式一般并不支持跨库join，因为实现了效率也往往并不高，还不如交给应用去做。
存储引擎
传统关系数据库的存储引擎设计都是面向磁盘的，大多都基于B+树。B+树通过降低树的高度减少随机读、进而减少磁盘寻道次数，提高读的性能，但大量的随机写会导致树的分裂，从而带来随机写，导致写性能下降。NewSQL的底层存储引擎则多采用LSM，相比B+树LSM将对磁盘的随机写变成顺序写，大大提高了写的性能。不过LSM的的读由于需要合并数据性能比B+树差，一般来说LSM更适合应在写大于读的场景。当然这只是单纯数据结构角度的对比，在数据库实际实现时还会通过SSD、缓冲、bloom filter等方式优化读写性能，所以读性能基本不会下降太多。NewSQL数据由于多副本、分布式事务等开销，相比单机关系数据库SQL的响应时间并不占优，但由于集群的弹性扩展，整体QPS提升还是很明显的，这也是NewSQL数据库厂商说分布式数据库更看重的是吞吐，而不是单笔SQL响应时间的原因。
成熟度与生态
分布式数据库是个新型通用底层软件，准确的衡量与评价需要一个多维度的测试模型，需包括发展现状、使用情况、社区生态、监控运维、周边配套工具、功能满足度、DBA人才、SQL兼容性、性能测试、高可用测试、在线扩容、分布式事务、隔离级别、在线DDL等等，虽然NewSQL数据库发展经过了一定时间检验，但多集中在互联网以及传统企业非核心交易系统中，目前还处于快速迭代、规模使用不断优化完善的阶段。
相比而言，传统关系数据库则经过了多年的发展，通过完整的评测，在成熟度、功能、性能、周边生态、风险把控、相关人才积累等多方面都具有明显优势，同时对已建系统的兼容性也更好。
对于互联网公司，数据量的增长压力以及追求新技术的基因会更倾向于尝试NewSQL数据库，不用再考虑库表拆分、应用改造、扩容、事务一致性等问题怎么看都是非常吸引人的方案。
对于传统企业例如银行这种风险意识较高的行业来说，NewSQL数据库则可能在未来一段时间内仍处于 探索 、审慎试点的阶段。基于中间件+分库分表模式架构简单，技术门槛更低，虽然没有NewSQL数据库功能全面，但大部分场景最核心的诉求也就是拆分后SQL的正确路由，而此功能中间件模式应对还是绰绰有余的，可以说在大多数OLTP场景是够用的。
限于篇幅，其它特性例如在线DDL、数据迁移、运维工具等特性就不在本文展开对比。
总结
如果看完以上内容，您还不知道选哪种模式，那么结合以下几个问题，先思考下NewSQL数据库解决的点对于自身是不是真正的痛点：
如果以上有2到3个是肯定的，那么你可以考虑用NewSQL数据库了，虽然前期可能需要一定的学习成本，但它是数据库的发展方向，未来收益也会更高，尤其是互联网行业，随着数据量的突飞猛进，分库分表带来的痛苦会与日俱增。当然选择NewSQL数据库你也要做好承担一定风险的准备。
如果你还未做出抉择，不妨再想想下面几个问题：
如果这些问题有多数是肯定的，那还是分库分表吧。在软件领域很少有完美的解决方案，NewSQL数据库也不是数据分布式架构的银弹。相比而言分库分表是一个代价更低、风险更小的方案，它最大程度复用传统关系数据库生态，通过中间件也可以满足分库分表后的绝大多数功能，定制化能力更强。 在当前NewSQL数据库还未完全成熟的阶段，分库分表可以说是一个上限低但下限高的方案，尤其传统行业的核心系统，如果你仍然打算把数据库当做一个黑盒产品来用，踏踏实实用好分库分表会被认为是个稳妥的选择。
很多时候软件选型取决于领域特征以及架构师风格，限于笔者知识与所属行业特点所限，以上仅为个人粗浅的一些观点，欢迎讨论。
7. 分布式数据库系统(DDBS)概述
一 什么是分布式数据库
分布式数据库系统是在集中式数据库系统的基础上发展来的 是数据库技术与网络技术结合的产物
分布式数据库系统有两种 一种是物理上分布的 但逻辑上却是集中的 这种分布式数据库只适宜用途比较单一的 不大的单位或部门 另一种分布式数据库系统在物理上和逻辑上都是分布的 也就是所谓联邦式分布数据库系统 由于组成联邦的各个子数据库系统是相对 自治 的 这种系统可以容纳多种不同用途的 差异较大的数据库 比较适宜于大范围内数据库的集成
分布式数据库系统(DDBS)包含分布式数据库管理系统(DDBMS)和分布式数据库(DDB)
在分布式数据库系统中 一个应用程序可以对数据库进行透明操作 数据库中的数据分别在不同的局部数据库中存储 由不同的DBMS进行管理 在不同的机器上运行 由不同的操作系统支持 被不同的通信网络连接在一起
一个分布式数据库在逻辑上是一个统一的整体 即在用户面前为单个逻辑数据库 在物理上则是分别存储在不同的物理节点上 一个应用程序通过网络的连接可以访问分布在不同地理位置的数据库 它的分布性表现在数据库中的数据不是存储在同一场地 更确切地讲 不存储在同一计算机的存储设备上 这就是与集中式数据库的区别 从用户的角度看 一个分布式数据库系统在逻辑上和集中式数据库系统一样 用户可以在任何一个场地执行全局应用 就好那些数据是存储在同一台计算机上 有单个数据库管理系统(DBMS)管理一样 用户并没有什么感觉不一样
分布式数据库中每一个数据库服务器合作地维护全局数据库的一致性
分布式数据库系统是一个客户/服务器体系结构
在系统中的每一台计算机称为结点 如果一结点具有管理数据库软件 该结点称为数据库服务器 如果一个结点为请求服务器的信息的一应用 该结点称为客户 在ORACLE客户 执行数据库应用 可存取数据信息和与用户交互 在服务器 执行ORACLE软件 处理对ORACLE数据库并发 共享数据存取 ORACLE允许上述两部分在同一台计算机上 但当客户部分和服务器部分是由网连接的不同计算机上时 更有效
分布处理是由多台处理机分担单个任务的处理 在ORACLE数据库系统中分布处理的例子如
客户和服务器是位于网络连接的不同计算机上
单台计算机上有多个处理器 不同处理器分别执行客户应用
参与分布式数据库的每一服务器是分别地独立地管理数据库 好像每一数据库不是网络化的数据库 每一个数据库独立地被管理 称为场地自治性 场地自治性有下列好处
◆系统的结点可反映公司的逻辑组织
◆由局部数据库管理员控制局部数据 这样每一个数据库管理员责任域要小一些 可更好管理
◆只要一个数据库和网络是可用 那么全局数据库可部分可用 不会因一个数据库的故障而停止全部操作或引起性能瓶颈
◆故障恢复通常在单个结点上进行
◆每个局部数据库存在一个数据字典
◆结点可独立地升级软件
可从分布式数据库的所有结点存取模式对象 因此正像非分布的局部的DBMS 必须提供一种机制 可在局部数据库中引用一个对象 分布式DBMS必须提供一种命名模式 以致分布式数据库中一个对象可在应用中唯一标识和引用 一般在层次结构的每一层实施唯一性 分布式DBMS简单地扩充层次命名模型 实施在网络上唯一数据库命名 因此一个对象的全局对象名保证在分布式数据库内是唯一
ORACLE允许在SQL语句中使用全局对象名引用分布式数据库中的模式对象(表 视图和过程) 在ORACLE中 一个模式对象的全局名由三部分组成 包含对象的模式名 对象名 数据库名 其形式如
SCOTT EMP@SALES DIVISION ACME
一个远程查询为一查询 是从一个或多个远程表中选择信息 这些表驻留在同一个远程结点
一个分布式查询可从两个或多个结点检索数据 一个分布式更新可修改两个或两个以上结点的数据
一个远程事务为一个事务 包含一人或多个远程语句 它所引用的全部是在同一个远程结点上 一个分布式事务中一个事务 包含一个或多个语句修改分布式数据库的两个或多个不同结点的数据
在分布式数据库中 事务控制必须在网络上直辖市 保证数据一致性 两阶段提交机制保证参与分布式事务的全部数据库服务器是全部提交或全部回滚事务中的语句
ORACLE分布式数据库系统结构可由ORACLE数据库管理员为终端用户和应用提供位置透明性 利用视图 同义词 过程可提供ORACLE分布式数据库系统中的位置透明性
ORACLE提供两种机制实现分布式数据库中表重复的透明性 表快照提供异步的表重复;触发器实现同步的表的重复 在两种情况下 都实现了对表重复的透明性
在单场地或分布式数据库中 所有事务都是用MIT或ROLLBACK语句中止
二 分布式数据库系统的分类
( ) 同构同质型DDBS 各个场地都采用同一类型的数据模型(譬如都是关系型) 并且是同一型号的DBMS
( )同构异质型DDBS 各个场地采用同一类型的数据模型 但是DBMS的型号不同 譬如DB ORACLE SYBASE SQL Server等
( )异构型DDBS 各个场地的数据模型的型号不同 甚至类型也不同 随着计算机网络技术的发展 异种机联网问题已经得到较好的解决 此时依靠异构型DDBS就能存取全网中各种异构局部库中的数据
三 分布式数据库系统主要特点
DDBS的基本特点
( )物理分布性 数据不是存储在一个场地上 而是存储在计算机网络的多个场地上
逻辑整体性 数据物理分布在各个场地 但逻辑上是一个整体 它们被所有用户(全局用户)共享 并由一个DDBMS统一管理
( )场地自治性 各场地上的数据由本地的DBMS管理 具有自治处理能力 完成本场地的应用(局部应用)
( )场地之间协作性 各场地虽然具有高度的自治性 但是又相互协作构成一个整体
DDBS的其他特点
( )数据独立性
( )集中与自治相结合的控制机制
( )适当增加数据冗余度
( )事务管理的分布性
四 分布式数据库系统的优点
( )更适合分布式的管理与控制
分布式数据库系统的结构更适合具有地理分布特性的组织或机构使用 允许分布在不同区域 不同级别的各个部门对其自身的数据实行局部控制 例如 实现全局数据在本地录入 查询 维护 这时由于计算机资源靠近用户 可以降低通信代价 提高响应速度 而涉及其他场地数据库中的数据只是少量的 从而可以大大减少网络上的信息传输量;同时 局部数据的安全性也可以做得更好
( )具有灵活的体系结构
集中式数据库系统强调的是集中式控制 物理数据库是存放在一个场地上的 由一个DBMS集中管理 多个用户只可以通过近程或远程终端在多用户操作系统支持下运行该DBMS来共享集中是数据库中的数据 而分布式数据库系统的场地局部DBMS的自治性 使得大部分的局部事务管理和控制都能就地解决 只有在涉及其他场地的数据时才需要通过网络作为全局事务来管理 分布式DBMS可以设计成具有不同程度的自治性 从具有充分的场地自治到几乎是完全集中式的控制
( )系统经济 可靠性高 可用性好
与一个大型计算机支持一个大型的集中式数据库在加一些进程和远程终端相比 由超级微型计算机或超级小型计算机支持的分布式数据库系统往往具有更高的性价比和实施灵活性 分布式系统比集中式系统具有更高的可靠性和更好的可用性 如由于数据分布在多个场地并有许多复制数据 在个别场地或个别通信链路发生故障时 不致于导致整个系统的崩溃 而且系统的局部故障不会引起全局失控
( )在一定条件下响应速度加快
如果存取的数据在本地数据库中 那么就可以由用户所在的计算机来执行 速度就快
( )可扩展性好 易于集成现有系统 也易于扩充
对于一个企业或组织 可以采用分布式数据库技术在以建立的若干数据库的基础上开发全局应用 对原有的局部数据库系统作某些改动 形成一个分布式系统 这比重建一个大型数据库系统要简单 既省时间 又省财力 物力 也可以通过增加场地数的办法 迅速扩充已有的分布式数据库系统
五 分布式数据库系统的劣势
( )通信开销较大 故障率高
例如 在网络通信传输速度不高时 系统的响应速度慢 与通信相关的因素往往导致系统故障 同时系统本身的复杂性也容易导致较高的故障率 当故障发生后系统恢复也比较复杂 可靠性有待提高
( )数据的存取结构复杂
一般来说 在分布时数据库中存取数据 比在集中时数据库中存取数据更复杂 开销更大
( )数据的安全性和保密性较难控制
在具有高度场地自治的分布时数据库中 不同场地的局部数据库管理员可以采用不同的安全措施 但是无法保证全局数据都是安全的 安全性问题式分布式系统固有的问题 因为分布式系统式通过通信网络来实现分布控制的 而通信网络本身却在保护数据的安全性和保密性方面存在弱点 数据很容易被窃取
分布式数据库的设计 场地划分及数据在不同场地的分配比较复杂 数据的划分及分配对系统的性能 响应速度及可用性等具有极大的影响 不同场地的通信速度与局部数据库系统的存取部件的存取速度相比 是非常慢的 通信系统有较高的延迟 在CPU上处理通信信息的代价很高 分布式数据库系统中要注意解决分布式数据库的设计 查询处理和优化 事务管理及并发控制和目录管理等问题
六 分布式数据库系统 数据分片
类型
水平分片
按一定的条件把全局关系的所有元组划分成若干不相交的子集 每个子集为关系的一个片段
垂直分片
把一个全局关系的属性集分成若干子集 并在这些子集上作投影运算 每个投影称为垂直分片
导出分片
又称为导出水平分片 即水平分片的条件不是本关系属性的条件 而是其他关系属性的条件
混合分片
以上三种方法的混合 可以先水平分片再垂直分片 或先垂直分片再水平分片 或其他形式 但他们的结果是不相同的
条件
( )完备性条件
必须把全局关系的所有数据映射到片段中 决不允许有属于全局关系的数据却不属于它的任何一个片段
( )可重构条件
必须保证能够由同一个全局关系的各个片段来重建该全局关系 对于水平分片可用并操作重构全局关系;对于垂直分片可用联接操作重构全局关系
( )不相交条件
要求一个全局关系被分割后所得的各个数据片段互不重叠(对垂直分片的主键除外)
七 分布式数据库系统 数据分配方式
( )集中式 所有数据片段都安排在同一个场地上
( )分割式
所有数据只有一份 它被分割成若干逻辑片段 每个逻辑片段被指派在一个特定的场地上
( )全复制式 数据在每个场地重复存储 也就是每个场地上都有一个完整的数据副本
( )混合式 这是一种介乎于分割式和全复制式之间的分配方式
八 分布式数据库系统 体系结构
数据分片和数据分配概念的分离 形成了 数据分布独立型 概念
数据冗余的显式控制 数据在各个场地的分配情况在分配模式中一目了然 便于系统管理
局部DBMS的独立性 这个特征也称为 局部映射透明性 此特征允许我们在不考虑局部DBMS专用数据模型的情况下 研究DDB管理的有关问题
九 分布式数据库管理系统
接受用户请求 并判定把它送到哪里 或必须访问哪些计算机才能满足该要求
访问网络数据字典 了解如何请求和使用其中的信息
如果目标数据存储于系统的多个计算机上 就必须进行分布式处理
通信接口功能 在用户 局部DBMS和其他计算机的DBMS之间进行协调
在一个异构型分布式处理环境中 还需提供数据和进程移植的支持 这里的异构型是指各个场地的硬件 软件之间存在着差别
分布式数据库管理系统
lishixin/Article/program/Oracle/201311/16998
8. 求救，分布式事务怎么处理
1.性能和时延问题在服务化之前，业务通常都是本地API调用，本地方法调用性能损耗较小。服务化之后，服务提供者和消费者之间采用远程网络通信，增加了额外的性能损耗：1）客户端需要对消息进行序列化，主要占用CPU计算资源。2）序列化时需要创建二进制数组，耗费JVM堆内存或者堆外内存。3）客户端需要将序列化之后的二进制数组发送给服务端，占用网络带宽资源。4）服务端读取到码流之后，需要将请求数据报反序列化成请求对象，占用CPU计算资源。5）服务端通过反射的方式调用服务提供者实现类，反射本身对性能影响就比较大。6）服务端将响应结果序列化，占用CPU计算资源。7）服务端将应答码流发送给客户端，占用网络带宽资源。8）客户端读取应答码流，反序列化成响应消息，占用CPU资源。通过分析我们发现，一个简单的本地方法调用，切换成远程服务调用之后，额外增加了很多处理流程，不仅占用大量的系统资源，同时增加了时延。一些复杂的应用会拆分成多个服务，形成服务调用链，如果服务化框架的性能比较差、服务调用时延也比较大，业务服务化之后的性能和时延将无法满足业务的性能需求。1.1RPC框架高性能设计影响RPC框架性能的主要因素有三个。1）I/O调度模型：同步阻塞I/O（BIO）还是非阻塞I/O（NIO）。2）序列化框架的选择：文本协议、二进制协议或压缩二进制协议。3）线程调度模型：串行调度还是并行调度，锁竞争还是无锁化算法。1.I/O调度模型在I/O编程过程中，当需要同时处理多个客户端接入请求时，可以利用多线程或者I/O多路复用技术进行处理。I/O多路复用技术通过把多个I/O的阻塞复用到同一个select的阻塞上，从而使得系统在单线程的情况下可以同时处理多个客户端请求。与传统的多线程/多进程模型比，I/O多路复用的最大优势是系统开销小，系统不需要创建新的额外进程或者线程，也不需要维护这些进程和线程的运行，降低了系统的维护工作量，节省了系统资源。JDK1.5_update10版本使用epoll替代了传统的select/poll，极大地提升了NIO通信的性能，它的工作原理如图1-1所示。图1-1非阻塞I/O工作原理Netty是一个开源的高性能NIO通信框架：它的I/O线程NioEventLoop由于聚合了多路复用器Selector，可以同时并发处理成百上千个客户端Channel。由于读写操作都是非阻塞的，这就可以充分提升I/O线程的运行效率，避免由于频繁I/O阻塞导致的线程挂起。另外，由于Netty采用了异步通信模式，一个I/O线程可以并发处理N个客户端连接和读写操作，这从根本上解决了传统同步阻塞I/O一连接一线程模型，架构的性能、弹性伸缩能力和可靠性都得到了极大的提升。Netty被精心设计，提供了很多独特的性能提升特性，使它做到了在各种NIO框架中性能排名第一，它的性能优化措施总结如下。1）零拷贝：（1）Netty的接收和发送ByteBuffer采用DIRECTBUFFERS，使用堆外直接内存进行Socket读写，不需要进行字节缓冲区的二次拷贝。如果使用传统的堆内存（HEAPBUFFERS）进行Socket读写，JVM会将堆内存Buffer拷贝一份到直接内存中，然后才写入Socket中。相比于堆外直接内存，消息在发腔兆送过程中多了一次缓冲区的内存拷贝。（2）Netty提供了组合Buffer对象，可以聚合多个ByteBuffer对象，用户可以像操作一个Buffer那样方便地对组合Buffer进行操作，避免了传统通过内存拷贝的方式将几手圆悔个小Buffer合并成一个大的Buffer。（3）Netty的文件传输采用了transferTo方法，它可以直接将文件缓冲区的数据发送到目标Channel，避免了传统通过循环write方式导致的内存拷贝问题。2）内存池：随着JVM虚拟机和JIT即时编译技术的发展，对象的分配和回收是个非常轻量级的工作。但是对于缓冲区Buffer，情况却稍有不同，特别是对于堆外直接内存的分配和回收，是一件耗时的操作。为了尽量重用缓冲区，Netty提供了基于内存池的缓冲区重用机制。性能测试表明，采用内存池的ByteBuf相比于朝生夕灭的ByteBuf，性能高23倍左右（性能数据与使用场景强相关）。3）无锁化的串行设计：在大多毕正数场景下，并行多线程处理可以提升系统的并发性能。但是，如果对于共享资源的并发访问处理不当，会带来严重的锁竞争，这最终会导致性能的下降。为了尽可能地避免锁竞争带来的性能损耗，可以通过串行化设计，即消息的处理尽可能在同一个线程内完成，期间不进行线程切换，这样就避免了多线程竞争和同步锁。为了尽可能提升性能，Netty采用了串行无锁化设计，在I/O线程内部进行串行操作，避免多线程竞争导致的性能下降。表面上看，串行化设计似乎CPU利用率不高，并发程度不够。但是，通过调整NIO线程池的线程参数，可以同时启动多个串行化的线程并行运行，这种局部无锁化的串行线程设计相比一个队列-多个工作线程模型性能更优。4）高效的并发编程：volatile的大量、正确使用；CAS和原子类的广泛使用；线程安全容器的使用；通过读写锁提升并发性能。2.高性能序列化框架影响序列化性能的关键因素总结如下。1）序列化后的码流大小（网络带宽的占用）。2）序列化&反序列化的性能（CPU资源占用）。3）是否支持跨语言（异构系统的对接和开发语言切换）。4）并发调用的性能表现：稳定性、线性增长、偶现的时延毛刺等。相比于JSON等文本协议，二进制序列化框架性能更优异，以Java原生序列化和Protobuf二进制序列化为例进行性能测试对比，结果如图1-2所示。图1-2序列化性能测试对比数据在序列化框架的技术选型中，如无特殊要求，尽量选择性能更优的二进制序列化框架，码流是否压缩，则需要根据通信内容做灵活选择，对于图片、音频、有大量重复内容的文本文件（例如小说）可以采用码流压缩，常用的压缩算法包括GZip、Zig-Zag等。3.高性能的Reactor线程模型该模型的特点总结如下。1）有专门一个NIO线程：Acceptor线程用于监听服务端，接收客户端的TCP连接请求。2）网络I/O操作：读、写等由一个NIO线程池负责，线程池可以采用标准的JDK线程池实现，它包含一个任务队列和N个可用的线程，由这些NIO线程负责消息的读取、解码、编码和发送。3）1个NIO线程可以同时处理N条链路，但是1个链路只对应1个NIO线程，防止产生并发操作。由于Reactor模式使用的是异步非阻塞I/O，所有的I/O操作都不会导致阻塞，理论上一个线程可以独立处理所有I/O相关的操作，因此在绝大多数场景下，Reactor多线程模型都可以完全满足业务性能需求。Reactor线程调度模型的工作原理示意如图1-3所示。图1-3高性能的Reactor线程调度模型1.2业务最佳实践要保证高性能，单依靠分布式服务框架是不够的，还需要应用的配合，应用服务化高性能实践总结如下：1）能异步的尽可能使用异步或者并行服务调用，提升服务的吞吐量，有效降低服务调用时延。2）无论是NIO通信框架的线程池还是后端业务线程池，线程参数的配置必须合理。如果采用JDK默认的线程池，最大线程数建议不超过20个。因为JDK的线程池默认采用N个线程争用1个同步阻塞队列方式，当线程数过大时，会导致激烈的锁竞争，此时性能不仅不会提升，反而会下降。3）尽量减小要传输的码流大小，提升性能。本地调用时，由于在同一块堆内存中访问，参数大小对性能没有任何影响。跨进程通信时，往往传递的是个复杂对象，如果明确对方只使用其中的某几个字段或者某个对象引用，则不要把整个复杂对象都传递过去。举例，对象A持有8个基本类型的字段，2个复杂对象B和C。如果明确服务提供者只需要用到A聚合的C对象，则请求参数应该是C，而不是整个对象A。4）设置合适的客户端超时时间，防止业务高峰期因为服务端响应慢导致业务线程等应答时被阻塞，进而引起后续其他服务的消息在队列中排队，造成故障扩散。5）对于重要的服务，可以单独部署到独立的服务线程池中，与其他非核心服务做隔离，保障核心服务的高效运行。6）利用Docker等轻量级OS容器部署服务，对服务做物理资源层隔离，避免虚拟化之后导致的超过20%的性能损耗。7）设置合理的服务调度优先级，并根据线上性能监控数据做实时调整。2.事务一致性问题服务化之前，业务采用本地事务，多个本地SQL调用可以用一个大的事务块封装起来，如果某一个数据库操作发生异常，就可以将之前的SQL操作进行回滚，只有所有SQL操作全部成功，才最终提交，这就保证了事务强一致性，如图2-1所示。服务化之后，三个数据库操作可能被拆分到独立的三个数据库访问服务中，此时原来的本地SQL调用演变成了远程服务调用，事务一致性无法得到保证，如图2-2所示。图2-2服务化之后引入分布式事务问题假如服务A和服务B调用成功，则A和B的SQL将会被提交，最后执行服务C，它的SQL操作失败，对于应用1消费者而言，服务A和服务B的相关SQL操作已经提交，服务C发生了回滚，这就导致事务不一致。从图2-2可以得知，服务化之后事务不一致主要是由服务分布式部署导致的，因此也被称为分布式事务问题。2.1分布式事务设计方案通常，分布式事务基于两阶段提交实现，它的工作原理示意图如图2-3所示。图2-3两阶段提交原理图阶段1：全局事务管理器向所有事务参与者发送准备请求；事务参与者向全局事务管理器回复自己是否准备就绪。阶段2：全局事务管理器接收到所有事务参与者的回复之后做判断，如果所有事务参与者都可以提交，则向所有事务提交者发送提交申请，否则进行回滚。事务参与者根据全局事务管理器的指令进行提交或者回滚操作。分布式事务回滚原理图如图2-4所示。图2-4分布式事务回滚原理图两阶段提交采用的是悲观锁策略，由于各个事务参与者需要等待响应最慢的参与者，因此性能比较差。第一个问题是协议本身的成本：整个协议过程是需要加锁的，比如锁住数据库的某条记录，且需要持久化大量事务状态相关的操作日志。更为麻烦的是，两阶段锁在出现故障时表现出来的脆弱性，比如两阶段锁的致命缺陷：当协调者出现故障，整个事务需要等到协调者恢复后才能继续执行，如果协调者出现类似磁盘故障等错误，该事务将被永久遗弃。对于分布式服务框架而言，从功能特性上需要支持分布式事务。在实际业务使用过程中，如果能够通过最终一致性解决问题，则不需要做强一致性；如果能够避免分布式事务，则尽量在业务层避免使用分布式事务。2.2分布式事务优化既然分布式事务有诸多缺点，那么为什么我们还在使用呢？有没有更好的解决方案来改进或者替换呢？如果我们只是针对分布式事务去优化的话，发现其实能改进的空间很小，毕竟瓶颈在分布式事务模型本身。那我们回到问题的根源：为什么我们需要分布式事务？因为我们需要各个资源数据保持一致性，但是对于分布式事务提供的强一致性，所有业务场景真的都需要吗？大多数业务场景都能容忍短暂的不一致，不同的业务对不一致的容忍时间不同。像银行转账业务，中间有几分钟的不一致时间，用户通常都是可以理解和容忍的。在大多数的业务场景中，我们可以使用最终一致性替代传统的强一致性，尽量避免使用分布式事务。在实践中常用的最终一致性方案就是使用带有事务功能的MQ做中间人角色，它的工作原理如下：在做本地事务之前，先向MQ发送一个prepare消息，然后执行本地事务，本地事务提交成功的话，向MQ发送一个commit消息，否则发送一个rollback消息，取消之前的消息。MQ只会在收到commit确认才会将消息投递出去，所以这样的形式可以保证在一切正常的情况下，本地事务和MQ可以达到一致性。但是分布式调用存在很多异常场景，诸如网络超时、VM宕机等。假如系统执行了local_tx()成功之后，还没来得及将commit消息发送给MQ，或者说发送出去由于网络超时等原因，MQ没有收到commit，发生了commit消息丢失，那么MQ就不会把prepare消息投递出去。MQ会根据策略去尝试询问（回调）发消息的系统（checkCommit）进行检查该消息是否应该投递出去或者丢弃，得到系统的确认之后，MQ会做投递还是丢弃，这样就完全保证了MQ和发消息的系统的一致性，从而保证了接收消息系统的一致性。3.研发团队协作问题服务化之后，特别是采用微服务架构以后。研发团队会被拆分成多个服务化小组，例如AWS的TwoPizzaTeam，每个团队由2~3名研发负责服务的开发、测试、部署上线、运维和运营等。随着服务数的膨胀，研发团队的增多，跨团队的协同配合将会成为一个制约研发效率提升的因素。3.1共用服务注册中心为了方便开发测试，经常会在线下共用一个所有服务共享的服务注册中心，这时，一个正在开发中的服务发布到服务注册中心，可能会导致一些消费者不可用。解决方案：可以让服务提供者开发方，只订阅服务（开发的服务可能依赖其他服务），而不注册正在开发的服务，通过直连测试正在开发的服务。它的工作原理如图3-1所示。图3-1只订阅，不发布3.2直连提供者在开发和测试环境下，如果公共的服务注册中心没有搭建，消费者将无法获取服务提供者的地址列表，只能做本地单元测试或使用模拟桩测试。还有一种场景就是在实际测试中，服务提供者往往多实例部署，如果服务提供者存在Bug，就需要做远程断点调试，这会带来两个问题：1）服务提供者多实例部署，远程调试地址无法确定，调试效率低下。2）多个消费者可能共用一套测试联调环境，断点调试过程中可能被其他消费者意外打断。解决策略：绕过注册中心，只测试指定服务提供者，这时候可能需要点对点直连，点对点直联方式将以服务接口为单位，忽略注册中心的提供者列表。3.3多团队进度协同假如前端Web门户依赖后台A、B、C和D4个服务，分别由4个不同的研发团队负责，门户要求新特性2周内上线。A和B内部需求优先级排序将门户的优先级排的比较高，可以满足交付时间点。但是C和D服务所在团队由于同时需要开发其他优先级更高的服务，因此把优先级排的相对较低，无法满足2周交付。在C和D提供版本之前，门户只能先通过打测试桩的方式完成Mock测试，但是由于并没有真实的测试过C和D服务，因此需求无法按期交付。应用依赖的服务越多，特性交付效率就越低下，交付的速度取决于依赖的最迟交付的那个服务。假如Web门户依赖后台的100个服务，只要1个核心服务没有按期交付，则整个进度就会延迟。解决方案：调用链可以将应用、服务和中间件之间的依赖关系串接并展示出来，基于调用链首入口的交付日期作为输入，利用依赖管理工具，可以自动计算出调用链上各个服务的最迟交付时间点。通过调用链分析和标准化的依赖计算工具，可以避免人为需求排序失误导致的需求延期。3.4服务降级和Mock测试在实际项目开发中，由于小组之间、个人开发者之间开发节奏不一致，经常会出现消费者等待依赖的服务提供者提供联调版本的情况，相互等待会降低项目的研发进度。解决方案：服务提供者首先将接口定下来并提供给消费者，消费者可以将服务降级同Mock测试结合起来，在Mock测试代码中实现容错降级的业务逻辑（业务放通），这样既完成了Mock测试，又实现了服务降级的业务逻辑开发，一举两得。3.5协同调试问题在实际项目开发过程中，各研发团队进度不一致很正常。如果消费者坐等服务提供者按时提供版本，往往会造成人力资源浪费，影响项目进度。解决方案：分布式服务框架提供Mock桩管理框架，当周边服务提供者尚未完成开发时，将路由切换到模拟测试模式，自动调用Mock桩；业务集成测试和上线时，则要能够自动切换到真实的服务提供者上，可以结合服务降级功能实现。3.6接口前向兼容性由于线上的Bug修复、内部重构和需求变更，服务提供者会经常修改内部实现，包括但不限于：接口参数变化、参数字段变化、业务逻辑变化和数据表结构变化。在实际项目中经常会发生服务提供者修改了接口或者数据结构，但是并没有及时知会到所有消费者，导致服务调用失败。解决方案：1）制定并严格执行《服务前向兼容性规范》，避免发生不兼容修改或者私自修改不通知周边的情况。2）接口兼容性技术保障：例如Thrift的IDL，支持新增、修改和删除字段，字段定义位置无关性，码流支持乱序等。4.总结服务化之后，无论是服务化框架，还是业务服务，都面临诸多挑战，本章摘取了其中一些比较重要的问题，并给出解决方案和最佳实践。对于本章节没有列出的问题，则需要服务框架开发者和使用者在实践中探索，找出一条适合自己产品的服务化最佳实践。
9. 数据库运行过程中常见的故障有哪几类试述对各类故障的恢复策略。
数据库运行过程中常见的故障有3类：事物故障、系统故障、介质故障。
恢复策略：
1、事物故障：
发生事务故障时，被迫中断的事务可能已对数据库进行丁修改，为了消除该事务对数据库的影响，要利用日志文件中所记载的信息，强行回滚该事务，将数据库恢复到修改前的初始状态。
为此，要检查日志文件中由这些事务所引起的发生变化的记录，取消这些没有完成的事务所做的一切改变，这类恢复操作称为事务撤销。
2、系统故障：
系统故障的恢复要完成两方面的工作，既要撤销所有末完成的事务，还要重做所有已提交的事务，这样才能将数据库真正恢复到一致的状态。
3、介质故障：
介质故障比事务故障和系统故障发生的可能性要小，但这是最严重的一种故障，破坏性很大，磁盘上的物理数据和日志文件可能被破坏，这需要装入发生介肢纯质故障前最新的后备数据库副本，然后利用日志文件重做该副本后所运行的所有事务。
(9)分布式数据库事务故障恢复原则扩展阅读：
“数据故障恢复”和“完整性约束”、“并发控制”一样，都是数据库数据保护机制中的一种完整性控制。所有的系统都免不了会发生故障，有可能是硬件失灵，有可能是软件系统崩溃，也有可能是其他外界的原因，比如断电等等。
数据库运行的突然中断会使数据库处在一个错误的状态局饥雀，而且故障排除后没有办法让系统精确地从断点继续执行下去。这就要求DBMS要有一套故障后的数据恢复机构，保证数桐早据库能够回复到一致的、正确地状态去。
参考资料来源：网络-事务故障
参考资料来源：网络-系统故障
参考资料来源：网络-介质故障
10. 在分布式系统中，为什么有时难以隐藏故障的发生以及故障恢复过程
分布式系统（distributed system）是建立在网络之上行蚂的软件系统。正是因为软件的特性，所以分布式系统具有高度的内聚性和透明性。因此，网络和分布式系统之间的区别凳虚更多的在于高层软件（特别是操作系统），而不是硬件。内聚性是指每一个数据库分布节点高度自治，有本地的数据库管理系统。透明性是指每一个数据库分布节点对用档粗埋户的应用来说都是透明的，看不出是本地还是远程。在分布式数据库系统中，用户感觉不到数据是分布的，即用户不须知道关系是否分割、有无副本、数据存于哪个站点以及事务在哪个站点上执行等。