语源科技BlogJava-永恒瞬间

AMQP与QPID简介

永恒瞬间 — Mon, 02 Jan 2012 09:18:00 GMT

自已整理的一些零散的知识点

简介

AMQP（消息队列协议，Advanced Message Queuing Protocol）是一种消息协议，等同于JMS，但是JMS只是java平台的方案，AMQP是一个跨语言的协议。

AMQP 不分语言平台,最初来自JPMorgon,因为业务需要而滋生，很快从金融界推广到整个计算机界流行起来。

AMQP 目前还是一个草案，最新版本是：0.10

Publisher --->Exchange ---> MessageQueue --->Consumer

整个过程是异步的.Publisher,Consumer相互不知道对方的存在

Exchange负责交换/路由，依靠Routing Key,每个消息者有一个Routing Key

每个Binding将自已感兴趣的RoutingKey告诉Exchange,以便Exchange将相关的

消息转发给相应的Queue

几个概念

Producer,Routing Key,Exchange,Binding,Queue,Consumer.

Producer: 消息的创建者，消息的发送者

Routing Key：唯一用来映射消息该进入哪个队列的标识

Exchange：负责消息的路由，交换

Binding:定义Queue和Exchange的映射关系

Queue：消息队列

Consumer：消息的使用者

Exchange类型

Fan-Out:类似于广播方式，不管RoutingKey

Direct:根据RoutingKey,进行关联投寄

Topic:类似于Direct,但是支持多个Key关联，以组的方式投寄。

key以.来定义界限。类似于usea.news,usea.weather.这两个消息是一组的。

QPID

QPID是AMQP的一个实现，提供C++，JAVA版本的broker,支持多种语言客户端。

基本功能外提供以下特性：

采用 Corosync(?)来保证集群环境下的Fault-tolerant(?) 特性

支持XML的Exchange,消息为XML时，彩用Xquery过滤

支持plugin

提供安全认证，可对producer/consumer提供身份认证

qpidd --port --no-data-dir --auth

port:端口

--no-data-dir:不指定数据目录

--auth：不启用安全身份认证

启动后自动创建一些Exchange,amp.topic,amp.direct,amp.fanout

tools:

Qpid-config:维护Queue,Exchange,内部配置

Qpid-route:配置broker Federation(联盟？集群？)

Qpid-tool:监控

参考：

关于AMQP更多信息可参考： http://www.openamq.org/doc:amqp-background

关于QPID的更多和使用可参考：http://qpid.apache.org/

永恒瞬间 2012-01-02 17:18 发表评论

分布式事务简述

永恒瞬间 — Sat, 20 Aug 2011 16:02:00 GMT

随着系统越来越大，不断的模块化和SOA化，你的系统可能被分散于不同的机器上，这时候，你原先的单机本地事务可能已经无法满足你的需求，你可能要跨系统跨资源的去使用事务。这就是分布式事务。
事务有四个特性：

原子性
一致性
隔离性
持久性

具体就不多介绍了，相信大家都能明白ACID特性的基本含义。

事务模型

而一个具体的事务需要涉及到的模型（无论哪种模型）一般由下面几部分组成：

AP 应用程序
RM 资源管理器
TM 事务管理器

这里的资源管理器一般指数据库资源，而事务管理器，大多是由数据库厂商提供。
那么其实在分布式事务中，也应该符合以上事务的特性和模型，只是资源管理器(RM)变得多了起来.

分布式事务介绍

分布式事务最大的问题在于如何确定资源的状态，以及保证一致性，原子性。
一般来说分布事务由

原子提交协议
协调器
参与者
事务恢复器
死锁检测器

五部分组成。

原子提交协议指的是如何保证原子提交，一般分为单阶段原子提交协议，两阶段原子提交协议，三阶段原子提交协议。

对于单阶段原子提交协议来说，根本没有办法保证分布式事务的原子性，所以不适用于分布式事务中。

两阶段原子提交协议则是各种分布式事务实现中使用最广泛的一种原子提交协议：它主要是交事务提交的过程分为二阶段，投票和最终提交。事务由协调者发起一个事务，参与者加入到事务中后，第一阶段时候，所有的参与者准备资源，并将资源hold住，协调者询问所有的参与者是否可以提交？所有的参与者向协调者响应结果YES/NO,当所有的协调者都响应YES的时候，协调者才会发起第二阶段，向所有的参与者通知提交事务，当所有的参与者都提交确认会会再通知协调者。至此事务处理完毕。

三阶段提交协议由于协调者与参与者多次进行沟通所以代价很大，一般不会使用。但是它能缩小事务处理“不确定”状态的延迟时间。

所谓“不确定”状态就是指当参与者向协调者反馈可以提交的时候，长时间没有收到协调者的通知，这时候参与者没有办法确定事务最终需要如何处理，所以状态为不确定状态。

协调者，参与者一般通过如下动作来进行通信：

join:由协调者提供，用来注册新的参与者
canCommit：协调者询问参与者是否能够提交
doCommit ：协调者通知参与者提交事务
doAbort：协调者通知参与者放弃事务
haveCommit：参与者向协调者确认已经提交事务
getDecision：当处于“不确定”状态时，参与者用来询问协调者事务的目前状态。

对于haveCommit特别说明一下，是当第一阶段的时候，协调者发现长时间参与者没有向协调者反馈事务状态，则协调者会主动调用该接口事务的情况，如果仍然无响应，则会通知所有的参与者放弃该事务。

任何事情都会有意外产生，特别是对于跨系统间的通信更容易产生问题，比如网络异常，机器down机，这个时候就需要事务恢复器来作相应的处理。

对于处于第一阶段的事务，如果参与者发生意外，则协调者会通知所有的参与者进行事务放弃，但是如果协调者出生故障时，就必须要能够就行事务恢复，所以协调者必须在开始事务的时候，产生唯一的事务ID,并且对事务进行持久化，在协调者恢复的时候，参够让人参与者继续进行事务。

而对于第二阶段出现的故障，由于第一阶段进行了资源的个决，则事务认为是必然能成功的，这个事候，如果这个时候参与者发生故障，则协调者需要一套重试机制，让参与者在恢复过来后，能够将事务进行完成或者人工介入。

关于死锁检测器这里就不多描述了，以后有机会再描述。

语言组织能力比较差，太久没有写东西，凑合着写给自已看吧。

永恒瞬间 2011-08-21 00:02 发表评论

分布式系统领域经典论文翻译集

永恒瞬间 — Tue, 16 Aug 2011 04:20:00 GMT

摘要: 转自: 弯曲评论【陈怀临：这个年轻人很优秀。优秀的不仅仅是能把这些经典论文看完，而是还花心思翻译出来。他的博客是：银河里的星星。其联系方式是phylips@bmy】分布式领域论文译序sql&nosql年代记海量数据的存储计算和查询一．google论文系列1. google系列论文译序2. &n... 阅读全文

永恒瞬间 2011-08-16 12:20 发表评论

Clojure Collections 集合类型简要介绍

永恒瞬间 — Fri, 29 Jul 2011 17:01:00 GMT

Clojure语言本身自已有提供了四种集合类型，List,Vector,Set,Map.同时它也可以使用Java的集合类型砂，但是这种方式目前并不推荐使用，因为Clojure集合类型和Java语言的集合类型还是有很大区别的，主要体现在集合内容不可改变，集合的内容可以多种类型以及持久化。持久化意味着当你在对一个集合的操作都会产生一个新的集合对象（如：插入，删除......)，而老的集合对象依然是存在的。

List
List的可以使用如下方式定义:
(def list1 '("aa" "bb" "cc"))
(def list1 (list "aa" "bb" "cc"))
(def list1 (quote ("aa" "bb" "cc")))
以上三种方式都可以定义一个List,和Java中一样List是有序的。

Vector
vector可以使用如下方式定义：
(def v ["v1" "v2"])
(def v (vector "v1" "v2"))
同样vector也是有序的，在Clojure的方法参数定义就是使用的Vector,比如定义一个类以于Java的public void say(String name)用Clojure则使用如下的方式
(defn say [name])

Set
set可以使用如下方式定义:
(def s {"aa" "bb" "cc"})
(def s #{"aa" "bb" "cc"})
(def s (hash-set "aa" "bb" "cc"))

Set分可有序set和无序set,上面示例中的"hash-set"就是代表无序set,而有序set则可用 sorted-set来定义.
可以用函数 contains? 来检测一个set中是否存在某个元素 (contains? s "aa") 如果s中存在"aa"元素，则返回true,否则返回false.
contains?函数可以使用在Set和Map无素上。
同Java中一样。Set中的元素是唯一的。

Map
map可以使用如下方式定义:
(def m {"k1" "v1","k2" "v2"})
(def m (hash-map "k1" "v1","k2" "v2"))
同样，map也分为有序和无序的，如果想申明有序的map则使用 sorted-map即可。
可以使用函数keys,vals得到键集合和值集合.(keys m)
get函数可以根据key取得相应的val值。(get m "k1") 返回的是"v1"
get也可以用在其它的集合中，比如从Vector中取元素的值.(get v 1) 代表取出集合v中的第2个无素。注意，集合的编号是从0开始的。

本部分主要简单介绍了一下Clojure中的集合的基本用法。后续会继续介绍更多的一些东西。

永恒瞬间 2011-07-30 01:01 发表评论

一则多线程死锁案例解析

永恒瞬间 — Tue, 26 Jul 2011 04:44:00 GMT

上周，我们有几个系统发生了线程死锁，导致系统的请求被挂住，无法响应请求。后面查了一下该问题，原来是我厂一个基础组件中使用的锁对象不一致而导致了死锁。

public class SimpleStore {

     private Map sessions = Collections.synchronizedMap(new HashMap());

     synchronized public void remove(String sessionID) { //A1
         sessions.put(sessionID, ""); //A2
         sessions.remove(sessionID);
         System.out.println("remove " + sessionID);
     }

     public void commit(Map attrs, String sessionID, StatusHolder statusHolder) {
         System.out.println("commit " + sessionID);
         synchronized (sessions) { //B1
             remove(sessionID); // B2
         }
     }
}

上面代码中：

private Map sessions = Collections.synchronizedMap(new HashMap());

将sessions这个map申明为线程安全的map,则操作map中的任何方法时，都会加锁，并且会锁住sessions对象。这行代码，则在外部线程访问remove方法时会锁住SimpleStore这个对象。

synchronized public void remove(String sessionID);

可以看到，目前在同一个类或者方法中，有两把锁，并且锁对象不是同一个，那下面我们看看线程是怎么被死锁住的：
1, 假设A线程先调用remove方法，则这时会把simpleStore给锁住，然后执行sessions.put(sessionID, “”)的时候，会尝试锁住sessions
2, 同时B线程调用commit方法，在 synchronized (sessions) 时，会先锁住sessions对象，并且在调用接下来的remove()试，会尝试锁住 SimpleStore对象，至此，线程A和线程B终于成功完成死锁。

所以在使用多线程时一定要特别注意，使用锁一定要注意你的锁对象是否一致。要不然就有可能死锁了~

永恒瞬间 2011-07-26 12:44 发表评论

ORA-00257 解决方法以及归档日志存放容量满的解决方法

永恒瞬间 — Thu, 02 Sep 2010 23:36:00 GMT

第一种解决方式：关闭闪回功能，可以使用如果下语句

alter database flashback off

不建议在正式环境使用这种方法，如果在开发环境则可以尝试使用这种方法。因为必竟开发环境对于数据的恢复没有什么要求，没有多大的概率用到闪回。
第二种解决方式：将闪回日志文件的最大容量调高，可以使用如下语句

alter system set DB_RECOVERY_FILE_DEST_SIZE=20g

可以通过如果下语句查看目前闪回文件的大小以及使用情况

select * from v$recovery_file_dest;

永恒瞬间 2010-09-03 07:36 发表评论