- 浏览: 685985 次
- 性别:
- 来自: 上海
文章分类
- 全部博客 (254)
- java分布式应用架构 (22)
- SSH框架整合 (6)
- java web 学习笔记 (49)
- java 学习笔记 (56)
- struts 2 学习 (6)
- Hibernate学习 (10)
- spring 学习 (2)
- 客户端编程(javascript) (4)
- IDE使用 (13)
- 生命 人生 (6)
- 系统维护 (3)
- 技术篇 (10)
- MySql (2)
- J2ME (1)
- java网络编程 (4)
- 数据库 (5)
- C/C++ (8)
- Oracle (7)
- 软件测试 (0)
- 软件的安装和部署 (0)
- Java快讯 (1)
- swt (1)
- Flex (1)
- 软件工程 (1)
- PostgreSQL (1)
- sql server2000 (2)
- 嵌入式数据库sqlite (5)
- J2EE (1)
- XML (1)
- ibatis3(MyBatis) (6)
- Linux&Unix (1)
- velocity (1)
- 回报社会 (4)
- 软件项目管理 (3)
- android研究 (3)
- C# (2)
- Objective-C (1)
- 音乐 (0)
- webx (1)
- JMS (1)
- maven软件项目管理 (1)
- 分布式服务 (0)
- 云平台 (0)
- 分布式存储 (1)
- 分布式系统架构 (0)
- 移动互联网 (1)
- ZooKeeper (1)
最新评论
-
liyys:
楼主,可不可以发这个项目的源码工程出来分享一下,少了几个类。楼 ...
仿照Hibernate实现一个SQLite的ORM框架 -
liyys:
少了一些类的源码没有粘贴出来
仿照Hibernate实现一个SQLite的ORM框架 -
honglei0412:
我使用的是这种方式获取db文件的目录但是 URL p = Fi ...
使用sqlite注意事项 -
honglei0412:
大侠 能不能说明下DbFile您是怎么做的吗?
使用sqlite注意事项 -
ahack:
刚写完mapping才发现早就有人写好了。仔细一看还都是针对的 ...
仿照Hibernate实现一个SQLite的ORM框架
由于数据量的巨大,大部分Web应用都需要部署很多个数据库实例。这样,有些用户操作就可能需要去修改多个数据库实例中的数据。传统的解决方法是使用分布式事务保证数据的全局一致性,经典的方法是使用两阶段提交协议。
长期以来,分布式事务提供的优雅的全局ACID保证麻醉了应用开发者的心灵,很多人都不敢越雷池一步,想像没有分布式事务的世界会是怎样。如今就如MySQL和PostgreSQL这类面向低端用户的开源数据库都支持分布式事务了,开发者更是沉醉其中,不去考虑分布式事务是否给系统带来了伤害。
事实上,有所得必有所失,分布式事务提供的ACID保证是以损害系统的可用性、性能与可伸缩性为代价的。只有在参与分布式事务的各个数据库实例都能够正常工作的前提下,分布式事务才能够顺利完成,只要有一个工作不正常,整个事务就不能完成。这样,系统的可用性就相当于参加分布式事务的各实例的可用性之积,实例越多,可用性下降越明显。从性能和可伸缩性角度看,首先是事务的总持续时间通常是各实例操作时间之和,因为一个事务中的各个操作通常是顺序执行的,这样事务的响应时间就会增加很多;其次是一般Web应用的事务都不大,单机操作时间也就几毫秒甚至不到1毫秒,一但涉及到分布式事务,提交时节点间的网络通信往返过程也为毫秒级别,对事务响应时间的影响也不可忽视。由于事务持续时间延长,事务对相关资源的锁定时间也相应增加,从而可能严重增加了并发冲突,影响到系统吞吐率和可伸缩性。
正是由于分布式事务有以上问题,eBay在设计上就不采用分布式事务,而是通过其它途径来解决数据一致性问题。其中使用的最重要的技术就是消息队列和消息应用状态表。
举个例子。假设系统中有以下两个表
其中user表记录用户交易汇总信息,transaction表记录每个交易的详细信息。
这样,在进行一笔交易时,若使用事务,就需要对数据库进行以下操作:
即在transaction表中记录交易信息,然后更新卖家和买家的状态。
假设transaction表和user表存储在不同的节点上,那么上述事务就是一个分布式事务。要消除这一分布式事务,将它拆分成两个子事务,一个更新transaction表,一个更新user表是不行的,因为有可能transaction表更新成功后,更新user失败,系统将不能恢复到一致状态。
解决方案是使用消息队列。如下所示,先启动一个事务,更新transaction表后,并不直接去更新user表,而是将要对user表进行的更新插入到消息队列中。另外有一个异步任务轮询队列内容进行处理。
述解决方案看似完美,实际上还没有解决分布式问题。为了使第一个事务不涉及分布式操作,消息队列必须与transaction表使用同一套存储资源,但为了使第二个事务是本地的,消息队列存储又必须与user表在一起。这两者是不可能同时满足的。
如果消息具有操作幂等性,也就是一个消息被应用多次与应用一次产生的效果是一样的话,上述问题是很好解决的,只要将消息队列放到transaction表一起,然后在第二个事务中,先应用消息,再从消息队列中删除。由于消息队列存储与user表不在一起,应用消息后,可能还没来得及将应用过的消息从队列中删除时系统就出故障了。这时系统恢复后会重新应用一次这一消息,由于幂等性,应用多次也能产生正确的结果。
但实际情况下,消息很难具有幂等性,比如上述的UPDATE操作,执行一次和执行多次的结束显然是不一样的。解决这一问题的方法是使用另一个表记录已经被成功应用的消息,并且这个表使用与user表相同的存储。假设增加以下表 message_applied(msg_id)记录被成功应用的消息,则产生最终的解决方案如下:
我们来仔细分析一下:
1、消息队列与transaction使用同一实例,因此第一个事务不涉及分布式操作;
2、message_applied与user表在同一个实例中,也能保证一致性;
3、第二个事务结束后,dequeue message之前系统可能出故障,出故障后系统会重新从消息队列中取出这一消息,但通过message_applied表可以检查出来这一消息已经被应用过,跳过这一消息实现正确的行为;
4、最后将已经成功应用,且已经从消息队列中删除的消息从message_applied表中删除,可以将message_applied表保证在很小的状态(不清除也是可以的,不影响系统正确性)。由于消息队列与message_applied在不同实例上,dequeue message之后,将对应message_applied记录删除之前可能出故障。一但这时出现故障,message_applied表中会留下一些垃圾内容,但不影响系统正确性,另外这些垃圾内容也是可以正确清理的。
虽然由于没有分布式事务的强一致性保证,使用上述方案在系统发生故障时,系统将短时间内处于不一致状态。但基于消息队列和消息应用状态表,最终可以将系统恢复到一致。使用消息队列方案,解除了两个数据库实例之间的紧密耦合,其性能和可伸缩性是分布式事务不可比拟的。
当然,使用分布式事务有助于简化应用开发,使用消息队列明显需要更多的工作量,两者各有优缺点。个人观点是,对于时间紧迫或者对性能要求不高的系统,应采用分布式事务加快开发效率,对于时间需求不是很紧,对性能要求很高的系统,应考虑使用消息队列方案。对于原使用分布式事务,且系统已趋于稳定,性能要求高的系统,则可以使用消息队列方案进行重构来优化性能。
长期以来,分布式事务提供的优雅的全局ACID保证麻醉了应用开发者的心灵,很多人都不敢越雷池一步,想像没有分布式事务的世界会是怎样。如今就如MySQL和PostgreSQL这类面向低端用户的开源数据库都支持分布式事务了,开发者更是沉醉其中,不去考虑分布式事务是否给系统带来了伤害。
事实上,有所得必有所失,分布式事务提供的ACID保证是以损害系统的可用性、性能与可伸缩性为代价的。只有在参与分布式事务的各个数据库实例都能够正常工作的前提下,分布式事务才能够顺利完成,只要有一个工作不正常,整个事务就不能完成。这样,系统的可用性就相当于参加分布式事务的各实例的可用性之积,实例越多,可用性下降越明显。从性能和可伸缩性角度看,首先是事务的总持续时间通常是各实例操作时间之和,因为一个事务中的各个操作通常是顺序执行的,这样事务的响应时间就会增加很多;其次是一般Web应用的事务都不大,单机操作时间也就几毫秒甚至不到1毫秒,一但涉及到分布式事务,提交时节点间的网络通信往返过程也为毫秒级别,对事务响应时间的影响也不可忽视。由于事务持续时间延长,事务对相关资源的锁定时间也相应增加,从而可能严重增加了并发冲突,影响到系统吞吐率和可伸缩性。
正是由于分布式事务有以上问题,eBay在设计上就不采用分布式事务,而是通过其它途径来解决数据一致性问题。其中使用的最重要的技术就是消息队列和消息应用状态表。
举个例子。假设系统中有以下两个表
user(id, name, amt_sold, amt_bought) transaction(xid, seller_id, buyer_id, amount)
其中user表记录用户交易汇总信息,transaction表记录每个交易的详细信息。
这样,在进行一笔交易时,若使用事务,就需要对数据库进行以下操作:
begin; INSERT INTO transaction VALUES(xid, $seller_id, $buyer_id, $amount); UPDATE user SET amt_sold = amt_sold + $amount WHERE id = $seller_id; UPDATE user SET amt_bought = amt_bought + $amount WHERE id = $buyer_id; commit;
即在transaction表中记录交易信息,然后更新卖家和买家的状态。
假设transaction表和user表存储在不同的节点上,那么上述事务就是一个分布式事务。要消除这一分布式事务,将它拆分成两个子事务,一个更新transaction表,一个更新user表是不行的,因为有可能transaction表更新成功后,更新user失败,系统将不能恢复到一致状态。
解决方案是使用消息队列。如下所示,先启动一个事务,更新transaction表后,并不直接去更新user表,而是将要对user表进行的更新插入到消息队列中。另外有一个异步任务轮询队列内容进行处理。
begin; INSERT INTO transaction VALUES(xid, $seller_id, $buyer_id, $amount); put_to_queue “update user(“seller”, $seller_id, amount); put_to_queue “update user(“buyer”, $buyer_id, amount); commit; for each message in queue begin; dequeue message; if message.type = “seller” then UPDATE user SET amt_sold = amt_sold + message.amount WHERE id = message.user_id; else UPDATE user SET amt_bought = amt_bought + message.amount WHERE id = message.user_id; end commit; end
述解决方案看似完美,实际上还没有解决分布式问题。为了使第一个事务不涉及分布式操作,消息队列必须与transaction表使用同一套存储资源,但为了使第二个事务是本地的,消息队列存储又必须与user表在一起。这两者是不可能同时满足的。
如果消息具有操作幂等性,也就是一个消息被应用多次与应用一次产生的效果是一样的话,上述问题是很好解决的,只要将消息队列放到transaction表一起,然后在第二个事务中,先应用消息,再从消息队列中删除。由于消息队列存储与user表不在一起,应用消息后,可能还没来得及将应用过的消息从队列中删除时系统就出故障了。这时系统恢复后会重新应用一次这一消息,由于幂等性,应用多次也能产生正确的结果。
但实际情况下,消息很难具有幂等性,比如上述的UPDATE操作,执行一次和执行多次的结束显然是不一样的。解决这一问题的方法是使用另一个表记录已经被成功应用的消息,并且这个表使用与user表相同的存储。假设增加以下表 message_applied(msg_id)记录被成功应用的消息,则产生最终的解决方案如下:
begin; INSERT INTO transaction VALUES(xid, $seller_id, $buyer_id, $amount); put_to_queue “update user(“seller”, $seller_id, amount); put_to_queue “update user(“buyer”, $buyer_id, amount); commit; for each message in queue begin; SELECT count(*) as cnt FROM message_applied WHERE msg_id = message.id; if cnt = 0 then if message.type = “seller” then UPDATE user SET amt_sold = amt_sold + message.amount WHERE id = message.user_id; else UPDATE user SET amt_bought = amt_bought + message.amount WHERE id = message.user_id; end INSERT INTO message_applied VALUES(message.id); end commit; if 上述事务成功 dequeue message DELETE FROM message_applied WHERE msg_id = message.id; end end
我们来仔细分析一下:
1、消息队列与transaction使用同一实例,因此第一个事务不涉及分布式操作;
2、message_applied与user表在同一个实例中,也能保证一致性;
3、第二个事务结束后,dequeue message之前系统可能出故障,出故障后系统会重新从消息队列中取出这一消息,但通过message_applied表可以检查出来这一消息已经被应用过,跳过这一消息实现正确的行为;
4、最后将已经成功应用,且已经从消息队列中删除的消息从message_applied表中删除,可以将message_applied表保证在很小的状态(不清除也是可以的,不影响系统正确性)。由于消息队列与message_applied在不同实例上,dequeue message之后,将对应message_applied记录删除之前可能出故障。一但这时出现故障,message_applied表中会留下一些垃圾内容,但不影响系统正确性,另外这些垃圾内容也是可以正确清理的。
虽然由于没有分布式事务的强一致性保证,使用上述方案在系统发生故障时,系统将短时间内处于不一致状态。但基于消息队列和消息应用状态表,最终可以将系统恢复到一致。使用消息队列方案,解除了两个数据库实例之间的紧密耦合,其性能和可伸缩性是分布式事务不可比拟的。
当然,使用分布式事务有助于简化应用开发,使用消息队列明显需要更多的工作量,两者各有优缺点。个人观点是,对于时间紧迫或者对性能要求不高的系统,应采用分布式事务加快开发效率,对于时间需求不是很紧,对性能要求很高的系统,应考虑使用消息队列方案。对于原使用分布式事务,且系统已趋于稳定,性能要求高的系统,则可以使用消息队列方案进行重构来优化性能。
发表评论
-
Spring MVC集成velocity扩展
2013-07-23 17:18 32581、扩展velocity的视图 [code=" ... -
【分布式系统工程实现】CAP理论及系统一致性
2013-03-08 16:05 1036印象中CAP理论开始流行 ... -
【分布式系统工程实现】分布式事务
2013-03-08 16:03 1386CAP理论虽然告诉我们,一致性和可用性二者不可兼得,但这并不 ... -
使用MBean获取tomcat和jboss端口
2012-04-10 21:29 2677/** * 根据协议和scheme获取服务端口号 ... -
淘宝网架构概述
2011-12-14 19:45 72众所周知,淘宝网是一 ... -
淘宝网的HttpClient工具
2011-11-23 21:02 47package com.taobao.pegasus.comm ... -
在Tomcat中通过JOTM支持JTA
2011-11-04 15:57 1861<?xml version='1.0' encoding ... -
sql server2005备份还原
2011-09-22 11:29 9671、先建立一个同名数据库,停止SQL SERVER2005 ... -
apache mina开发文件传输服务器
2011-09-19 18:03 7735服务器接收端 /** * */ package o ... -
使用 Apache MINA 2 开发网络应用
2011-09-19 10:01 1166简介: Apache MINA 2 是一个开发高性能和高可伸缩 ... -
HTTP上传工具
2011-09-14 11:36 1866package com.dayo.tool; impor ... -
定义一个java类型转换器
2011-09-09 19:48 13641、相关接口 package org.liufei.jweb. ... -
使用mina 作代理服务器例子
2011-09-07 14:38 2369import java.net.InetSocketAddre ... -
Java 通过 HTTP 下载文件
2011-09-07 14:35 1081package core.spider; import ... -
Java 的 HTTP 客户端 http4j 示例代码
2011-09-07 14:32 1469package com.google.code.http4j. ... -
获取IP地址
2011-09-07 13:41 2426public String getIpAddrByReques ... -
netty telnet 应用实例server代码
2011-09-07 12:21 1888public class TelnetServer { ... -
Netty中使用Apache Common FileUpload
2011-09-07 12:19 1280/** * 用Netty来实现上传 */ publi ... -
netty实现Socket NIO服务器
2011-09-06 15:58 8795package org.liufei.dccserver; ... -
Netty简介
2011-09-05 15:55 1912Netty 介绍 2010-08-05 15:20 ...
相关推荐
8. **事务支持**:在某些场景下,消息中间件需要保证事务一致性,确保消息在所有参与方之间的一致性状态。 9. **消息路由与过滤**:消息中间件可以根据预定义的规则或筛选条件将消息路由到合适的接收者,提高消息...
分布式呼叫处理系统是一种高效、灵活的通信架构,用于处理大量并发呼叫请求,广泛应用于客服中心、电信运营商等领域。在这样的系统中,一个关键问题是如何有效处理呼叫同抢现象,即多个处理单元同时尝试处理同一个...
- **分布式事务管理**:确保跨分区分区事务的一致性和完整性。 - **数据复制**:创建数据副本,提高数据冗余和灾难恢复能力。 3. **动态数据路由**: - **智能路由**:根据数据分片规则和查询条件将查询路由至...
10. **消息队列(MQ)**:消息队列技术允许应用异步通信,将消息放入队列,然后在合适的时间由消费者处理,这样可以提高系统的响应速度和可靠性,同时减少系统间的直接依赖。 这些技术的综合运用在《实战EJB》中...
使用事务管理、分布式一致性算法等技术手段来确保数据的一致性。 - **高可用架构设计最佳实践** 结合实际案例,分享如何设计一个既可靠又高效的分布式数据存储层。 - **实践案例** 如何根据不同的业务需求和...
分布式项目p2p金融系统是基于点对点网络技术构建的一种现代金融模式,它通过将借贷双方直接连接,消除了传统金融机构的中介角色,降低了交易成本。在这个项目中,我们将会探讨P2P金融系统的核心技术和实现细节。 一...
- **异步调用**:使用消息队列(如RabbitMQ、Kafka)进行请求缓冲,平滑系统负载,但可能影响实时性且需处理消息丢失问题。 2. **关键业务保护**: - **服务降级**:在流量过大时,牺牲非核心功能以保证核心业务...
事务性发件箱模式的优点在于它避免了直接在应用层进行双写操作,消除了因为网络问题导致的数据不一致风险。同时,由于消息发送是异步进行的,不会阻塞订单服务的主要业务流程,提高了服务的响应速度和可用性。 然而...
2PC是一种在分布式环境中协调多个参与节点以达成共识的协议,主要用于确保跨多个数据库或队列的分布式事务的一致性。该协议由Jim Gray在1978年提出,是Paxos算法出现之前的解决方案。 2PC包括两个阶段: 1. **准备...
EJB(Enterprise JavaBeans)是Java EE(Java Platform, Enterprise Edition)平台的核心组成部分,用于构建企业级分布式应用程序。本教程将深入探讨EJB技术及其在J2EE环境中的应用。 一、EJB概述 EJB是一种组件...
JTA提供了一组接口和规范,使得跨多个资源(如数据库和消息队列)的事务管理成为可能。 8. **Java Naming and Directory Interface (JNDI)** JNDI提供了一种查找和绑定服务的接口,常用于在应用服务器中查找资源...
- **状态存储位置**:熟悉状态管理的重要性,了解何时使用缓存、数据库、内存数据库(如Redis)、消息队列等,以优化系统性能和数据持久性。 - **安全问题**:深入掌握安全编程原则,如输入验证、权限控制、加密解密...
EJB是Java平台企业版(Java EE)的核心组成部分,它提供了一种规范化的框架来构建分布式、事务处理、安全性和可伸缩性的企业级应用程序。 在EJB3.0版本中,引入了多项重大改进,旨在简化开发过程,提高生产力,并...
- **ACID、CAP、Base理论**:在理解分布式事务时,需要了解ACID(原子性、一致性、隔离性、持久性)、CAP(一致性、可用性、分区容错性)和Base(基本可用、软状态、最终一致性)理论。 - **Zookeeper基础组件...
- **定义**:消息队列是一种应用程序间通信的中间件实现,用于在发送者和接收者之间传递消息。 - **应用场景**: - **异步处理**:分离消息的发送与处理过程。 - **负载均衡**:平衡处理负载。 - **解耦**:降低...
- **简介**:Apache ZooKeeper 是一个分布式的,开放源码的分布式应用程序协调服务,是集群的管理者,监视着集群中各个节点的状态根据节点提交的反馈进行下一步合理操作。 - **在 Dubbo 中的作用**:Zookeeper ...
MyBatis消除了几乎所有的JDBC代码和参数的手动设置以及结果集的检索,极大简化了基于Java的应用程序的数据访问层的编码工作。 #### 三、工程化与工具 **1. Maven** Maven是一个强大的项目管理和构建工具,可以...
- **消息队列(RabbitMQ, Kafka):** 消息队列用于实现异步处理,提高系统的吞吐量和扩展性。 - **分布式事务:** 学习如何处理分布式事务,确保数据的一致性。 #### 九、项目实践 **目标:** 通过实际项目开发,...
此外,Redis还可以用于实现分布式锁、消息队列等功能。 6. **整合与配置**:将这些组件整合在一起需要合理的配置。Spring的配置文件(如`applicationContext.xml`)会定义bean的定义和依赖关系,而SpringMVC的配置...