消息队列

本文是大型网站架构系列：消息队列（二），主要分享JMS消息服务，常用消息中间件（Active MQ，Rabbit MQ，Zero MQ，Kafka）。【第二篇的内容大部分为网络资源的整理和汇总，供大家学习总结使用，最后有文章来源】 本次分享大纲 消息队列概述（见第一篇： 大型网站架构系列：分布式消息队列（一） ） 消息队列应用场景（见第一篇： 大型网站架构系列：分布式消息队列（一） ） 消息中间件示例（见第一篇： 大型网站架构系列：分布式消息队列（一） ） JMS消息服务 常用消息队列 参考（推荐）资料 本次分享总结 四、JMS消息服务 讲消息队列就不得不提JMS 。JMS（JAVA Message Service,java消息服务）API是一个消息服务的标准/规范，允许应用程序组件基于JavaEE平台创建、发送、接收和读取消息。它使分布式通信耦合度更低，消息服务更加可靠以及异步性。 在EJB架构中，有消息bean可以无缝的与JM消息服务集成。在J2EE架构模式中，有消息服务者模式，用于实现消息与应用直接的解耦。 4.1消息模型 在JMS标准中，有两种消息模型P2P（Point to Point）,Publish/Subscribe(Pub/Sub)。 4.1.1 P2P模式 P2P模式包含三个角色：消息队列（Queue），发送者(Sender)，接收者(Receiver)

分布式消息队列 kafka介绍 基本架构 Kafka是开源的分布式消息队列，能够轻松实现高吞吐、可扩展、高可用，并且部署简单快速、开发接口丰富。 kafka分布式消息队列的作用： 解耦：将消息生产阶段和处理阶段拆分开，两个阶段互相独立各自实现自己的处理逻辑，通过kafka提供的消息写入和消费接口实现对消息的连接处理。降低开发复杂度，提高系统稳定性。 高吞吐量：kafka通过顺序读写磁盘提供可以和内存随机读写相匹敌的读写速度，灵活的客户端API设计，利用Linux操作系统提供的“零拷贝”特性减少消息网络传输时间，提供端到端的消息压缩传输，对同一主题下的消息采用分区存储，kafka通过诸多良好的特性利用廉价的机器就可以轻松实现高吞吐率。 高容错、高可用：kafka允许用户对分区配置多副本，kafka将副本均匀分配到各个broker存储，保证同一个分区的副本不会再同一台机器上存储（集群模式下），多副本之间采用Leader-Follower机制同步消息，只有Leader对外提供读写服务，当Leader以外失败、Broker进程关闭、服务宕机等情况导致数据不可用时，kafka会从Follwer中选择一个Leader继续提供读写服务。 可扩展：理论上kafka的性能随着Broker的增多而增加，增加一个Broker只需要为新增加的Broker设置一个唯一编号，编写好配置文件后

本期内容 exactly once 输入不重复 输出不重复 exactly once ：有且仅被执行一次。（不多，不少，一次刚好） 首先和大家聊下概念： 事务是恢复和 并发控制 的基本单位。 事务应该具有4个属性：原子性、一致性、隔离性、持久性。这四个属性通常称为 ACID特性 。 原子性（atomicity）。一个事务是一个不可分割的工作单位，事务中包括的诸操作要么都做，要么都不做。 一致性（consistency）。事务必须是使数据库从一个一致性状态变到另一个一致性状态。一致性与原子性是密切相关的。 隔离性（isolation）。一个事务的执行不能被其他事务干扰。即一个事务内部的操作及使用的数据对并发的其他事务是隔离的，并发执行的各个事务之间不能互相干扰。 持久性（durability）。持久性也称永久性（permanence），指一个事务一旦提交，它对数据库中数据的改变就应该是永久性的。接下来的其他操作或故障不应该对其有任何影响。 简单记忆法则(一持原隔) 如：银行转账，A向B转账500元，这个步骤可以分为A扣500元，B加500元 两部分。 如果 A减500元成功后，在B加500元的时候失败了，那么A减掉的500就不生效。也就是说。要么两个操作都成功，要么两个操作都失败。 先了解下SparkStreaming的数据流转流程 数据一致性的要求： 数据源可靠。数据源产生出来后

前言   那天我和同事一起吃完晚饭回公司加班，然后就群里就有人@我说xxx商户说收不到推送，一开始觉得没啥。我第一反应是不是极光没注册上，就让客服通知商户，重新登录下试试。这边打开极光推送的后台进行检查。后面反应收不到推送的越来越多，我就知道这事情不简单。 事故经过   由于大量商户反应收不到推送，我第一反应是不是推送系统挂了，导致没有进行推送。于是让运维老哥检查推送系统各节点的情况，发现都正常。于是打开RabbitMQ的管控台看了一下，人都蒙了。已经有几万条消息处于 ready 状态，还有几百条 unacked 的消息。   我以为推送服务和MQ连接断开了，导致无法推送消息，于是让运维重启推送服务，将所有的推送服务重启完，发现 unacked 的消息全部变成 ready ，但是没过多久又有几百条 unacked 的消息了，这个就很明显了能消费，没有进行 ack 呀。   当时我以为是网络问题，导致mq无法接收到 ack ，让运维老哥检查了一下，发现网络没问题。现在看是真的是傻，网络有问题连接都连不上。由于确定的是无法 ack 造成的，立马将 ack模式 由原来的 manual 改成 auto 紧急发布。将所有的节点升级好以后，发现推送正常了。   你以为这就结束了其实并没有，没过多久发现有一台MQ服务出现异常，由于生产采用了 镜像队列 ，立即将这台有问题的MQ从集群中移除

背景 作为中国最大的在线教育站点，目前沪江日志服务的用户包含网校，交易，金融，CCTalk 等多个部门的多个产品的日志搜索分析业务，每日产生的各类日志有好十几种，每天处理约10亿条（1TB）日志，热数据保留最近7天数据，冷数据永久保存。 为什么做日志系统 首先，什么是日志？ 日志就是程序产生的，遵循一定格式（通常包含时间戳）的文本数据 通常日志由服务器生成，输出到不同的文件中，一般会有系统日志、 应用日志、安全日志。这些日志分散地存储在不同的机器上。 通常当系统发生故障时，工程师需要登录到各个服务器上，使用 grep / sed / awk 等 Linux 脚本工具去日志里查找故障原因。在没有日志系统的情况下，首先需要定位处理请求的服务器，如果这台服务器部署了多个实例，则需要去每个应用实例的日志目录下去找日志文件。每个应用实例还会设置日志滚动策略（如：每天生成一个文件），还有日志压缩归档策略等。 这样一系列流程下来，对于我们排查故障以及及时找到故障原因，造成了比较大的麻烦。因此，如果我们能把这些日志集中管理，并提供集中检索功能，不仅可以提高诊断的效率，同时对系统情况有个全面的理解，避免事后救火的被动。 我认为，日志数据在以下几方面具有非常重要的作用： 数据查找 ：通过检索日志信息，定位相应的 bug ，找出解决方案 服务诊断 ：通过对日志信息进行统计、分析

原文：https://www.jianshu.com/p/e1258c004314 RabbitMQ作为AMQP的代表性产品，在项目中大量使用。结合现在主流的spring boot，极大简化了开发过程中所涉及到的消息通信问题。 首先正确的安装RabbitMQ及运行正常。 RabbitMQ需啊erlang环境，所以首先安装对应版本的erlang，可在RabbitMQ官网下载 # rpm -ivh erlang-19.0.4-1.el7.centos.x86_64.rpm 使用yum安装RabbitMQ,避免缺少依赖包引起的安装失败 # yum install rabbitmq-server-3.6.6-1.el7.noarch.rpm 启动RabbitMQ # /sbin/service rabbitmq-server start 由于RabbitMQ默认提供的guest用户只能本地访问，所以额外创建用户用于测试 # /sbin/rabbitmqctl add_user test test123 用户名：test，密码：test123 开启web管理插件 # rabbitmq-plugins enable rabbitmq_management 并使用之前创建的用户登录,并设置该用户为administrator,虚拟主机地址为/ spring boot 引入相关依赖

工作中经常用到rabbitmq,而用的语言主要是python，所以也就经常会用到python中的pika模块，但是这个模块的使用，也给我带了很多问题，这里整理一下关于这个模块我在使用过程的改变历程已经中间碰到一些问题 的解决方法 刚开写代码的小菜鸟 在最开始使用这个rabbitmq的时候，因为本身业务需求，我的程序既需要从rabbitmq消费消息，也需要给rabbitmq发布消息，代码的逻辑图为如下： 下面是我的模拟代码： #! /usr/bin/env python3 # .-*- coding:utf-8 .-*- import pika import time import threading import os import json import datetime from multiprocessing import Process # rabbitmq 配置信息 MQ_CONFIG = { "host": "192.168.90.11", "port": 5672, "vhost": "/", "user": "guest", "passwd": "guest", "exchange": "ex_change", "serverid": "eslservice", "serverid2": "airservice" } class RabbitMQServer

RabbitMQ的工作模式之一简单（Simple）模式 由一个生产者，一个消费者组成，消息通过FIFO模式排队。 导入依赖 <!--RabbitMQ的依赖--> <dependency> <groupId>com.rabbitmq</groupId> <artifactId>amqp-client</artifactId> <version>5.7.3</version> </dependency> 首先创建工具类，用以生成连接，避免重复书写此段代码 public class RabbitMQUtil { private static ConnectionFactory factory = new ConnectionFactory(); static{ //用户名 factory.setUsername("hello"); //密码 factory.setPassword("123456"); //虚拟机 factory.setVirtualHost("/myhost"); //IP地址,运行rabbitmq组件的主机ip地址 factory.setHost("192.168.31.14"); //端口 factory.setPort(5672); } public static Connection getConnection(){ Connection connection

1. 消息中间件的核心设计思想 ： 采用 异步 通讯、自动 补偿与重试 、 分布式事务 、解决 流量削峰 问题、系统的 解耦 2. 消息中间件常用名词 : Broker 消息转发端，消息中间件Server端； Message 发送的消息内容 roducer 生产者，向Server端投递消息； Consumer 消费者，向Server端获取消息 MessageId 消息全局id 解决消息幂等性问题 3. 主流的MQ对比分析 ActiveMQ: 基本淘汰(老项目使用) 够轻巧（源代码比RocketMQ多）,支持持久化到数据库， 对队列数较多的情况支持不好。 RabbitMQ: 结合erlang语言本身的并发优势，支持很多的协议：AMQP，XMPP, SMTP, STOMP， 也正是如此，使的它变的非常重量级，更适合于企业级的开发。 RocketMQ: 阿里系下开源的一款分布式、队列模型的消息中间件，原名Metaq，3.0版本名称改为RocketMQ， 是阿里参照kafka设计思想使用java实现的一套mq,同时将阿里系内部多款mq产品 （Notify、metaq）进行整合，只维护核心功能，去除了所有其他运行时依赖， 保证核心功能最简化，在此基础上配合阿里上述其他开源产品实现不同场景下mq的架构， 目前主要多用于订单交易系统。 Kafka: Apache下的一个子项目

1. kafka概述 1.1 kafka简介 Apache Kafka 是一个快速、可扩展的、高吞吐的、可容错的分布式“发布-订阅”消息系统， 使用 Scala 与 Java 语言编写，能够将消息从一个端点传递到另一个端点，较之传统的消息中 间件(例如 ActiveMQ、RabbitMQ)，Kafka 具有高吞吐量、内置分区、支持消息副本和高容 错的特性，非常适合大规模消息处理应用程序。 Kafka 官网: http://kafka.apache.org/ Kafka主要设计目标如下： 以时间复杂度为O(1)的方式提供消息持久化能力，即使对TB级以上数据也能保证常数时间的访问性能。 高吞吐率。即使在非常廉价的商用机器上也能做到单机支持每秒100K条消息的传输。 支持Kafka Server间的消息分区，及分布式消费，同时保证每个partition内的消息顺序传输。 同时支持离线数据处理和实时数据处理。 支持在线水平扩展 Kafka通常用于两大类应用程序： 建立实时流数据管道，以可靠地在系统或应用程序之间获取数据 构建实时流应用程序，以转换或响应数据流 要了解Kafka如何执行这些操作，让我们从头开始深入研究Kafka的功能。 首先几个概念： Kafka在一个或多个可以跨越多个数据中心的服务器上作为集群运行。 Kafka集群将 记录 流存储在称为 主题的 类别中。 每个记录由一个键