Kafka

一.kafka-manager简介 kafka-manager是目前最受欢迎的kafka集群管理工具，它最早由雅虎开源，功能非常齐全，展示的数据非常丰富。同时用户能够在界面上执行一些简单的集群管理操作。 不过雅虎已经将其更名为CMAK(Cluster Manager for Apache Kafka)。具体支持以下内容： 管理多个集群 轻松检查集群状态(主题，消费者，偏移，代理，副本分发，分区分发) 运行首选副本选举 使用选项生成分区分配以选择要使用的代理 运行分区重新分配(基于生成的分配) 使用可选主题配置创建主题(0.8.1.1具有与0.8.2+不同的配置) 删除主题(仅支持0.8.2+并记住在代理配置中设置delete.topic.enable = true) 主题列表现在指示标记为删除的主题(仅支持0.8.2+) 批量生成多个主题的分区分配，并可选择要使用的代理 批量运行重新分配多个主题的分区 将分区添加到现有主题 更新现有主题的配置 选择性为 broker level and topic level metrics 开放JMX polling 选择性过滤掉在zookeeper中没有ids|owners|offsets|directories的消费者 CMAK管理工具支持的范围 支持 Kafka 0.8以上版本 Java 11+ zookeeper必须是3.5+版本。

《小姐姐味道》是一个主观性和悲观性很强的公众号。吉祥物是佩奇，然鹅过着不如猪的生活。 本公众号关注的方向有两个。 一个是基础架构。 一个是Linux。 不知不觉写了上百篇文章，感觉被掏空了。总结性的文章果然也就是就那么点料。接下来，可能要写一些系列性的文章。冷门但很重要的那种。 还是先总结一下吧。 Linux 小姐姐比较自豪的就是linux玩的非常6。对了，为了体现自己的博学，还出了个系列。最爱的编辑器当然是vim，这篇文章很受欢迎，你也来看看吧。 Linux生产环境上，最常用的一套“vim“技巧 Java堆外内存排查小结 据说很多人拿来洗稿 Linux五件套↓ Linux之《荒岛余生》（一）准备篇 Linux之《荒岛余生》（二）CPU篇 Linux之《荒岛余生》（三）内存篇 Linux之《荒岛余生》（四）I/O篇 Linux之《荒岛余生》（五）网络篇 LWP进程资源耗尽，Resource temporarily unavailable 命令行版星球大战 # 挖坟会不会被打？ 在终端画画、炒股、玩游戏 与福报厂无因果 小姐姐还是一个阿里黑，甚至是无脑黑。看我的表演 ↓ 坑爹项目「spring-cloud-alibaba」，我们也来一个 阿里开源软件替换指南 当然，也会恬不知耻的继续使用福报厂的一些优秀项目（羞）。 由 Canal 组件分析集成中间件架构的一般过程 高屋建瓴

前不久，朋友的公司，出现了比较大的故障。故障引起的原因也比较好解释，因为使用了ActiveMQ的高可用级别(M-S架构，双写完成ACK），结果在高峰期间，造成了生产端消息拥堵，诸多请求无法落地，数据错乱。 背景 据他说，他们的应用，级别比电信应用还要高（牛皮一定要吹），所以消息系统要求一条消息都不能丢。他做到了，但是服务不能用了。 这个Case有何而来呢？据说是来自一次高管会议上，某位领导对其中的一个小问题情绪激动：他测试环境测试的某条数据，直接不见了，生产环境并未复现。矛头最终指向了消息系统，直接上升到断电后怎么办云云。 领导发威，事情要特事特办。架构组扯蛋似的熬夜讨论了改进的方案，从Kafka到RocketMQ，从落盘DB到升级到StoreHA方案，不亦乐乎。最终的讨论结果，就是采用极高可用的方式。领导的条件满足了，消息系统也是高可用的，但整个业务不是。最终的MQ吞吐量，连个DB都不如。 典型的枪杆子需求引起的优化故障。一定不少见。 思考 高可用是个伪命题，虽然有CAP等耳熟能详的理论支持，还是有很多人陷入了这个误区，包括技术决策人。架构作为全局把控人，能出现这样的错误，纯属低级。下面，是我自己对高可用的一点思考。 高可用不是组件高可用，是业务高可用 拿消息队列来说，并不是说保证消息队列的存活和消息的可靠，就完成了工作。还需要考虑生产端和消费端的拓扑和高可用。比如

基础 我之前也踩过一些坑， 参与的一个创业项目在初始阶段就采用了服务化的架构，但由于当时人力有限，团队技术积累不足，因此在实际项目开发过程中，发现无法驾驭如此复杂的架构，也出现了问题难以定位、系统整体性能下降等多方面的问题，甚至连系统宕机了都很难追查到根本原因，最后不得不把服务做整合，回归到简单的单体架构中。 所以我建议一般系统的演进过程应该遵循下面的思路： 最简单的系统设计满足业务需求和流量现状，选择最熟悉的技术体系。随着流量的增加和业务的变化，修正架构中存在问题的点，如单点问题，横向扩展问题，性能无法满足需求的组件。在这个过程中，选择社区成熟的、团队熟悉的组件帮助我们解决问题，在社区没有合适解决方案的前提下才会自己造轮子。当对架构的小修小补无法满足需求时，考虑重构、重写等大的调整方式以解决现有的问题。 以淘宝为例， 当时该业务从 0 到 1 的阶段是通过购买的方式快速搭建了系统。而后，随着流量的增长，淘宝做了一系列的技术改造来提升高并发处理能力，比如数据库存储引擎从MyISAM 迁移到 InnoDB，数据库做分库分表，增加缓存，启动中间件研发等。当这些都无法满足时就考虑对整体架构做大规模重构，比如说著名的“五彩石”项目让淘宝的架构从单体演进为服务化架构。正是通过逐步的技术演进，淘宝才进化出如今承担过亿QPS 的技术架构。 下面就为大家展示一份技术小册，需要的朋友点赞收藏

日志的处理机制 1 golang日志库可以考虑 tmlog https://github.com/heiyeluren/go-tmlog --黑夜路人@北京 2 老谢，你这个是异步库，一旦log gr 出问题不就坑爹了 可以考虑加上阻塞方式的，效率低点，但是安全 log库不必也没必要追求效率 --于雨@北京 3 行啊，回头再考虑实时写入临时日志 --黑夜路人 @北京 4 一般的逻辑处理，瓶颈不可能在log上，务求不丢不乱就行了 --于雨@北京 5 前阵子看过一篇文章，一个老外做的分析，系统性能消耗有不少的部分浪费在同步log上 --郭军@360 6 主要是磁盘io慢啊慢 --黑夜路人 @北京 9 确实，我们client的log都出于效率原因从同步实时改成异步分批写入了 --类库@上海-意励 8 log太多了吧，会对io造成压力 --kyle@成都-风际游戏 9 异步的本质都是为了不阻塞当前执行协程 --黑夜路人 @北京 10 瓶颈还真有可能在log上 --Xargin@北京-didi 11 可以开启raid卡wb，对比下，如果差异巨大，可能是log导致的 --谭俊青@途牛 12 去年写proxy 日志info级别性能下降蛮多的 还是要少打日志的。业务对性能要求不苛刻就无所谓了 --董泽润@北京-nice 13 不要用文本日志，改成二进制代号 --kingsword@广州-kg 14

实践目的 通过操作一个开源例子，学习大数据的架构 及基本的使用，各种概念。不涉及自编码与创新。 环境搭建 需要建立 hadoop,hbase ,spark 等大数据环境 在10.30.2.5上建立六个docker , 分别对应 s141~s146 分别用于装大数据环境，具体操作步骤 参考本人 hadoop-spark https://blog.csdn.net/dualvencsdn/article/details/112007643?spm=1001.2014.3001.5501 habase https://blog.csdn.net/dualvencsdn/article/details/112905925?spm=1001.2014.3001.5501 学会操作hbase https://blog.csdn.net/dualvencsdn/article/details/113309385?spm=1001.2014.3001.5501 flume初步学习与使用 https://blog.csdn.net/qq_1018944104/article/details/85462011 /usr/local/flume/do.sh kafka与zookeeper的使用与编程 https://blog.csdn.net/dualvencsdn/article/details

概述： flink kafka实时流计算时都是用默认的序列化和分区器，这篇文章主要介绍如何向Kafka发送消息，并自定义消息的key,value,自定义消息分区类，这里选择最新的Flink1.9.1进行讲解。 自定义序列化类KeyedSerializationSchema： 通常我们都是用默认的序列化类来发送一条消息，有时候我们需要执行发送消息的key,value值，或者解析消息体后，在消息的key或者value加一个固定的前缀，这时候我们就需要自定义他的序列化类，Flink提供了可自定的的序列化基类KeyedSerializationSchema，这里先看下他的源码，： package org .apache .flink .streaming .util .serialization ; import java .io .Serializable ; import org .apache .flink .annotation .PublicEvolving ; /** @deprecated */ @ Deprecated @PublicEvolving public interface KeyedSerializationSchema<T> extends Serializable { byte [] serializeKey ( T var1 ); byte []

Flink 在 Flink 中需要端到端精准一次处理的位置有三个： Source 端 ：数据从上一阶段进入到 Flink 时，需要保证消息精准一次消费。 Flink 内部端 ：这个我们已经了解，利用 Checkpoint 机制，把状态存盘，发生故障的时候可以恢复，保证内部的状态一致性。不了解的小伙伴可以看下我之前的文章： Flink可靠性的基石-checkpoint机制详细解析 Sink 端 ：将处理完的数据发送到下一阶段时，需要保证数据能够准确无误发送到下一阶段。 在 Flink 1.4 版本之前，精准一次处理只限于 Flink 应用内，也就是所有的 Operator 完全由 Flink 状态保存并管理的才能实现精确一次处理。但 Flink 处理完数据后大多需要将结果发送到外部系统，比如 Sink 到 Kafka 中，这个过程中 Flink 并不保证精准一次处理。 在 Flink 1.4 版本正式引入了一个里程碑式的功能：两阶段提交 Sink，即 TwoPhaseCommitSinkFunction 函数。该 SinkFunction 提取并封装 了两阶段提交协议 中的公共逻辑，自此 Flink 搭配特定 Source 和 Sink（如 Kafka 0.11 版） 实现精确一次处理语义 (英文简称：EOS，即 Exactly-Once Semantics)。

前言 在日常开发过程中使用kafka来实限流削峰作用但是往往kafka会存放多份副本来防止数据丢失，那你知道他的机制是什么样的吗？本篇文章就带给大家讲解下。 一、Kafka集群 Kafka 使用 Zookeeper 来维护集群成员 (brokers) 的信息。每个 broker 都有一个唯一标识 broker.id ，用于标识自己在集群中的身份，可以在配置文件 server.properties 中进行配置，或者由程序自动生成。下面是 Kafka brokers 集群自动创建的过程： 每一个 broker 启动的时候，它会在 Zookeeper 的 /brokers/ids 路径下创建一个 临时节点 ，并将自己的 broker.id 写入，从而将自身注册到集群； 当有多个 broker 时，所有 broker 会竞争性地在 Zookeeper 上创建 /controller 节点，由于 Zookeeper 上的节点不会重复，所以必然只会有一个 broker 创建成功，此时该 broker 称为 controller broker。它除了具备其他 broker 的功能外， 还负责管理主题分区及其副本的状态 。 当 broker 出现宕机或者主动退出从而导致其持有的 Zookeeper 会话超时时，会触发注册在 Zookeeper 上的 watcher 事件，此时 Kafka

众所周知，游戏行业在当今的互联网行业中算是一棵常青树。在疫情之前的2019年，中国游戏市场营收规模约2884.8亿元，同比增长17.1%。2020年因为疫情，游戏行业更是突飞猛进。玩游戏本就是中国网民最普遍的娱乐方式之一，疫情期间更甚。据不完全统计，截至2019年，中国移动游戏用户规模约6.6亿人，占中国总网民规模8.47亿的77.92%，可见游戏作为一种低门槛、低成本的娱乐手段，已成为大部分人生活中习以为常的一部分。 对于玩家而言，市面上的游戏数量多如牛毛，那么玩家如何能发现和认知到一款游戏，并且持续的玩下去恐怕是所有游戏厂商需要思考的问题。加之2018年游戏版号停发事件，游戏厂商更加珍惜每一个已获得版号的游戏产品，所以这也使得“深度打磨产品质量”和“提高运营精细程度”这两个游戏产业发展方向成为广大游戏厂商的发展思路，无论是新游戏还是老游戏都在努力落实这两点： 新游戏：面向玩家需要提供更充足的推广资源和更完整的游戏内容。 老游戏：通过用户行为分析，投入更多的精力和成本，制作更优质的版本内容。 这里我们重点来看新游戏。一家游戏企业辛辛苦苦研发三年，等着新游戏发售时一飞冲天。那么问题来了，新游戏如何被广大玩家看到？ 首先来看看游戏行业公司的分类： 游戏研发商：研发游戏的公司，生产和制作游戏内容。比如王者荣耀的所有英雄设计、游戏战斗场景、战斗逻辑等，全部由游戏研发公司提供。 游戏发行商