消息队列

RabbitMQ是一个在AMQP基础上完整的，可复用的企业消息系统。他遵循Mozilla Public License开源协议。 MQ全称为Message Queue, 消息队列（MQ）是一种应用程序对应用程序的通信方法。应用程序通过读写出入队列的消息（针对应用程序的数据）来通信，而无需专用连接来链接它们。消 息传递指的是程序之间通过在消息中发送数据进行通信，而不是通过直接调用彼此来通信，直接调用通常是用于诸如远程过程调用的技术。排队指的是应用程序通过 队列来通信。队列的使用除去了接收和发送应用程序同时执行的要求。 RabbitMQ安装 1.linux 安装配置epel源 $ rpm -ivh http://dl.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm 安装erlang $ yum -y install erlang 安装RabbitMQ $ yum -y install rabbitmq-server service rabbitmq-server start/stop 2.安装python API pip install pika or easy_install pika 先来一个基于Queue实现生产者消费者模型试试水 #!/usr/bin/env python3 #coding:utf8

Java初识RabbitMQ一消费端限流 为什么要对消费端限流 假设一个场景，首先，我们RabbitMQ服务器上积压了有上万条未处理的消息，我们随便打开一个消费端，巨量的消息就会瞬间全部推送过来，但是我们单个消费端是无法同时处理这么多消息的。 当数据量特别大的时候，我们对生产端限流肯定是不科学的，因为有时候并发量就是特别大，有时候并发量又特别少，我们无法约束生产端，这是用户的行为。所以我们应该对消费端限流，用于保持消费端的稳定，当消息数量激增的时候很有可能造成资源耗尽，以及影响服务的性能，导致系统的卡顿甚至直接崩溃。 怎么实现消费端限流 RabbitMQ给我们提供了 QOS (服务质量保证)功能，即在非自动确认消息的前提下（ autoAck 要设置为false ），如果一定数目的消息未被 ack 前，RabbitMQ服务器不会推送新的消息给消费端。 /** * Request specific "quality of service" settings. * * These settings impose limits on the amount of data the server * will deliver to consumers before requiring acknowledgements. * Thus they provide a means of

线程中通信 在裸机编程中，经常会使用全局变量进行功能间的通信，如某些功能可能由于一些操作而改变全局变量的值，另一个功能对此全局变量进行读取，根据读取到的全局变量值执行相应的动作，达到通信协作的目的； 邮箱 邮箱服务是实时操作系统中一种典型的线程间通信方法。举一个简单的例子，有两个线程，线程 1 检测按键状态并发送，线程 2 读取按键状态并根据按键的状态相应地改变 LED 的亮灭。这里就可以使用邮箱的方式进行通信，线程 1 将按键的状态作为邮件发送到邮箱，线程 2 在邮箱中读取邮件获得按键状态并对 LED 执行亮灭操作。 邮箱的工作机制 RT-Thread 操作系统的邮箱用于线程间通信，特点是开销比较低，效率较高； 邮箱中的每一封邮件只能容纳固定的 4 字节内容（针对 32 位处理系统，指针的大小即为 4 个字节，所以一封邮件恰好能够容纳一个指针）。典型的邮箱也称作交换消息，如下图所示，线程或中断服务例程把一封 4 字节长度的邮件发送到邮箱中，而一个或多个线程可以从邮箱中接收这些邮件并进行处理。 非阻塞方式的邮件发送过程能够安全的应用于中断服务中，是线程、中断服务、定时器向线程发送消息的有效手段。 通常来说，邮件收取过程可能是阻塞的，这取决于邮箱中是否有邮件，以及收取邮件时设置的超时时间。当邮箱中不存在邮件且超时时间不为 0 时，邮件收取过程将变成阻塞方式。在这类情况下

这里面见到的同步和互斥的概念非常清晰，转载自： http://www.cnblogs.com/King-Gentleman/p/4311582.html 一、进程间通信机制 rt-thread操作系统的IPC（Inter-Process Communication，进程间同步与通信）包含有中断锁、调度器锁、信号量、互斥锁、事件、邮箱、消息队列。其中前5个主要表现为线程间同步，邮箱与消息队列表现为线程间通信。本文主要介绍它们的一些特性及使用场合。 1、中断锁 关闭中断也叫中断锁，是禁止多任务访问临界区最简单的一种方式，即使是在分时操作系统中也是如此。当中断关闭的时候，就意味着当前任务不会被其他事件打断（因为整个系统已经不再响应那些可以触发线程重新调度的外部事件），也就是当前线程不会被抢占，除非这个任务主动放弃了处理器控制权。关闭中断/恢复中断API接口由BSP实现，根据平台的不同其实现方式也大不相同。比如在stm32平台中中断锁机制通过关闭中断函数（rt_base_t rt_hw_interrupt_disable(void)，这个函数用于关闭中断并返回关闭中断前的中断状态。）以及恢复中断函数（void rt_hw_interrupt_enable(rt_base_t level)，恢复调用rt_hw_interrupt_disable()函数前的中断状态）实现。 警告:

RabbitMQ拓展 TTL队列/消息 TTL是Time To Live的缩写, 也就是生存时间 RabbitMQ支持消息的过期时间, 在消息发送时可以进行指定 RabbitMQ支持队列的过期时间, 从消息入队列开始计算, 只要超过了队列的超时时间配置, 那么消息会自动清除 生产者 import com . rabbitmq . client . Channel ; import com . rabbitmq . client . Connection ; import com . victoria . rabbitmq . util . ConnectionUtils ; import java . io . IOException ; import java . util . concurrent . TimeoutException ; public class send { private static final String EXCHANGE_NAME = "test_exchange_ttl" ; public static void main ( String [ ] args ) throws IOException , TimeoutException { //获取链接 Connection connection = ConnectionUtils .

一、RabbitMQ简介 RabbitMQ即一个消息队列，主要是用来实现应用程序的异步和解耦，同时也能起到消息缓冲，消息分发的作用。 消息中间件在互联网公司的使用中越来越多，消息中间件最主要的作用是解耦，中间件最标准的用法是生产者生产消息传送到队列，消费者从队列中拿取消息并处理，生产者不用关心是谁来消费，消费者不用关心谁在生产消息，从而达到解耦的目的。在分布式的系统中，消息队列也会被用在很多其它的方面，比如：分布式事务的支持，RPC的调用等等。 RabbitMQ是实现AMQP（高级消息队列）的消息中间件的一种，最初起源于金融系统，用于在分布式系统中存储转发消息，在易用性、扩展性、高可用性等方面表现不俗。RabbitMQ主要是为了实现系统之间的双向解耦而实现的。当生产者大量产生数据时，消费者无法快速消费，那么需要一个中间层保存这个数据。 AMQP，即advanced message queuing protocol，高级消息队列协议，是应用层协议的一个开放标准，为面向消息的中间件设计。消息中间件主要用于组件之间的解耦，消息的发送者无需知道消息使用者的存在，反之亦然。AMQP的主要特征是面向消息、队列、路由（包括点对点和发布/订阅）、可靠安全。 RabbitMQ是一个开源的AMQP实现，服务器用Erlang语言编写，支持多种客户端，如 Python、Ruby、.NET、Java、JMS

对于Kafka与RabbitMQ、ActiveMQ协议，它们具体的区别如下： activemq： activemq支持主从复制、集群。但是集群功能看起来很弱，只有failover功能，即我连一个失败了，可以切换到其他的broker上。这一点貌似不太科学。假设有三个broker，其中一个上面没有consumer，但另外两个挂了，消息会转到这个上面来，堆积起来。看样子activemq还在升级中。 activemq工作模型比较简单。只有两种模式 queue,topics rabbitmq： rabbitmq用erlang写的。安装完才10m不到，在windows上使用也非常方便，在这点上完爆了activemq，java又臭又长没办法啊。rabbitmq给我感觉更像oracle，功能非常强大。安装完，也有实例的概念，可以像建数据库一样，建实例，建用户划权限。同时监控系统也很好用。这些都是好处，同时也是累赘，整体上来说rabbitmq比activemq复杂太多了 kafka： kafka号称为分布式而生。和activemq以及rabbitmq这些企业级队列而言确实更有分布式系统的优势 kafka的优势在于: 传统的消息队列只有两种模式，要么是queue，要么是publish-subscribe发布订阅。在queue模式中，一组消费者消费一个队列，每条消息被发给其中一个消费者。在publish

一. 死锁 死锁概念 死锁是进程之间由于共享资源而造成无限期等待的情况。 判断死锁的四个条件： 一个资源在一个时刻只能给一个进程——互斥 一个进程至少有一个资源且等待其他进程占有的资源——持有并等待 资源只能在进程使用后自愿释放——非抢占 进程i等待进程i+1使用的资源——循环等待 死锁的处理方法 （1）死锁预防 （2）死锁避免 死锁避免：分配资源时判断是否会出现死锁，只有在不会死锁时分配资源。 安全状态 ：针对所有进程已占用的资源，找出进程的执行序列（安全序列），序列的执行保证已有的资源能满足进程序列执行到结束。如果可以找出，系统状态就是安全的，那你要求分配的资源就可以分配给你。 eg:当前占用资源的进程P1~Pn，对进程做排序，要求对任何一个进程，空闲资源（包括之前的进程占用的一些资源）可以满足这个进程的需求。一个进程执行完归还资源。后续的进程，如果当前可用的空闲资源不够，前边一些进程也占用的一些资源，这个进程就会等待前面的进程执行结束，之后就可以拿到所需资源执行了。找到这个排序系统就是安全的。 3. 银行家算法 银行家算法是一种死锁避免的方法。 need(i)线程i未来需要的资源总量是否小于我当前剩余的资源总量。 Work就是空闲资源（包括前面进程占用的后释放的）。 要使得当前的剩余资源可以满足某一个线程的未来需要，迭代到最后可以满足所有线程就找到了一个安全序列。 初始状态

思路 商品秒杀是典型的高并发场景,为了提高性能,减少数据库的访问次数可以把数据加载到redis中,在redis中进行商品的库存减少,而且不会存在线程安全问题,当redis中商品减少成功后,可以把消息推送到rabbitMQ中,实现异步同步到数据库,让数据库按照他自己本身的处理能力到rabbitmq中去取消息. 项目架构 项目架构 <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.0.5.RELEASE</version> <relativePath/> </parent> <properties> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> <maven.compiler.source>1.8</maven.compiler.source> <maven.compiler.target>1.8</maven.compiler.target> </properties> <dependencies> <dependency> <groupId>org.springframework.boot</groupId>

这两天重点学习了下kafka消息队列，对其相关比较重要的问题进行总结。（以下内容均个人理解总结，不对的地方多多指正） 1. kafka组成 有哪些？ Broker：kafka保存消息的中转站，集群中包含多个kafka服务节点，每个kafka服务节点就称为broker。 Topic：主题，用来存储不同类别的消息。 Partition：分区队列，一个Topic包个或多个Partition，在创建Topic时指定包含的Partition数量，kafka的有序性就是通过分区来实现，分区内是有序的。 Replication：副本，一个分区对应有多个副本，分布在不同的Broker上，副本的数量不会大于broker的数量，一个副本作为Leader，所有的读写请求都会通过Leader完成，Follower只负责备份数据所有Follower会自动的从Leader中复制数据，当Leader宕机后， 会从Follower中选出一个新的Leader继续提供服务，实现故障自动转移。 Message：消息，是通信的基本单位。 Producer：消息的生产者，向Kafka的一个topic发布消息，可以指定向某个分区发送消息。 Consumer：消息的消费者，订阅topic并消费其发布的消息。 Consumer Group：每个消费者都属于一个特定的Consumer Group，消费者组之间可以重复消费