Kafka

php的垃圾回收机制可以简单总结为 引用计数 写时复制 COW机制。 引用计数基本知识 官网的解答如下 每个php变量存在一个叫”zval”的变量容器中一个zval变量容器，除了包含变量的类型和值 ，还包括两个字节的额外信息 is_ref 和 refcount is_ref 是个bool值，用来标识这个变量是否是属于引用集合(reference set)。 通过这个字节，php引擎才能把普通变量和引用变量区分开来 refcount 用以表示指向这个zval变量容器的变量个数 PHP5 中的引用计数在PHP5中，zval 的内存是单独从堆（heap）中分配的（有少数例外情况），PHP 需要知道哪些 zval 是正在使用的，哪些是需要释放的。所以这就需要用到引用计数：zval 中 refcount__gc 的值用于保存 zval 本身被引用的次数，比如 b = 12语句中，12 被两个变量引用，所以它的引用计数就是 2。如果引用计数变成 0，就意味着这个变量已经没有用了，内存也就可以释放了。 如下: <?php //php zval变量容器 $a = 1 ; $b = 1 ; $c = & $a ; $d = $b ; $e = range ( 0 , 3 ); xdebug_debug_zval ( 'a' ); xdebug_debug_zval ( 'b' ); xdebug

摘要： 本文介绍高并发系统的度量指标，讲述高并发系统的设计思路，再梳理高并发的关键技术，最后结合作者的经验做一些延伸探讨。 当前，数字化在给企业带来业务创新，推动企业高速发展的同时，也给企业的IT软件系统带来了严峻的挑战。面对流量高峰，不同的企业是如何通过技术手段解决高并发难题的呢? 0、引言 软件系统有三个追求： 高性能、高并发、高可用 ，俗称三高。三者既有区别也有联系，门门道道很多，全面讨论需要三天三夜，本篇讨论高并发。 高并发（High Concurrency） 。并发是操作系统领域的一个概念，指的是一段时间内多任务流交替执行的现象，后来这个概念被泛化，高并发用来指大流量、高请求的业务情景，比如春运抢票，电商双十一，秒杀大促等场景。 很多程序员每天忙着搬砖，平时接触不到高并发，哪天受不了跑去面试，还常常会被面试官犀利的高并发问题直接KO，其实吧，高并发系统也不高深，我保证任何一个智商在线的看过这篇文章后，都能战胜恐惧，重拾生活的信心。 本文先介绍高并发系统的度量指标，然后讲述高并发系统的设计思路，再梳理高并发的关键技术，最后结合作者的经验做一些延伸探讨。 1、高并发的度量指标 既然是高并发系统，那并发一定要高，不然就名不副实。并发的指标一般有 QPS、TPS、IOPS ，这几个指标都是可归为 系统吞吐率 ，QPS越高系统能hold住的请求数越多，但光关注这几个指标不够

Kafka的配置详尽、复杂，想要进行全面的性能调优需要掌握大量信息，这里只记录一下我在日常工作使用中走过的坑和经验来对kafka集群进行优化常用的几点。 1.JVM的优化 java相关系统自然离不开JVM的优化。首先想到的肯定是Heap Size的调整。 vim bin/kafka-server-start.sh 调整KAFKA_HEAP_OPTS="-Xmx16G -Xms16G”的值 推荐配置：一般HEAP SIZE的大小不超过主机内存的50%。 2.网络和ios操作线程配置优化： # broker处理消息的最大线程数 num.network.threads=9 # broker处理磁盘IO的线程数 num.io.threads=16 推荐配置： num.network.threads主要处理网络io，读写缓冲区数据，基本没有io等待， 配置线程数量为cpu核数加1。 num.io.threads主要进行磁盘io操作，高峰期可能有些io等待，因此配置需要大些。 配置线程数量为cpu核数2倍，最大不超过3倍。 3.socket server可接受数据大小(防止OOM异常)： socket.request.max.bytes=2147483600 推荐配置： 根据自己业务数据包的大小适当调大。这里取值是int类型的，而受限于java int类型的取值范围又不能太大： java

如果要问最近几年，IT行业哪个技术方向最火？一定属于ABC，即AI + Big Data + Cloud，也就是人工智能、大数据和云计算。 这几年，随着互联网大潮走向低谷，同时传统企业纷纷进行数字化转型，基本各个公司都在考虑如何进一步挖掘数据价值，提高企业的运营效率。在这种趋势下，大数据技术越来越重要。所以，AI时代，还不了解大数据就真的OUT了！ 相比较AI和云计算，大数据的技术门槛更低一些，而且跟业务的相关性更大。我个人感觉再过几年，大数据技术将会像当前的分布式技术一样，变成一项基本的技能要求。 前几天，我在团队内进行了一次大数据的技术分享，重点是对大数据知识做一次扫盲，同时提供一份学习指南。这篇文章，我基于分享的内容再做一次系统性整理，希望对大数据方向感兴趣的同学有所帮助，内容分成以下5个部分： 1、大数据的发展历史 2、大数据的核心概念 3、大数据平台的通用架构和技术体系 4、大数据的通用处理流程 5、大数据下的数仓体系架构 01 大数据的发展历史 在解释「大数据」这个概念之前，先带大家了解下大数据将近30年的发展历史，共经历了5个阶段。那在每个阶段中，大数据的历史定位是怎样的？又遇到了哪些痛点呢？ 1.1 启蒙阶段：数据仓库的出现 20世纪90年代，商业智能（也就是我们熟悉的BI系统）诞生，它将企业已有的业务数据转化成为知识，帮助老板们进行经营决策。比如零售场景中

​导语 | 云原生场景，多语言、多种协议兼容，任意多的消息 Topic、任意多的消费者，性能的按需快速扩展成为消息队列基本的要求。本文是对腾讯TEG技术委员会专家工程师刘德志老师在云+社区沙龙 online 的分享整理，介绍基于 Apache Pulsar 的新一代存储计算分离设计的消息队列 TDMQ，希望与大家一同交流。 点击视频查看完整直播回放 一、金融级别云原生消息队列功能需求 1. 腾讯计费背景介绍 腾讯计费是孵化于支撑腾讯内部业务千亿级营收的互联网计费平台，其核心是帮助用户与产品，安全、便捷的完成支付和收款，在交易过程中帮助产品盈收实现最大化。 如果把腾讯比喻为一个饭店，腾讯计费就相当于门口柜台的收费平台，你在饭店的消费，可以用微信支付、银行卡、苹果支付、QQ钱包、充值卡抵扣券或其他方式支付。 这里包括了 ToC 场景，比如用户往自己的 QB 账户充值，或者在游戏终端购买道具、游戏币，比如王者荣耀购买英雄或者皮肤等。也包括 ToB 场景，比如广告主、网红主播、腾讯云客户的扣款收费，都是通过腾讯计费这套平台提供的服务。 平台承载了腾讯公司每天数亿收入的大盘，为 180+ 个国家（地区）、万亿业务代码、100W+ 计算商户提供服务，托管账户总量 300 多亿，是一个全方位一站式计费平台。 腾讯计费平台有四个版本，分别是基础版、企业版、海外版、行业版，为众多广告客户提供服务

为什么会有ZooKeeper 我们知道要写一个分布式应用是非常困难的，主要原因就是局部故障。一个消息通过网络在两个节点之间传递时，网络如果发生故障，发送方并不知道接收方是否接收到了这个消息。有可能是收到消息以后发生了网络故障，也有可能是没有收到消息，又或者可能接收方的进程死了。发送方唯一的确认方法就是再次连接发送消息，并向他进行询问。这就是局部故障：根本不知道操作是否失败。因此，大部分分布式应用需要一个主控、协调控制器来管理物理分布的子进程。所以大部分应用需要开发私有的协调程序，协调程序的反复编写浪费时间，这个时候就需要一个通用的、伸缩性好的协调器。就是因为这样的场景，ZooKeeper应运而生，ZooKeeper的设计目的，就是为了减轻分布式应用程序所承担的协调任务。 ZooKeeper常用的应用场景 01 / 分布式协调 分布式协调简单说就是有人对ZooKeeper中的数据做了监听，如果修改了ZooKeeper中被监听的数据，ZooKeeper反过来会告诉给发起监听的人数据的变更。比如在Kafka的设计中，Kafka的一个节点在ZooKeeper中创建了一个数据，Kafka的策略是谁创建了这个数据谁就是Kafka集群的主节点，其余的节点都会去监听这个数据。如果主节点宕机了，这ZooKeeper对应的数据就会发生变更，既而监听这个数据的其余节点就会感知到主节点宕机了

spring.kafka.bootstrap-servers=10.10.6.33:9092,10.10.6.34:9092,10.10.6.35:9092 spring.kafka.consumer.auto-commit-interval=5000 spring.kafka.consumer.auto-offset-reset=latest 默认的消费组ID spring.kafka.consumer.group-id=WeChatLogConsumerGroup 是否自动提交offset spring.kafka.consumer.enable-auto-commit=true Kafka提供的序列化和反序列化类 spring.kafka.consumer.key-deserializer=org.apache.kafka.common.serialization.StringDeserializer spring.kafka.consumer.value-deserializer=org.apache.kafka.common.serialization.StringDeserializer 消费端监听的topic不存在时，项目启动会报错(关掉) spring.kafka.listener.missing-topics-fatal=false spring.kafka

前言 我的个人背景非常简单，也可以说丝毫没有亮点。 学历普通，计算机专业二本毕业，毕业后出来就一直在一家小公司，岁月如梭细，算了下至今从事Java开发已经5年了，也crud了五年，每天就是抄代码，毫无新意，甚至一度的怀疑人生。 其实很久之前就已经对自己不满了，每次都在想鼓起勇气想去打破困境，去改变自己，然而因为游戏因为玩耍一次又一次的破功；直到这次疫情，强有力的给了我当头一棒。是的，我失业了。这时候才真正的体会到什么叫做人无远虑，必有近忧。 失业之后疯狂的去找面经，去海投简历（都是一些小的不能再小的公司有回复），去找老朋友，去找同学；但是在疫情这么严重的当下根本不会找到合适的工作的，我也又冷静下来了，准备好好的调整下心态，整理下自己； 在这期间也七七八八的接到一些电话面试；这时候给了我个 新的启示 ——可以去投一些小公司的简历，去面试扫盲，看看哪些东西不会，欠缺哪些知识，然后慢慢的做面试复盘。并且通过这些面试给自己查漏补缺； 也许我的运气没有坏到极限吧 ，在恶补了三个月知识之后，我朋友给我打来了电话，说是有个字节跳动事业部的内推； 幸运女神往往会眷顾努力的人，所以当好运降临到我头上，我并不诧异，目前拿到了字节跳动25K的offer，下文也不说废话，主要分享我这次“面试经历”和“这段时间的学习方法”，希望能帮助到你们。 字节一面 1、自我介绍； 2、介绍自己做的项目； 3

一、Kafka持久化概述 Kakfa 依赖文件系统来存储和缓存消息。对于硬盘的传统观念是硬盘总是很慢，基于文件系统的架构能否提供优异的性能？实际上硬盘的快慢完全取决于使用方式。同时 Kafka 基于 JVM 内存有以下缺点： 对象的内存开销非常高，通常是要存储的数据的两倍甚至更高 随着堆内数据的增加，GC的速度越来越慢 实际上磁盘线性写入的性能远远大于任意位置写的性能，线性读写由操作系统进行了大量优化（read-ahead、write-behind 等技术），甚至比随机的内存读写更快。所以与常见的数据缓存在内存中然后刷到硬盘的设计不同，Kafka 直接将数据写到了文件系统的日志中： 写操作：将数据顺序追加到文件中 读操作：从文件中读取 这样实现的好处： 读操作不会阻塞写操作和其他操作，数据大小不对性能产生影响 硬盘空间相对于内存空间容量限制更小 线性访问磁盘，速度快，可以保存更长的时间，更稳定。 二、Kafka的持久化原理解析 一个 Topic 被分成多 Partition，每个 Partition 在存储层面是一个 append-only 日志文件，属于一个 Partition 的消息都会被直接追加到日志文件的尾部，每条消息在文件中的位置称为 offset（偏移量）。 如下图所示，我们之前创建了mytopic1，具有三个分区。我们可以到对应的日志目录下进行查看。

一、软件下载和准备 1、Zookeeper & Kafka下载 Zookeeper 下载地址： http://www.apache.org/dyn/closer.cgi/zookeeper/ 或 http://distfiles.macports.org/zookeeper/zookeeper-3.4.6.tar.gz Kafka下载地址： http://kafka.apache.org/downloads 或 https://www.apache.org/dyn/closer.cgi?path=/kafka/2.5.0/kafka_2.12-2.5.0.tgz 二、安装软件 1、Zookeeper的单机&集群安装 $ tar -zxvf zookeeper-3.4.6.tar.gz # 设置环境变量 $ vim /root/.bash_profile export ZOOKEEPER_HOME=/data/app/zookeeper-3.4.6 PATH=$PATH:$JAVA_HOME/bin:$ZOOKEEPER_HOME/bin $ source /root/.bash_profile # 配置Zookeeper $ cd /data/app/zookeeper-3.4.6/conf $ mv zoo_sample.cfg zoo.cfg # 集群规划，Zookeeper