消息队列

浅谈js运行机制(线程） 1.前言 从开始接触js时，我们便知道js是单线程的。单线程，异步，同步，互调，阻塞等。在实际写js的时候，我们都会用到ajax,不管是原生的实现，还是借助jQuery等工具库实现，我们都知道，ajax可以实现局部刷新，并且在请求处理时，任然可以响应用户的操作，比如点击事件。不是说js是单线程吗?这些都是怎么实现的？ 在阅读《深入理解Bootrap的源码》一书，在分析轮播组件(carousel.js)的源码时，作者对一句代码操作的注释引起了我的兴趣。 setTimeout(function(){ that.$element.trigger('slid'); },0);//触发slid事件,这里使用setTimeout是为了确保UI刷新线程不被阻塞。 1 2 3 4 后面我会一一解答这些疑惑。 2.浏览器线程 js运作在浏览器中,是单线程的，即js代码始终在一个线程上执行，这个线程称为js引擎线程。 浏览器是多线程的，除了js引擎线程，它还有： UI渲染线程 浏览器事件触发线程 http请求线程 EventLoop轮询的处理线程 …….. 这些线程的作用： UI线程用于渲染页面 js线程用于执行js任务 浏览器事件触发线程用于控制交互，响应用户 http线程用于处理请求，ajax是委托给浏览器新开一个http线程 EventLoop处理线程用于轮询消息队列

分布式消息服务DMS 是完全托管的高性能消息队列服务，提供普通队列、有序队列、Kafka、ActiveMQ、RabbitMQ，兼容HTTP、TCP、AMQP协议，为分布式应用提供灵活可靠的异步通信机制。使用DMS，用户可以创建消息队列，将消息队列作为一个传输消息的中转站，存储应用程序不同组件间传递的消息，从而做到在应用程序的不同组件之间传输消息时，不要求各个组件同时处于可用状态。 作为分布式系统中重要的组件，消息队列主要解决应用耦合，异步消息，流量削锋等问题，实现高性能，高可用，可伸缩和最终一致性架构。那么，在实际应用中，分布式消息服务常用的使用场景有哪些呢？让我们一起来看一下。 1、分布式系统异步通信 在单体应用中，业务流程耦合导致系统对用户请求响应慢，可以通过将拆分子系统，并用消息队列作为子系统间的异步通信通道进行系统解耦，提升整个系统的响应速度。 优势： 加快系统响应：系统分布式解耦，并行处理，加快系统对用户请求的响应速度。 降低系统耦合：子系统间通过消息队列通信，避免相互耦合和影响。 数据缓存：消息队列提供亿级消息堆积能力，帮助系统在峰值情况下从容应对。 2、物联网 物联网设备通过接入网关连接云端，DMS消息队列可以提供高速的数据传输通道，连接后端的数据分析系统。 优势： 高并发：单队列最高至10万TPS，并可通过队列数扩展提升整系统并发能力 灵活扩展

1、下载安装ActiveMQ 　　ActiveMQ官网下载地址： http://activemq.apache.org/download.html 　　ActiveMQ 提供了Windows 和Linux、Unix 等几个版本，楼主这里选择了Linux 版本下进行开发。 　　下载完安装包，解压之后的目录： 　 　　从它的目录来说，还是很简单的： bin存放的是脚本文件 conf存放的是基本配置文件 data存放的是日志文件 docs存放的是说明文档 examples存放的是简单的实例 lib存放的是activemq所需jar包 webapps用于存放项目的目录 2、启动ActiveMQ　 　　进入到ActiveMQ 安装目录的Bin 目录，linux 下输入 ./activemq start 启动activeMQ 服务。 　　 输入命令之后，会提示我们创建了一个进程IP 号，这时候说明服务已经成功启动了。 　　 　　ActiveMQ默认启动时，启动了内置的jetty服务器，提供一个用于监控ActiveMQ的admin应用。 　　admin： http://127.0.0.1:8161/admin/ 　　我们在浏览器打开链接之后输入账号密码（这里和tomcat 服务器类似） 　　默认账号：admin 　　密码：admin 　　 　　　到这里为止，ActiveMQ 服务端就启动完毕了。

马蜂窝技术原创文章，更多干货请订阅公众号：mfwtech Kafka 是当下热门的消息队列中间件，它可以实时地处理海量数据，具备高吞吐、低延时等特性及可靠的消息异步传递机制，可以很好地解决不同系统间数据的交流和传递问题。 Kafka 在马蜂窝也有非常广泛的应用，为很多核心的业务提供支撑。本文将围绕 Kafka 在马蜂窝大数据平台的应用实践，介绍相关业务场景、在 Kafka 应用的不同阶段我们遇到了哪些问题以及如何解决、之后还有哪些计划等。 Part.1 应用场景 从 Kafka 在大数据平台的应用场景来看，主要分为以下三类： 第一类是将 Kafka 作为数据库 ，提供大数据平台对实时数据的存储服务。从来源和用途两个维度来说，可以将实时数据分为业务端 DB 数据、监控类型日志、基于埋点的客户端日志 (H5、WEB、APP、小程序) 和服务端日志。 第二类是为数据分析提供数据源 ，各埋点日志会作为数据源，支持并对接公司离线数据、实时数据仓库及分析系统，包括多维查询、实时 Druid OLAP、日志明细等。 第三类是为业务方提供数据订阅 。除了在大数据平台内部的应用之外，我们还使用 Kafka 为推荐搜索、大交通、酒店、内容中心等核心业务提供数据订阅服务，如用户实时特征计算、用户实时画像训练及实时推荐、反作弊、业务监控报警等。 主要应用如下图所示： Part.2 演进之路 四个阶段

在 zeromq源码分析笔记之架构 说到了zmq的整体架构，可以看到线程间通信包括两类，一类是用于收发命令，告知对象该调用什么方法去做什么事情，命令的结构由 command_t结构体确定 ；另一类是socket_base_t实例与session的消息通信，消息的结构由 msg_t确定。命令的发送与存储是通过mailbox_t实现的，消息的发送和存储是通过pipe_t实现的，这两个结构都会详细说到，今天先说一下线程间的收发命令。 zeromq的线程可分为两类，一类是io线程，像reaper_t、io_thread_t都属于这一类，这类线程的特点就是内含一个轮询器poller及mailbox_t， 通过 poller 可以 监听激活 mailbox_t的 信号 ；另一类是zmq的socket,所有socket_base_t实例化的对象都可以看做一个单独的线程，这类线程不含poller，但同样含有一个mailbox_t，可以用于收发命令，由于不含poller，只能在每次使用socket_base_t实例的时候先处理一下mailbox_t，看是否有命令需要处理，代码上来看就是每次先调用下面这个函数接收并处理一下命令： int zmq::socket_base_t::process_commands (int timeout_, bool throttle_) 另外

rabbitmq消息队列的学习 1.优点：能够保证消息数据持久化，不丢失 安装rabbitmq 1.安装erlang $ yum -y install erlang2.安装RabbitMQ $ yum -y install rabbitmq-server3.启动(无用户名密码): systemctl start rabbitmq-server 查看是否启动： netstat -tunlp 0 0.0.0.0:4369 0.0.0.0:* LISTEN 3134/epmd 4.开启rabbitmq的web控制台 #开启web界面rabbitmqrabbitmq-plugins enable rabbitmq_management浏览器访问： http://192.168.91.128:15672/ 5.重启rabbitmq systemctl restart rabbitmq-server 6.创建rabbitmq用户 # 设置新用户kevins 密码123sudo rabbitmqctl add_user kevins 123 7. 设置用户为admin角色sudo rabbitmqctl set_user_tags kevins administrator 8.允许kevins用户对所有的队列进行读写 sudo rabbitmqctl set_permissions -p "/"

一、相关参数配置 ############################ System ############################# #唯一标识在集群中的ID，要求是正数。 broker.id=0 #服务端口，默认9092 port=9092 #监听地址，不设为所有地址 host.name=debugo01 # 处理网络请求的最大线程数 num.network.threads=2 # 处理磁盘I/O的线程数 num.io.threads=8 # 一些后台线程数 background.threads = 4 # 等待IO线程处理的请求队列最大数 queued.max.requests = 500 # socket的发送缓冲区（SO_SNDBUF） socket.send.buffer.bytes=1048576 # socket的接收缓冲区 (SO_RCVBUF) socket.receive.buffer.bytes=1048576 # socket请求的最大字节数。为了防止内存溢出，message.max.bytes必然要小于 socket.request.max.bytes = 104857600 ############################# Topic ############################# # 每个topic的分区个数

本文围绕如下几点进行阐述: 为什么使用消息队列？ 使用消息队列有什么缺点? 消息队列如何选型? 如何保证消息队列是高可用的？ 如何保证消息不被重复消费? 如何保证消费的可靠性传输? 如何保证消息的顺序性？ 1. 为什么使用消息队列？ 解耦，异步，限流 1.1 解耦 1.1.1 传统模式 传统模式的缺点： 系统间耦合性太强，如上图所示，系统A在代码中直接调用系统B和系统C的代码，如果将来D系统接入，系统A还需要修改代码，增加维护难度 1.1.2 中间件模式 中间件模式的的优点： 将消息写入消息队列，需要消息的系统自己从消息队列中订阅，从而系统A不需要做任何修改。 1.2 异步 1.2.1 传统模式 传统模式的缺点： 一些非必要的业务逻辑以同步的方式运行，太耗费时间。 1.2.2 MQ中间件模式 中间件模式的的优点： 将消息写入消息队列，非必要的业务逻辑以异步的方式运行，加快响应速度 1.3 限流 1.3.1 传统模式 传统模式的缺点： 并发量大的时候，所有的请求直接怼到数据库，造成数据库连接异常 1.3.2 中间件模式 中间件模式的的优点： 系统A慢慢的按照数据库能处理的并发量，从消息队列中慢慢拉取消息。在生产中，这个短暂的高峰期积压是允许的。 2. 使用消息队列有什么缺点? 导致系统可用性降低，若MQ发生故障会影响系统可用性。系统复杂性增加，引入MQ会引入新的关注点

一、消息传递模型 传统的消息队列最少提供两种消息模型，一种P2P，一种PUB/SUB，而Kafka并没有这么做，巧妙的，它提供了一个消费者组的概念，一个消息可以被多个消费者组消费，但是只能被一个消费者组里的一个消费者消费，这样当只有一个消费者组时就等同与P2P模型，当存在多个消费者组时就是PUB/SUB模型。 Kafka 的 consumer 是以pull的形式获取消息数据的。 pruducer push消息到kafka cluster ，consumer从集群中pull消息，如下图。该博客主要讲解. Parts在消费者中的分配、以及相关的消费者顺序、底层结构元数据信息、Kafka数据读取和存储等。 二、消息持久化 很多系统、组件为了提升效率一般恨不得把所有数据都扔到内存里，然后定期flush到磁盘上；可实际上，现代操作系统也是这样，所有的现代操作系统都乐于将空闲内存转作磁盘缓存（页面缓存），想不用都难；对于这样的系统，他的数据在内存中保存了一份，同时也在OS的页面缓存中保存了一份，这样不但多了一个步骤还让内存的使用率下降了一半；因此，Kafka决定直接使用页面缓存；但是随机写入的效率很慢，为了维护彼此的关系顺序还需要额外的操作和存储，而线性的写入可以避免这些，实际上，线性写入（linear write）的速度大约是300MB/秒，但随即写入却只有50k/秒

kafka是使用Java和Scala编写的一个快速可扩展的高吞吐量的分布式消息队列系统。 kafka将数据持久化存储到磁盘上，自带分区和副本机制，因而具有较好的持久化保证。 但是kafka的消息消费没有确认机制，可能因为consumer崩溃导致消息没有完成处理。因此不建议将kafka用于一致性较高的业务场景，kafka经常被用做日志收集和数据仓库之间的缓存。 比如将网站的浏览日志缓存到kafka，然后从kafka中取出批量写入ElasticSearch, Hive或者HBase等数据仓库中。这样做可以极大的减轻离线分析系统的负载。 架构简介 kafka架构中有下列角色参与： broker: kafka 集群中的服务器实例称为broker producer: 向broker发送消息的客户端 consumer: 向从borker中读取消息的客户端 zookeeper: 存储集群状态的注册中心，不处理具体消息。在负载均衡和集群扩展等功能中有重要作用。 接下来介绍kafka的逻辑模型: message: 消息是kafka通信的基本单元 topic: topic 在逻辑结构上类似于队列, 每条消息都属于一个 topic。 consumer group: 每个group中可以包含若干 consumer 实例，每个topic可以被多个consumer group 订阅。 消费者组拥有唯一的