科技新闻

拉模式： 点对点消费，如果没有消费者在监听队列，消息将保留在队列中，直至消费者连接到队列，在这种模型中，消息不是自动推动给消费者的，而是要由消费者从队列中请求活动（拉模式）。 优点： 1.保证每条消息都被接收。 2.消息不会丢失。 推模式 消息会自动广播，消息消费者无需主动请求或轮询主题的方法来获得新消息。 对比： 1.不保证每条消息都会被消费， 2.发布消息时，只有正在监听该topic的能够接收，如果没人监听，则会消息丢失。 MetaQ Client 订阅消息，因其是Pull的模型。MetaQ Server收到Pull消息的请求，会从磁盘上读取出消息，然后返回给MetaQ Client。这一步有大量的read系统调用。 消息中间件MetaQ高性能原因分析-转自阿里中间件 https://www.cnblogs.com/felixzh/p/6197707.html 来源： oschina 链接： https://my.oschina.net/u/3421984/blog/1633582

我们有世界上最牛的交易场景，但还缺少最牛的你！ 招聘岗位： 资深Java开发工程师、技术专家 岗位描述: 中间件技术部是阿里巴巴集团生态系统的技术基石，为淘宝、天猫、聚划算、1688、B2B、AE、淘宝旅行、淘宝海外、零售O2O等业务群提供可靠、高效、易扩展的技术基础服务 这里有世界一流的中间件产品和场景，包括应用托管容器、分布式调用服务、分布式消息服务、分布式数据服务和大数据计算平台等，掌控着超千亿规模的消息推送和分布式数据库调用，是全球流量最大的中间件集群之一 这里有世界最大的电商交易业务场景，团队提供的高可用架构基础设施直面双11洪峰流量，包括容量规划、准入控制、限流降级、流量调度、弹性伸缩和全链路压测等，体系化支撑阿里巴巴电商链路的稳定运行 这里有世界领先的企业互联网架构平台，以中间件技术部多款核心产品作为基础设施构建的云计算解决方案，面对互联网+的浪潮，帮助企业级客户轻松构建并托管分布式应用，解决集中化和互联网化的业务需求 我们的使命：做分布式架构基础设施，建设支撑百万笔交易的分布式架构能力，建设支撑百万台服务器和超万个系统的服务能力 我们的愿景：打造世界一流的中间件产品，打造世界一流的高可用架构基础设施，打造世界一流的企业级互联网架构平台 全面参与阿里巴巴集团中间件（容器，服务框架、消息中间件、数据中间件等）的设计，核心代码开发，系统稳定性开发，性能优化等工作

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

  回忆一下,在上一篇文章中,我们使用了分布式配置中心config来管理所有微服务的配置文件,那这样有没有什么问题?有,那就是无法配置文件无法自动更新,当我的git服务器上的配置文件更新后,不能同步更新到config-server,需要config-server重启才能生效,这在生产环境下,肯定是不可以的,我们需要当git服务器的文件更新后,自动同步到config-server,并且config-server不需要重启就能获取到最新的配置,因此我们需要借助spring cloud bus消息总线来实现该功能.其实spring cloud bus 本质上是利用MQ(消息中间件,常用的是RabbitMQ或者kafka)实现消息的推送功能. spring cloud bus的使用   上面我们说到spring cloud bus需要借助MQ,本文中我们借助RabbitMQ来实现该功能.首先需要我们在本机安装好RabbitMQ(安装过程就不再说了,大家发挥各自的聪明才智吧~),然后启动RabbitMQ:   以上打印信息说明已经启动好了,让我们登录网页版的控制台看一下,rabbitMQ控制台默认端口号15672:   出现该页面说明rabbitMQ已经成功启动了,大家可以用默认的账号密码guest/guest登录进去看一下:   然后我们将[dhp-micro-service-config

文章目录 消息100%的投递 方案1一 消息落库，对消息状态进行打标 方案二 消息的延迟投递，做二次确认，回调检查 幂等性概念 Confirm确认消息 Return返回消息 自定义消费者 消息100%的投递 消息如何保障100%的投递成功？ 什么是生产端的可靠性投递？ 保障消息的成功发出 保障MQ节点的成功接收 发送端收到MQ节点（Broker）确认应答 完善的消息进行补偿机制 BAT/TMD互联网大厂的解决方案： 消息落库，对消息状态进行打标 消息的延迟投递，做二次确认，回调检查 方案1一 消息落库，对消息状态进行打标 流程如下： 第1步：将订单入库，创建一条MSG(状态为0) 入MSG DB库 第2步：将消息发出去 第3步：监听消息应答(来自Broker) 第4步：修改消息的状态为1(成功) 第5步：分布式定时任务抓取状态为0的消息 第6步：将状态为0的消息重发 第7步：如果尝试了3次(可按实际情况修改)以上则将状态置为2(消息投递失败状态) 方案二 消息的延迟投递，做二次确认，回调检查 第1步：首先业务数据落库，成功才后第一次消息发送 第2步：紧着着发送第2条消息（可以用于寻找第1条消息），用于延迟(可能2,3分钟后才发送)消息投递检查 第3步：Broker端收到消息后，消费端进行消息处理 第4步：处理成功后，发送confirm消息 第5步：收到confirm消息后

RPC 即远程过程调用（Remote Procedure Call Protocol，简称RPC），像调用本地服务(方法)一样调用服务器的服务(方法)。通常的实现有 XML-RPC , JSON-RPC , 通信方式基本相同, 所不同的只是传输数据的格式. RPC是分布式架构的核心，按响应方式分如下两种： 同步调用：客户端调用服务方方法，等待直到服务方返回结果或者超时，再继续自己的操作 异步调用：客户端把消息发送给中间件，不再等待服务端返回，直接继续自己的操作。 同步调用的实现方式有WebService和RMI。Web Service提供的服务是基于web容器的，底层使用http协议，因而适合不同语言异构系统间的调用。RMI实际上是Java语言的RPC实现，允许方法返回 Java 对象以及基本数据类型，适合用于JAVA语言构建的不同系统间的调用。 异步调用的JAVA实现版就是JMS(Java Message Service)，目前开源的的JMS中间件有Apache社区的ActiveMQ、Kafka消息中间件，另外有阿里的RocketMQ。 RPC架构里包含如下4个组件: 1、 客户端(Client)：服务调用方 2、 客户端存根(Client Stub)：存放服务端地址信息，将客户端的请求参数打包成网络消息，再通过网络发送给服务方 3、 服务端存根(Server Stub)

博文大纲： 一、Kafka概述 1）消息队列 2）为什么要使用消息队列？ 3）什么是Kafka？ 4）Kafka的特性 5）Kafka架构 6）Topic和Partition的区别 7）kafka流程图 8）Kafka的文件存储机制 9）数据的可靠性和持久性保证 10）leader选举 二、部署单机Kafka 1）部署Kafka 2）测试Kafka 三、部署Kafka群集 1）环境准备 2）部署zookeeper群集 3）部署Kafka群集 一、Kafka概述 1）消息队列 1）点对点模式 （一对一，消费者主动拉取数据，消息收到后消息清除） 点对点模型通常是一个基于拉取或者轮询的消息传送模型，这种模型从队列中请求信息，而不是将消息推送到客户端。这个模型的特点是发送到队列的消息被一个且只有一个接收者接收处理，即使有多个消息监听者也是如此； 2）发布/订阅模式 （一对多，数据生产后，推送给所有订阅者） 发布订阅模型则是一个基于推送的消息传送模型。发布订阅模型可以有多种不同的订阅者，临时订阅者只在主动监听主题时才接收消息，而持久订阅者则监听主题的所有消息，即使当前订阅者不可用，处于离线状态。 2）为什么要使用消息队列？ 1）解耦 允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。 2）冗余 消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险

一、 简介 设计很独特，它采用pull机制，而不是一般MQ的push模型 ； 大量利用了zookeeper做服务发现和offset存储 ；它来源于kafka（scala），但是有自己的特点： 事务、多种offset存储、高可用方案(HA)等。 MetaQ相对kafka特有功能： 文本协议设计，非常透明，支持类似memcached stats的协议来监控broker 纯Java实现，从通讯到存储，从client到server都是重新实现。 提供事务支持，包括本地事务和XA分布式事务 支持HA复制，包括异步复制和同步复制，保证消息的可靠性 支持异步发送消息 消费消息失败，支持本地恢复 多种offset存储支持，数据库、磁盘、zookeeper，可自定义实现 支持group commit，提升数据可靠性和吞吐量。 支持消息广播模式 一系列配套项目：python客户端、twitter storm的spout、tail4j等。 Meta适合的应用： 日志传输，高吞吐量的日志传输本来就是kafka的强项 消息广播功能，如广播缓存配置失效。 数据的顺序同步功能，如mysql binlog复制 分布式环境下（broker,producer,consumer都为集群）的消息路由，对顺序和可靠性有极高要求的场景。 作为一般MQ来使用的其他功能 二、术语 Message Producer ：生产者；

1、Internet 2、Intranet 3、万维网 注：万维网不等同于因特网，它只是因特网的一项服务。 4、TCP/IP 5、HTTP 注：HTTP是运行在应用层的一项服务。 注：服务器在没有用户请求的时候不能推送给用户消息； HTTP是无状态的连接，本次请求与上次的请求没有关系。 6、Web服务器 注：目前主流的Web服务器包括三类：Apache、Nginx、IIS（Microsoft）。 来源： oschina 链接： https://my.oschina.net/u/2312175/blog/648733

本文主要介绍 Parcelable 和 Serializable 的作用、效率、区别及选择。 1、作用 Serializable 的作用是为了保存对象的属性到本地文件、数据库、网络流、rmi以方 便数据传输，当然这种传输可以是程序内的也可以是两个程序间的。而Android的 Parcelable 的设计初衷是因为 Serializable 效率过慢，为了在程序内不同组件间以及 不同Android程序间(AIDL)高效的传输数据而设计，这些数据仅在内存中存在， Parcelable 是通过 IBinder 通信的消息的载体。 从上面的设计上我们就可以看出优劣了 2、效率及选择 Parcelable 的性能比 Serializable 好，在内存开销方面较小，所以在内存间数据传输 时推荐使用 Parcelable ，如 activity 间传输数据，而 Serializable 可将数据持久化方便 保存，所以在需要保存或网络传输数据时选择 Serializable ，因为android不同版本 Parcelable 可能不同，所以不推荐使用 Parcelable 进行数据持久化。 3、编程实现 对于 Serializable ，类只需要实现 Serializable 接口，并提供一个序列化版本 id(serialVersionUID) 即可。而 Parcelable 则需要实现