消息中间件

webservice 之 axis2 的使用 简单说下如何使用webservice . webservice有个服务端，像数据库，svn，activemq,zookeeper,这些都有服务端。 服务端能做什么：服务端提供一些自定义的函数接口供客户端调用，这些接口做了什么事，怎么做的，客户端不知道，client只需调用即可，该传参数就传参数,最后可以得到返回结果 axis2 的使用 结合eclipse axis2-code-genarator axis2-service-archer 网上很多如何安装和部署的我就不多说了 如何实现的 1:axis2服务端，先编写service-写自己的函数和方法--打包成aar包，放在下载好的axis2-war包里，就可以运行该服务了。 2：客户端，根据服务端的地址生成了相应的java文件，在客户端实现步骤一般为： a: 与服务端创建连接 b:找到对应的方法类（类名与方法一样大，除了类名首字母大写外）,实例化该对象，然后通过该对象set参数值，参数值是方法类的属性 c：得到该方法Response类的实例对象，是通过服务对象stub加方法函数以及参数得到的 d:最后通过response的对象的get_return()方法得到返回值 来源： oschina 链接： https://my.oschina.net/u/1444819/blog/733362

9.1 spring cloud stream 简介 spring cloud stream 是一个用来为微服务应用提供消息驱动能力的框架. 它可以基于 springboot 来单独的创建独立的,可用于生产的 spring 的应用程序. 它通过使用 spring integration 来连接消息代理中间件以实现消息事件驱动. 它为一些一些供应商的消息中间件产品提供了个性化的自动化配置,并且引入了发布-订阅,消费组以及分区这三个核心概念. 快速入门 下面我们通过构建一个简单的示例来对Spring Cloud Stream有一个初步认识。该示例主要目标是构建一个基于Spring Boot的微服务应用，这个微服务应用将通过使用消息中间件RabbitMQ来接收消息并将消息打印到日志中。所以，在进行下面步骤之前请先确认已经在本地安装了RabbitMQ 构建一个Spring Cloud Stream消费者 创建一个基础的Spring Boot工程，命名为：stream-hello 编辑 build.gradle 中的依赖关系，引入Spring Cloud Stream对RabbitMQ的支持，具体如下： dependencies { implementation 'org.springframework.boot:spring-boot-starter-web' implementation

对于大型的互联网业务来说，消息系统是必不可少的基础服务。 子柳 在《淘宝技术这十年》中为大家展示了阿里消息系统架构的概貌，作为集团业务使用的核心基础服务，目前消息系统现在可以承受每天几百亿规模的请求，并在历年的双十一、双十二大促中承受住抗住了更加严峻的考验，消息系统背后的中间件团队还陆续开源了诸如 MetaQ 、 RocketMQ 等项目。近期，InfoQ 采访了阿里消息中间件团队消息和分布式数据层负责人王晶昱（花名：沈询），话题涉及案例中间件系统的选型、系统扩容与数据一致性、团队文化等内容。 InfoQ ：对于阿里的消息中间件系统，大家所广泛了解的是 @ 子柳 在《淘宝技术这十年》中介绍的 Notify ，但是从最近的阿里的开源计划中，我们经常看到 MetaQ / RocketMQ ，在阿里内部 Notify 和 MetaQ 是怎样的关系？我看到早期的 MetaQ 是采用的 Kafaka 的设计思路，那么可能大家就比较好奇 “ 问什么要重复造轮子 ” ，能不能介绍这个方面的考虑以及所做的工作？ 沈询： 要讲明白这个问题，就需要从产品的实际需求角度入手开始做个介绍了。Notify作为一个已经存在了5年多的消息产品，被广泛的应用在整个阿里巴巴集团的大部分消息通信领域。它的核心特性是： 提供事务支持、不保证消息顺序、消息可能会重复、推模型。 因为淘宝是个交易类网站

配置 关于ActiveMQ的配置有几个关键的文件，activemq.xml，jetty.xml和jetty-realm.properties，这几个文件全都在ActiveMQ文件的conf文件夹下 首先我们来看jetty-realm.properties文件 这两行分别代表的是admin和user两个用户，用户admin登录账号密码都是admin，user也一样，我们可以通过修改这个文件进行一些操作，增加用户，修改密码等，需要注意的是冒号后面的第一个是密码，第二个是账号，如我们想要把admin的密码改成123 修改之后保存重启我们的ActiveMQ，从http://localhost:8161登录我们管理界面输入新的账号密码才能进入。 jetty.xml文件中是控制台的安全配置 < bean id = "securityConstraint" class = "org.eclipse.jetty.util.security.Constraint" > < property name = "name" value = "BASIC" / > < property name = "roles" value = "user,admin" / > < ! -- set authenticate = false to disable login -- > < property name =

RabbitMQ 的高可用性 RabbitMQ 是比较有代表性的，因为是 基于主从 （非分布式）做高可用性的。 RabbitMQ 有三种模式：单机模式、普通集群模式、镜像集群模式。 单机模式： Demo 级别、本地启动，生产不使用该模式 普通集群模式（无高可用性）： 在多台机器上启动多个 RabbitMQ 实例，每个机器启动一个实例。 创建的 queue，只会放在其中一个 RabbitMQ 实例上 ，但是每个实例都同步 queue 的元数据（元数据可以认为是 queue 的一些配置信息，通过元数据，可以找到 queue 所在实例）。消费的时候，实际上如果连接到了另外一个实例，那么那个实例会从 queue 所在实例上拉取数据过来。 缺点：普通集群提高吞吐量，没有分布式，不存在高可用性 镜像集群模式（高可用性）： 创建的 queue，无论元数据还是 queue 里的消息都会 存在于多个实例上 。每个 RabbitMQ 节点都有 queue 的一个 完整镜像 ，包含 queue 的全部数据。然后每次写消息到 queue 的时候，都会自动把 消息同步 到多个实例的 queue 上。 如何开启镜像集群模式？ 在 RabbitMQ后台新增 镜像集群模式的策略， 指定的时候是可以要求数据同步到所有节点的，也可以要求同步到指定数量的节点，再次创建 queue 的时候，应用这个策略

导语   RabbitMQ 是现在比较热门的消息中间件，在互联网行业和传统行业都有大量地使用。消息中间件有很多，RabbitMQ在高可靠、易扩展、高可用等方面都有很大的优势。在学习RabbitMQ的过程中都有所提升。 文章目录 消息中间件介绍 消息中间件作用 解耦 存储 扩展性 流量削峰 可恢复 顺序保证 缓冲 异步通信 RabbitMQ 起源 总结 消息中间件介绍   消息(Message) 在应用之前传递数据，消息可以是一个字符串，也可以是JSON数据，XML数据等等，当然也可以是复杂的对象。对于消息这个是一个抽象的定义，在任何应用之间的数据传递都可以称为消息，例如QQ消息，微信消息等等。   消息队列中间件(Message Queue Middleware，简称MQM)是指高效的传递机制进行平台之间的与平台无关的数据交流，基于数据通信的方式来进行分布式系统的集成。通过提供一个消息队列和消息的排队模型，可以在分布式环境下进行扩展消息传递。   对于消息中间件来说一般有两种传递模式，当然也有其他的，但是常用的就是以下的两种方式 点对点模式 发布订阅模式   点对点模式是基于队列的模式，消息生产者发送消息到消息队列，消息消费者从队列中接收消息，队列的存在使得消息的异步传递称为可能，例如在RocketMQ中消息的落地，可以使得消息重传。  

1、消息中间件 1、简介 消息中间件也可以称消息队列，是指用高效可靠的消息传递机制进行与平台无关的数据交流，并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息队列模型，可以在分布式环境下扩展进程的通信。 当下主流的消息中间件有RabbitMQ、Kafka、ActiveMQ、RocketMQ等。其能在不同平台之间进行通信，常用来屏蔽各种平台协议之间的特性，实现应用程序之间的协同。优点在于能够在客户端和服务器之间进行同步和异步的连接，并且在任何时刻都可以将消息进行传送和转发，是分布式系统中非常重要的组件，主要用来解决应用耦合、异步通信、流量削峰等问题。 2、作用 1、消息中间件主要作用 解耦 冗余(存储) 扩展性 削峰 可恢复性 顺序保证 缓冲 异步通信 2、消息中间件的两种模式 1、P2P模式 P2P模式包含三个角色：消息队列（Queue）、发送者(Sender)、接收者(Receiver)。每个消息都被发送到一个特定的队列，接收者从队列中获取消息。队列保留着消息，直到它们被消费或超时。 P2P的特点： 每个消息只有一个消费者（Consumer），即一旦被消费，消息就不再在消息队列中 发送者和接收者之间在时间上没有依赖性，也就是说当发送者发送了消息之后，不管接收者有没有正在运行它不会影响到消息被发送到队列 接收者在成功接收消息之后需向队列应答成功

前提 之前有个打算在学习RabbitMQ之前，把AMQP详细阅读一次，挑出里面的重点内容。后来找了下RabbitMQ的官方文档，发现了有一篇文档专门介绍了RabbitMQ中实现的AMQP模型部分，于是直接基于此文档和个人理解写下这篇文章。 AMQP协议 AMQP 全称是Advanced Message Queuing Protocol，它是一个(分布式)消息传递协议，使用和符合此协议的客户端能够基于使用和符合此协议的消息传递中间件代理(Broker，也就是经纪人，个人感觉叫代理合口一些)进行通信。AMQP目前已经推出协议1.0，实现此协议的比较知名的产品有StormMQ、RabbitMQ、Apache Qpid等。RabbitMQ实现的AMQP版本是0.9.1，官方文档中也提供了该协议pdf文本下载，有兴趣可以翻阅一下。 消息中间件代理的职责 Messaging Broker，这里称为消息中间件代理。它的职责是从发布者(Publisher，或者有些时候称为Producer，生产者)接收消息，然后把消息路由到消费者(Consumer，或者有些时候称为Listener，监听者)。 因为消息中间件代理、发布者客户端和消费者客户端都是基于AMQP这一网络消息协议，所以消息中间件代理、发布者客户端和消费者客户端可以在不同的机器上，从而实现分布式通讯和服务解耦。

消息队列中间件是分布式系统中重要的组件，主要解决应用解耦，异步消息，流量削锋等问题，实现高性能，高可用，可伸缩和最终一致性架构。目前使用较多的消息队列有ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaMQ，RocketMQ。消息中间件到底该如何使用，何时使用这是一个问题，胡乱地使用消息中间件增加了系统的复杂度，如果用不好消息中间件还不如不用。 消息队列通讯模式 点对点通讯 点对点方式是最为传统和常见的通讯方式，它支持一对一、一对多、多对多、多对一等多种配置方式，支持树状、网状等多种拓扑结构。 多点广播 MQ适用于不同类型的应用。其中重要的，也是正在发展中的是"多点广播"应用，即能够将消息发送到多个目标站点(DestinationList)。可以使用一条MQ指令将单一消息发送到多个目标站点，并确保为每一站点可靠地提供信息。MQ不仅提供了多点广播的功能，而且还拥有智能消息分发功能，在将一条消息发送到同一系统上的多个用户时，MQ将消息的一个复制版本和该系统上接收者的名单发送到目标MQ系统。目标MQ系统在本地复制这些消息，并将它们发送到名单上的队列，从而尽可能减少网络的传输量。 发布/订阅(Publish/Subscribe)模式 发布/订阅功能使消息的分发可以突破目的队列地理指向的限制，使消息按照特定的主题甚至内容进行分发

上图中一个topic配置了3个partition。Partition1有两个offset：0和1。Partition2有4个offset。Partition3有1个offset。副本的id和副本所在的机器的id恰好相同。 如果一个topic的副本数为3，那么Kafka将在集群中为每个partition创建3个相同的副本。集群中的每个broker存储一个或多个partition。多个producer和consumer可同时生产和消费数据。 一 。Broker Kafka 集群包含一个或多个服务器，服务器节点称为broker。 broker存储topic的数据。如果某topic有N个partition，集群有N个broker，那么每个broker存储该topic的一个partition。 如果某topic有N个partition，集群有(N+M)个broker，那么其中有N个broker存储该topic的一个partition，剩下的M个broker不存储该topic的partition数据。 如果某topic有N个partition，集群中broker数目少于N个，那么一个broker存储该topic的一个或多个partition。在实际生产环境中，尽量避免这种情况的发生，这种情况容易导致Kafka集群数据不均衡。 二。Topic 每条发布到Kafka集群的消息都有一个类别