一种分布式数据库同步方案 .

转:http://blog.csdn.net/fangaoxin/article/details/5752526

对于大型企业,业务分布在世界各地,为了改善当地业务服务能力,不得不在当地部署数据库以提高性能,而各个区域之间的数据交互或者同步,成为不可不面对的问题。其间要解决的技术问题主要有:
    1、同步数据的提取。从数据库里提取出需要同步的数据,这包括增、删、改三类动作对数据造成的改变。在数据表安装触发器是提取同步数据的简单有效的手段,而且触发器对应用层而言是透明的,应用程序感觉不到触发器的存在。
    2、同步数据的可靠传输。数据传输可以用队列来实现,例如有MSMQ、IBM MQ Series等。
    3、数据冲突与操作冲突的规避、发现和解决。数据冲突是指两个节点合并数据时,出现约束冲突的情况;而操作冲突是指两个节点同时发生对同一条记录发生操作,导致在双向同步时难以决定两个操作执行的先后顺序。

触发器安装在各个要同步的数据表上,记录对表的增删改操作。所有操作共同记录在一张操作日志表上,以便保证操作发生的顺序。数据发送服务提取操作日志表上的数据,通过消息队列传输到远程服务器,远程服务器接收队列数据后,写入到远程数据表里,从而完成数据同步。
在方案中,本地和远程节点在结构上是对等的,是发送方同时也是接收方,由以下几个部分组成:
1、 数据库服务器:Oracle / SQL Server / DB2 等
2、 操作日志:记录数据表的增删改操作
3、 消息队列:消息队列服务,负责通讯,例如发送和接收消息
4、 抽取发送服务:从操作日志表提取数据,写入消息队列
5、 接收写入服务:从消息队列读取数据,写入到数据库
6、 配置管理服务:配置同步任务、管理监控系统执行情况
7、 配置管理工具:管理配置工具的客户端
8、 适配器:消息队列适配器,减少队列依赖
9、 异常信息库:存放一些无法处理的冲突和意外错误,供管理员处理

时间: 2024-10-12 20:33:16

一种分布式数据库同步方案 .的相关文章

手机端与服务器数据库同步方案

服务器端: 1, 创建数据表 2, 操作数据库的日志. 定义三个字段(id,操作时间,操作内容,分发到所属手机端的用户id) Id: js uuid值 操作时间:2014/8/21 11:32:10 操作内容:以json格式存放select,delete,update之类的 分发到所属手机端的用户id:手机端并不是每个手机用户都需要,选择性的更新数据. 手机端: 建空库,直接取服务器端的操作数据库的日志运行操作.然后取服务器端的操作日志,过滤时间进行操作. 手机端与服务器数据库同步方案

基于SymmetricDS的多主一从数据库同步方案

原文参照:https://blog.csdn.net/seattle0564/article/details/22096901 下面就记录下测试的一款第三方同步方案SymmetricDS(以下简称S)的使用过程,中文资料较少,而且存在一些版本上的差异,导致一些步骤根本不能通过或报错,自己简化了些操作,并没有按照官方的指导操作,鉴于英文水平有限,很多叙述都是基于自己的理解,也请有不同观点的兄弟留言指正或交流. 之所以选择SymmetricDS,大致三个原因: 1.  平台独立.不依赖其他组件包,独

一种异构数据库同步的简单方法

标题有点高大上,是为了解决实际应用中的一个问题.做了一个Android应用,用于记录日常消费账单,开始是单机版的,我老婆说太low了,起码要能看到彼此的消费情况吧.为此,我还专门写了一套基于protobuf的RPC组件,用于网络通信,http://www.cnblogs.com/zmkeil/p/5176758.html. 应用本身比较简单,几张简单粗暴的UI,涵盖了增.删.改各种功能,外加一个后台service组件,用于上传账单,并同步他人账单.也算是麻雀虽小五脏俱全吧,看几张效果图.代码见h

数据库同步方案

1--所有的表添加'datatsp和datatsp_int' --select * from sysobjects where xtype='U' order by name --数据库中所有的只具有一个主键表添加'datatsp和datatsp_int' declare @table_name varchar(50), @sql varchar(8000), @col_key varchar(50) declare cur_tb cursor for select distinct table

两种分布式锁实现方案(一)

一.为何使用分布式锁?当应用服务器数量超过1台,对相同数据的访问可能造成访问冲突(特别是写冲突).单纯使用关系数据库比如MYSQL的应用可以借助于事务来实现锁,也可以使用版本号等实现乐观锁,最大的缺陷就是可用性降低(性能差).对于GLEASY这种满足大规模并发访问请求的应用来说,使用数据库事务来实现数据库就有些捉襟见肘了.另外对于一些不依赖数据库的应用,比如分布式文件系统,为了保证同一文件在大量读写操作情况下的正确性,必须引入分布式锁来约束对同一文件的并发操作. 二.对分布式锁的要求1.高性能(

内存数据库的分布式数据库架构

author:skate time:2012/02/16 转载一篇文章: 本文提出了一种通过引入内存数据库层,建立两层多分区分布式数据库架构.此方案用于解决海量高并发系统的数据存储和访问问题,尤其适用于电子商务等数据模型复杂且业务复杂的互联网站. 这些年互联网站发展迅猛,为应对海量数据下的高并发访问,产生了各种分布式架构设计思想,例如Key-Value引擎,数据分区等.而对于电子商务类网站,海量数据问题还有一个重要特点,就是数据结构化及数据之间的关联,淘宝如此,阿里巴巴也是如此,这是与社区.视频

浅谈分布式数据库

基本概念 1) 单库,就是一个库 ? 2) 分片(sharding),分片解决扩展性问题,引入分片,就引入了数据路由和分片键的概念.分表解决的是数据量过大的问题,分库解决的是数据库性能瓶颈的问题. ? 3) 分组(group),分组解决可用性问题,分组通常通过主从复制(replication)的方式实现.(各种可用级别方案单独介绍) ? 4) 互联网公司数据库实际软件架构是(大数据量下):又分片,又分组(如下图) 数据分片简介和问题 数据分片是按照某个维度将存放在单一数据库中的数据分散地存放至多

微服务架构下的分布式限流方案思考

1.微服务限流 随着微服务的流行,服务和服务之间的稳定性变得越来越重要.缓存.降级和限流是保护微服务系统运行稳定性的三大利器.缓存的目的是提升系统访问速度和增大系统能处理的容量,而降级是当服务出问题或者影响到核心流程的性能则需要暂时屏蔽掉,待高峰或者问题解决后再打开,而有些场景并不能用缓存和降级来解决,比如稀缺资源.数据库的写操作.频繁的复杂查询,因此需有一种手段来限制这些场景的请求量,即限流. 比如当我们设计了一个函数,准备上线,这时候这个函数会消耗一些资源,处理上限是1秒服务3000个QPS

分布式数据库选型——数据水平拆分方案

概述 水平拆分的概念随着分布式数据库的推广已为大部分人熟知.分库分表.异构索引.小表广播.这些功能几乎是产品功能需求标配.然而有些客户使用分布式数据库后的体验不尽如意.本文尝试从数据的角度总结分布式数据的复制(replication)和分区(partition)技术原理和方案,其中分区也有称为分片(sharding),希望能引起读者一些思考,在分布式数据库选型中能注意这些细节的区别,选择适合业务的数据水平拆分方案. 分布式数据库架构 分布式数据库以集群形式存在,有多个节点.集群架构有共享磁盘架构