Kafka

环境篇：Kylin3.0.1集成CDH6.2.0 Kylin是什么? Apache Kylin™是一个开源的、分布式的分析型数据仓库，提供Hadoop/Spark 之上的 SQL 查询接口及多维分析（OLAP）能力以支持超大规模数据，最初由 eBay 开发并贡献至开源社区。它能在亚秒内查询巨大的表。 Apache Kylin™ 令使用者仅需三步，即可实现超大数据集上的亚秒级查询。 定义数据集上的一个星形或雪花形模型 在定义的数据表上构建cube 使用标准 SQL 通过 ODBC、JDBC 或 RESTFUL API 进行查询，仅需亚秒级响应时间即可获得查询结果 如果没有Kylin 大数据在数据积累后，需要计算，而数据越多，算力越差，内存需求也越高，询时间与数据量成线性增长，而这些对于Kylin影响不大，大数据中硬盘往往比内存要更便宜，Kylin通过与计算的形式，以空间换时间，亚秒级的响应让人们爱不释手。 注：所谓询时间与数据量成线性增长：假设查询 1 亿条记录耗时 1 分钟，那么查询 10 亿条记录就需 10分钟，100 亿条记录就至少需要 1 小时 40 分钟。 http://kylin.apache.org/cn/ 1 Kylin架构 Kylin 提供与多种数据可视化工具的整合能力，如 Tableau，PowerBI 等，令用户可以使用 BI 工具对 Hadoop 数据进行分析

本文源码： GitHub·点这里 || GitEE·点这里 一、异步处理 1、异步概念 异步处理不用阻塞当前线程来等待处理完成，而是允许后续操作，直至其它线程将处理完成，并回调通知此线程。 必须强调一个基础逻辑，异步是一种设计理念，异步操作不等于多线程，MQ中间件，或者消息广播，这些是可以实现异步处理的方式。 同步处理和异步处理相对，需要实时处理并响应，一旦超过时间会结束会话，在该过程中调用方一直在等待响应方处理完成并返回。同步类似电话沟通，需要实时对话，异步则类似短信交流，发送消息之后无需保持等待状态。 2、异步处理优点 虽然异步处理不能实时响应，但是处理复杂业务场景，多数情况都会使用异步处理。 异步可以解耦业务间的流程关联，降低耦合度； 降低接口响应时间，例如用户注册，异步生成相关信息表； 异步可以提高系统性能，提升吞吐量； 流量削峰即把请求先承接下来，然后在异步处理； 异步用在不同服务间，可以隔离服务，避免雪崩； 异步处理的实现方式有很多种，常见多线程，消息中间件，发布订阅的广播模式，其根据逻辑在于先把请求承接下来，放入容器中，在从容器中把请求取出，统一调度处理。 注意 ：一定要监控任务是否产生积压过度情况，任务如果积压到雪崩之势的地步，你会感觉每一片雪花都想勇闯天涯。 3、异步处理模式 异步流程处理的实现有好多方式，但是实际开发中常用的就那么几种，例如： 基于接口异步响应

截至 Laravel 7，共有 6 个可用的缓存驱动程序，其中 APC 是最佳实践，而文件驱动程序是唯一不需要额外设置的驱动程序。 我昨晚与一位朋友交谈，他提到他们使用 Redis 作为缓存驱动程序，这让我想到我还有一个仍然使用文件驱动程序的项目。 我想我可以使用一些内存驱动缓存，以获得更好的性能，但我真的不想在这个时候用 Redis。就在这时，一个解决方案让我眼前一亮，我知道但还没有真正使用过的东西。 tmpfs. $ mount -t tmpfs -o size=12m tmpfs storage/framework/cache 　　 它做了啥 (小朋友你是否有很多？) 图片由 Liam Briese 提供 tmpfs: 允许你将文件作为一个目录存储在 RAM (内存) 中。 在 Linux 服务器上，Laravel 目录中，运行上述操作将把 storage/framework/cache 映射到 RAM，这意味着你可以通过使用 RAM 而不是磁盘 IO 来享受缓存文件的延迟下降。 如果你在你的应用中大量使用缓存的话，使用此方法的代价非常小 你可以确保你的服务器在重新启动时切换到 RAM 存储，方法是将以下命令放入你的服务器的系统配置文件 /etc/fstab tmpfs storage/framework/cache tmpfs nodev,nosuid,noexec

Java注解提供了关于代码的一些信息，但并不直接作用于它所注解的代码内容。在这个教程当中，我们将学习Java的注解，如何定制注解，注解的使用以及如何通过反射解析注解。 Java1.5引入了注解，当前许多java框架中大量使用注解，如Hibernate、Jersey、Spring。注解作为程序的元数据嵌入到程序当中。注解可以被一些解析工具或者是编译工具进行解析。我们也可以声明注解在编译过程或执行时产生作用。 在使用注解之前，程序源数据只是通过java注释和javadoc，但是注解提供的功能要远远超过这些。注解不仅包含了元数据，它还可以作用于程序运行过程中、注解解释器可以通过注解决定程序的执行顺序。例如，在Jersey webservice 我们为方法添加URI字符串的形式的 PATH 注解，那么在程序运行过程中jerser解释程序将决定该方法去调用所给的URI。 创建Java自定义注解 创建自定义注解和创建一个接口相似，但是注解的interface关键字需要以@符号开头。我们可以为注解声明方法。我们先来看看注解的例子，然后我们将讨论他的一些特性。 package com.journaldev.annotations; import java.lang.annotation.Documented; import java.lang.annotation.ElementType;

在战“疫”期间，腾讯与广州市政府合作，在2天内上线了“穗康”小程序口罩预约功能，解决了购买口罩难的问题，上线首日访问量1.7亿，累计参与口罩预约人次1400万+。本文是腾讯云专家产品经理 汤文亮老师在「云加社区沙龙online」分享整理，为大家揭晓其前后端架构及产品设计。 点击视频，查看完整直播回放 一、口罩预约项目背景 穗康是广州市政府提供的一个战役小程序，于1月30号上线，最开始版本只有三个功能：个人健康上报、疫情线索上报以及医疗物资上报，后续我们快速迭代了包括口罩预约、在线问诊、健康码等等功能。 说起口罩预约的诞生背景，其实在春节假期前疫情爆发就已经初现端倪。在大年三十那天，我们团队开了电话会议，决定我们要通过互联网工具的方式帮助政府支持疫情的防控。 而小程序具有开发快，门槛低，用户易上手的特点，是最适合做这种工具的渠道。经过沟通后，广州市政府很快决定要做这样的官方战役小程序，并且在1月30号就上线了第1个版本。 广州市政府在全国首次提出用小程序来做口罩预约，这为我们带来了很大的挑战，除了时间紧迫以外，因为口罩的社会关注度非常高，民众的需求很大，对系统的稳定性要求也会很高。 其次，相对于之前第1版上线的三个功能而言，口罩预约功能的业务逻辑更加复杂。这个项目是由市政府去主导，腾讯负责产品研发，广药集团负责口罩物资的提供、调配、以及线上线下的业务运营。 在政府的指导和推进下

汽车产业互联网平台大搜车由姚军红创立于2012年12月，先后获得阿里巴巴集团、蚂蚁金服、晨兴资本、华平投资、春华资本等机构超过12亿美元融资。2017年12月，大搜车列入由硅谷全球数据研究机构PitchBook评选的“2017年全球新晋独角兽”名单。 目前，大搜车已经搭建起比较完整的汽车产业互联网协同生态。随着业务业务的快速发展，大搜车遇到了一系列的问题： 大量微服务系统，总数在2000以上，这些系统之间的异步通信全部都需要通过消息队列MQ，导致消息量大幅增加，日均消息TPS在6000以上，消息系统的稳定性成为云上业务稳定保障的重中之重。 由于有杭州和北京两大研发中心，客户在杭州和北京都部署了大量业务系统，多地域应用的消息同步需要有稳定可靠的机制。 物联网设备的管理和接入对消息系统提出了更高的要求。 大数据领域大量应用Kafka，需要更稳定可靠的商业版Kafka产品，减少运维工作量。 为了更好地支撑业务，大搜车利用云上MQTT+消息队列RocketMQ+全球消息路由+消息队列Kafka构建了完整的云上消息系统。 通过全球消息路由功能将杭州地域的消息同步到北京地域，做到业务分地区就近部署。 独立消息队列实例管理不同业务，可用性更高。 利用消息队列Kafka对接大数据生态，即开即用，快速扩容，可靠性更高。物联网设备通过MQTT进行接入，后台开发物联网设备管理平台，通过MQTT连接设备端

生产端核心参数 1. acks 参数说明：这是一个非常重要的参数，表示指定分区中成功写入消息的副本数量，这是Kafka生产端消息的持久性（durability）保证。只有当leader确认已成功写入消息的副本数后，才会给Producer发送响应，此时消息才可以认为“已提交”。该参数影响着消息的可靠性以及生产端的吞吐量，并且两者往往相向而驰，通常消息可靠性越高则生产端的吞吐量越低，反之亦然。acks有3个取值： acks = 0：表示生产端发送消息后立即返回，不等待broker端的响应结果。通常此时生产端吞吐量最高，消息发送的可靠性最低。 acks = 1: 表示leader副本成功写入就会响应Producer，而无需等待ISR（同步副本）集合中的其他副本写入成功。这种方案提供了适当的持久性，保证了一定的吞吐量。默认值即是1。 acks = all或-1: 表示不仅要等leader副本成功写入，还要求ISR中的其他副本成功写入，才会响应Producer。这种方案提供了最高的持久性，但也提供了最差的吞吐量。 调优建议：建议根据实际情况设置，如果要严格保证消息不丢失，请设置为all或-1；如果允许存在丢失，建议设置为1；一般不建议设为0，除非无所谓消息丢不丢失。 2. max.request.size 参数说明：这个参数比较重要，表示生产端能够发送的最大消息大小，默认值为1048576

一、Kafka概述 关于Kafka，我们在之前的文章里也介绍，简而言之Kafka是一个分布式消息引擎与流处理平台，经常用做企业的消息总线、实时数据管道，有时还可以当做存储系统来用。Kafka的设计遵循生产者消费者模式，其中生产者和消费者都属于客户端，服务端则是由多个broker实例组成，broker主要负责接收和处理来自客户端的请求，以及对消息进行持久化。基本架构如下： 二、broker端核心参数 1. broker.id 参数说明：broker的唯一标识id，默认值为-1，如果不指定Kafka会自动生成一个id。生产环境推荐设置从0开始，按1递增的数字，比如0,1,2,3...等。 2. log.dirs 参数说明：设置Kafka持久化消息的数据目录，如果不设置Kafka会将消息持久化到/tmp/kafka-logs，通常都需要我们手动设置。多个目录逗号分隔，也就是一个csv列表。 调优建议：这是必须要上线前规划好的，建议设置成挂载不同磁盘的多个数据目录。创建topic时分区会自动均匀的分布到不同目录里，磁盘的io请求与空间占用也会负载均衡。 3. zookeeper.connect 参数说明：指定Kafka依赖的ZK连接信息，这个参数同样是一个csv列表，比如：zk1:2181,zk2:2181,zk3:2181。因为Kafka依靠Zookeeper做分布式协调服务

要回答这个问题，首先要明确啥程度算“零编码”？ 以 Excel 为例，如果把写 Excel 公式（包括复杂一些的）看做零编码；而把写 Excel VBA 看做编码的话， 报表开发是可以零编码的！ 但是，这有个前提：在数据（集）准备好的情况下才可以零编码！ 为什么这么说？ 我们知道报表开发主要分两个阶段： 第一阶段是为报表准备数据，也就是把原始数据通过 SQL/ 存储过程加工成数据集； 第二阶段是使用已准备的数据编写表达式做报表呈现。在报表工具提供的 IDE 里可视化地画出报表样式，然后再填入一些把数据和单元格绑定的表达式就可以完成报表呈现了，虽然表达式可能比较复杂，但相对硬编码要简单得多（Excel 公式和 VBA 的关系）。所以说这个阶段是能做到“零编码”的。 那报表数据准备怎么办？ 很遗憾，这个阶段没法零编码，一直以来只能硬编码，想想我们报表里写的嵌套 SQL、存储过程、JAVA 程序就知道了。为什么报表工具发展这么多年报表呈现已经完全工具化而报表数据准备的手段还这样原始呢？因为这个阶段太复杂了，不仅涉及计算逻辑的算法实现，还涉及报表性能（要知道大部分报表性能问题都是数据准备阶段引起的）。 那报表数据准备是不是没办法了呢？ 虽然不能做到零编码，但可以朝着简单化的方向努力，将数据准备阶段也工具化，这样可以使用工具提供的便利来简化报表数据准备阶段的工作，从而进一步简化报表的开发。

Python实战社群 Java实战社群 长按识别下方二维码， 按需求添加 扫码关注添加客服 进Python社群▲ 扫码关注添加客服 进Java社群 ▲ 作者 | 悟空聊架构 来源 | 悟空聊架构（ID：PassJava666） 转载请联系授权（微信ID：PassJava） 本篇主要内容如下： 主要内容 前言 我们都在讨论分布式，特别是面试的时候，不管是招初级软件工程师还是高级，都会要求懂分布式，甚至要求用过。传得沸沸扬扬的分布式到底是什么东东，有什么优势？ 借用火影忍术 风遁 ·螺旋手里剑 看过 火影 的同学肯定知道 漩涡鸣人 的招牌忍术： 多重影分身之术 。 这个术有一个特别厉害的地方， 过程和心得 ：多个分身的感受和经历都是相通的。比如 A 分身去找卡卡西（鸣人的老师）请教问题，那么其他分身也会知道 A 分身问的什么问题。 漩涡鸣人 有另外一个超级厉害的忍术，需要由几个影分身完成： 风遁·螺旋手里剑。 这个忍术是靠三个鸣人一起协作完成的。 这两个忍术和分布式有什么关系？ 分布在不同地方的系统或服务，是彼此相互关联的。 分布式系统是分工合作的。 案例： 比如 Redis 的 哨兵机制 ，可以知道集群环境下哪台 Redis 节点挂了。 Kafka的 Leader 选举机制 ，如果某个节点挂了，会从 follower 中重新选举一个 leader 出来。（leader