Kafka

Honghu的消息服务平台已经抛弃了之前的ActiveMQ，改用高吞吐量比较大的Kafka分布式消息中间件方案： kafka消息平台使用spring+kafka的集成方案，详情如下： 使用最高版本2.1.0.RELEASE集成jar包：spring-integration-kafka Zookeeper、Kafka分布式集群使用init.properties配置化方案。 Java代码 kafka . servers = 127.0 .0 .1 : 9092 kafka . topic = xxxooo 使用消息生产者spring-context-producer配置化方案。 Java代码 < ? xml version = "1.0" encoding = "UTF-8" ? > < beans xmlns = "http://www.springframework.org/schema/beans" xmlns : xsi = "http://www.w3.org/2001/XMLSchema-instance" xmlns : context = "http://www.springframework.org/schema/context" xsi : schemaLocation = "http : / / www . springframework . org /

集群搭建: [root@localhost kafka_2.11-0.10.2.1]# cat config/server.properties | grep -v ^$ | grep -v ^# broker.id=0 listeners=PLAINTEXT://node1:9092 num.network.threads=3 num.io.threads=8 socket.send.buffer.bytes=102400 socket.receive.buffer.bytes=102400 socket.request.max.bytes=104857600 log.dirs=/tmp/kafka-logs num.partitions=1 num.recovery.threads.per.data.dir=1 log.retention.hours=168 log.segment.bytes=1073741824 log.retention.check.interval.ms=300000 zookeeper.connect=node1:2181,node2:2181,node3:2181 zookeeper.connection.timeout.ms=6000 listeners=PLAINTEXT://node1:9092, 配置物理机器的hostname,

延迟任务 什么是延迟任务 需要延迟一段时间才需要处理的任务. 比如订单关闭, 电商平台一般会给用户30分钟左右交钱时间, 当超时未交钱就需要关闭订单. 订单的延时关闭就是一种延迟任务. 怎么实现延迟任务 定时任务 最普遍的做法应该就是定时任务了, 比如订单关闭例子, 我们会将订单存储在表中, 通过定时任务定时扫表, 比如10分钟一次, 对扫描结果进行时间处理, 如果是超时订单则执行关闭操作. 定时任务实现简单, 缺点是时间延迟时间不准确, 在订单例子中, 如果第一次扫描发现订单为29分钟未支付, 那么该订单只能在第二次扫描时执行关闭, 此时订单已经是39分钟未支付了. 为了提供时间准确性, 我们可以减少定时任务时间, 比如一分钟一次. 时间越短准确性越高, 但是资源消耗的也越多. RabbitMQ延迟队列 RabbitMQ本身没有延迟队列的概念, 但是它在处理死信时使用了类似的功能. 当队列中出现死信, 我们可以让它路由到指定的队列中, 然后再消费该队列消息, 达到延迟功能. 那么什么是死信 dead-lettered message? 官网解释在以下三种情况下message可以成为dead-lettered message 1 The message is negatively acknowledged by a consumer using basic.reject or

摘要： 在本篇文章中我们将对 RocksDB、Heap 和 Gemini 在相同场景下进行压测，并对其资源消耗进行对比。测试的 Flink 内核版本为 1.10.0。 微博机器学习平台使用 Flink 实现多流 join 来生成在线机器学习需要的样本。时间窗口内的数据会被缓存到 state 里，且 state 访问的延迟通常决定了作业的性能。开源 Flink 的状态存储主要包括 RocksDB 和 Heap 两种，而在去年的 Flink Forward 大会上我们了解到阿里云 VVP 产品自研了一款更高性能的状态存储插件 Gemini，并对其进行了测试和试用。 测试场景 我们使用真实的样本拼接业务作为测试场景，通过将多个流的数据 union后对指定key做聚合（keyby），在聚合函数里从各个流中获取相应的字段，并将需要的字段重新组合成一个新的对象存储到 value state 里。这里对每个新的对象都定义一个 timer，用 timer 功能来替代 TimeWindow，窗口结束时将数据发射到下游算子。使用 timer 功能的主要原因是 timer 更灵活，更方便用户自定义，在平台的实用性，可扩展性上表现更好。 MemoryStateBackend vs. RocksDBStateBackend 首先需要说明的是，MemoryStateBackend 不建议在线上使用

1、背景 日志系统接入的日志种类多、格式复杂多样，主流的有以下几种日志： filebeat采集到的文本日志，格式多样 winbeat采集到的操作系统日志 设备上报到logstash的syslog日志 接入到kafka的业务日志 以上通过各种渠道接入的日志，存在2个主要的问题： 格式不统一、不规范、标准化不够 如何从各类日志中提取出用户关心的指标，挖掘更多的业务价值 为了解决上面2个问题，我们基于flink和drools规则引擎做了实时的日志处理服务。 2、系统架构 架构比较简单，架构图如下： 各类日志都是通过kafka汇总，做日志中转。 flink消费kafka的数据，同时通过API调用拉取drools规则引擎，对日志做解析处理后，将解析后的数据存储到Elasticsearch中，用于日志的搜索和分析等业务。 为了监控日志解析的实时状态，flink会将日志处理的统计数据，如每分钟处理的日志量，每种日志从各个机器IP来的日志量写到Redis中，用于监控统计。 3、模块介绍 系统项目命名为eagle。 eagle-api：基于springboot，作为drools规则引擎的写入和读取API服务。 eagle-common：通用类模块。 eagle-log：基于flink的日志处理服务。 重点讲一下eagle-log： 对接kafka、ES和Redis 对接kafka和ES都比较简单

前言 消息队列在现今数据量大，并发量高的系统中是十分常用的。本文将会对现时最常用到的几款消息队列框架 ActiveMQ、RabbitMQ、Kafka 进行分析对比。 详细介绍 RabbitMQ 在 Spring 框架下的结构及实现原理，从Producer 端的事务、回调函数（ConfirmCallback / ReturnCallback）到 Consumer 端的 MessageListenerContainer 信息接收容器进行详细的分析。通过对 RabbitTemplate、SimpleMessageListenerContainer、DirectMessageListenerContainer 等常用类型介绍，深入剖析在消息处理各个传输环节中的原理及注意事项。 并举以实例对死信队列、持久化操作进行一一介绍。 目录 一、RabbitMQ 与 AMQP 的关系 二、RabbitMQ 的实现原理 三、RabbitMQ 应用实例 四、Producer 端的消息发送与监控 五、Consumer 端的消息接收与监控 六、死信队列 七、持久化操作 一、RabbitMQ 与 AMQP 的关系 1.1 AMQP简介 AMQP（Advanced Message Queue Protocol 高级消息队列协议）是一个消息队列协议，它支持符合条件的客户端和消息代理中间件（message

发布会传送门 点击了解产品详情 众所周知，注册中心和配置中心是Spring Cloud 和Dubbo 等微服务架构中的重要组件，往往采用 ZooKeeper/Nacos/Eureka/Apollo 等开源方案自建，但因其依赖复杂、变更频繁，往往给客户带来的较高的建设和运维成本，同时，在 Hbase、Spark或Kafka 等大数据的环境下，会依赖 ZooKeeper 进行分布式系统的协调，此时，基于云上的托管服务，可以极大的降低运维复杂度，并提高应用可用性。相比开源自建，微服务引擎MSE 通过提供的云上监控和运维能力、多机房和多区域容灾能力、自动宕机恢复能力，实现了99.9%的可用性保障，此外，MSE提供了多打25项的开源优化，提升了注册和配置中心的易用性和性能。3分钟便能完成接入，每月最低50.16元，更是从操作和价格上降低了企业的接入成本。 据微服务引擎MSE产品经理子墚介绍，“我们除了提供注册和配置中心的托管能力，还围绕困扰开发者微服务治理过程遇到的各类运维难题，提供了包括金丝雀发布、离群实例摘除、服务鉴权、无损下线、限流降级和全链路流控的高阶微服务治理能力，极大的降低了微服务的运维难度，其组件型的产品理念还帮助客户实现了云上应用的自主可控。“目前，已有包括陆德科技、吉递换电、趣练习、企迈云商等来自出行、物联网、在线教育、新零售等行业的客户正通过 MSE 来提升运维效率

无所不在的时序数据 时间带走一切，长年累月会把你的名字、外貌、性格、命运都改变。 ---柏拉图 随着时间的推移，万事万物都在不停的变化，而我们也会用各种数字去衡量这些变化信息，比如年龄、重量、速度、温度、金钱...在数字化时代中，我们会把这些随着时间变化的数据保存起来，挖掘这些数据的价值。通常我们会称这类数据为---时序数据。 时序数据用于描述物体在时间维度上的状态变化信息。 时序数据在各行各业都得到了非常广泛的应用，例如股票走势、交易趋势、服务器指标、脉搏心跳、定位坐标、能耗趋势等等，而这些数据几乎在所有的场景中都得到了应用，例如： 各类炒股软件提供众多不同维度的股票K线图，为广大股民提供参考标准； Apple Watch通过监控佩戴者的心率信息，帮助人们提早发现严重的心脏疾病； 国家电网通过分析各个小区、住户的用电量曲线，来判断是否有偷电漏电情况； 电商类的公司会监控平台的下单、交易、退货、评价等关键流程的变化趋势，用来快速发现各类异常； 各个游戏平台通过分析每个用户角色的操作、位置等变化规律，来判断是否使用了作弊辅助工具... 我们需要一个什么样的时序存储 为了能够支撑各种场景的时序分析、监控等需求，近几年在开源和商业领域均出现了一些时序存储的引擎，例如TimescaleDB、CrateDB、InfluxDB、OpenTSDB、Prometheus等

问题 如何保证消息队列的高可用？ 面试题剖析 如果有人问到你 MQ 的知识， 高可用是必问的 。这个问题这么问是很好的，因为不能问你 Kafka 的高可用性怎么保证？ActiveMQ 的高可用性怎么保证？一个面试官要是这么问就显得很没水平，人家可能用的就是 RabbitMQ，没用过 Kafka，你上来问人家 Kafka 干什么？这不是摆明了刁难人么。 所以有水平的面试官，问的是 MQ 的高可用性怎么保证？这样就是你用过哪个 MQ，你就说说你对那个 MQ 的高可用性的理解。 1. RabbitMQ 的高可用性 RabbitMQ 是比较有代表性的，因为是 基于主从 （非分布式）做高可用性的，我们就以 RabbitMQ 为例子讲解第一种 MQ 的高可用性怎么实现。 RabbitMQ 有三种模式：单机模式、普通集群模式、镜像集群模式。 单机模式 单机模式，就是 Demo 级别的，一般就是你本地启动了玩玩儿的，没人生产用单机模式。 普通集群模式（无高可用性） 普通集群模式，意思就是在多台机器上启动多个 RabbitMQ 实例，每个机器启动一个。你 创建的 queue，只会放在一个 RabbitMQ 实例上 ，但是每个实例都同步 queue 的元数据（元数据可以认为是 queue 的一些配置信息，通过元数据，可以找到 queue 所在实例）。你消费的时候，实际上如果连接到了另外一个实例

1. redis各种应⽤场景 2. redis持久化机制 3.有没了解Docker，Docker和虚拟机有什么区别？ 4.说说rabbitmq的结构。 四种交换机： 直连交换机，Direct exchange：带路由功能的交换机，根据routing_key（消息发送的时候需要指定）直接绑定到队列， ⼀个交换机也可以通过过个routing_key绑定多个队列。 扇形交换机，Fanout exchange：⼴播消息。 主题交换机，Topic exchange：发送到主题交换机上的消息需要携带指定规则的routing_key，主题交换机会根据这个规 则将数据发送到对应的(多个)队列上。 ⾸部交换机，Headers exchange：⾸部交换机是忽略routing_key的⼀种路由⽅式。路由器和交换机路由的规则是通过 Headers信息来交换的，这个有点像HTTP的Headers。 将⼀个交换机声明成⾸部交换机，绑定⼀个队列的时候，定义⼀ 个Hash的数据结构，消息发送的时候，会携带⼀组hash数据结构的信息，当Hash的内容匹配上的时候，消息就会被写⼊队 列。 5.项⽬中哪⾥⽤到了kafka，kafka特性？ 6. 介绍springcloud核⼼组件及其作⽤，以及springcloud⼯作流程。 7.介绍springcloud⼼跳机制，以及消费端如何发现服务端（Ribbon）？ 8