Linux使用 -- 帮助命令
man
Executable programs or shell commands
System calls (functions provided by the kernel)
Library calls (functions within program libraries)
Special files (usually found in /dev)
File formats and conventions eg /etc/passwd
Games
Miscellaneous (including macro packages and conventions), e.g. man(7), groff(7)
System administration commands (usually only for root)
Kernel routines [Non standard]
123456$ ls /usr/bin/passwd /etc/passwd/etc/passwd /usr/bin/passwd$ man 1 passwd$ man 5 passwd$ man - ...
Kafka -- 调优
调优目标
主要目标:高吞吐量、低延时
吞吐量
即TPS,指的是Broker端进程或Client端应用程序每秒能处理的字节数或消息数
延时,可以有两种理解
从Producer发送消息到Broker持久化完成之间的时间间隔
端到端的延时,即从Producer发送消息到Consumer成功消费该消息的总时长
优化漏斗优化漏斗是调优过程中的分层漏斗,层级越靠上,调优的效果越明显
操作系统层
mount -o noatime
在挂载文件系统时禁用atime(Access Time)更新,记录的是文件最后被访问的时间
记录atime需要操作系统访问inode资源,禁用atime可以避免inode访问时间的写入操作
文件系统选择ext4、XFS、ZFS
将swappiness设置成一个很小的值(1~10,默认是60),防止Linux的OOM Killer开启随机杀掉进程
swappiness=0,并不会禁止对swap的使用,只是最大限度地降低使用swap的可能性
因为一旦设置为0,当物理内存耗尽时,操作系统会触发OOM Killer
OOM Killer会随机挑选一个进程然后kill掉,不会给出 ...
Kafka -- 监控
主机监控
主机监控:监控Kafka集群Broker所在的节点机器的性能
常见的主机监控指标
机器负载
CPU使用率
内存使用率,包括空闲内存和已使用内存
磁盘IO使用率,包括读使用率和写使用率
网络IO使用率
TCP连接数
打开文件数
inode使用情况
JVM监控
重点指标
Full GC发生频率和时长
活跃对象大小
应用线程总数
设置堆大小
经历一次Full GC后,堆上存活的活跃对象大小为S,可以安全地将老年代堆大小设置为1.5S或者2S
从0.9.0.0版本开始,社区将默认的GC收集器设置为G1,而G1的Full GC是由单线程执行的,速度非常慢
一旦发现Broker进程频繁Full GC,可以开启G1的**-XX:+PrintAdaptiveSizePolicy,获知引发Full GC的原因**
集群监控
查看Broker进程是否启动,端口是否建立
在容器化的Kafka环境,容器虽然启动成功,但由于网络配置有误,会出现进程已经启动但端口未成功监听的情形
查看Broker端关键日志
Broker端服务器日志server.log – 最重要
控制器日志controller.l ...
Kafka -- KafkaAdminClient
背景
命令行脚本只能运行在控制台上,在应用程序、运维框架或者监控平台中集成它们,会非常困难
很多命令行脚本都是通过连接ZK来提供服务的,这会存在潜在的问题,即绕过Kafka的安全设置
运行这些命令行脚本需要使用Kafka内部的类实现,也就是Kafka服务端的代码
社区是希望用户使用Kafka客户端代码,通过现有的请求机制来运维管理集群
基于上述原因,社区于0.11版本正式推出Java客户端版的KafkaAdminClient
功能
主题管理
主题的创建、删除、查询
权限管理
具体权限的配置和删除
配置参数管理
Kafka各种资源(Broker、主题、用户、Client-Id等)的参数设置、查询
副本日志管理
副本底层日志路径的变更和详情查询
分区管理
创建额外的主题分区
消息删除
删除指定位移之前的分区消息
Delegation Token管理
Delegation Token的创建、更新、过期、查询
消费者组管理
消费者组的查询、位移查询和删除
Preferred领导者选举
推选指定主题分区的Preferred Broker为领导者
工作原理
KafkaA ...
Kafka -- 常用脚本
脚本列表12345678connect-distributed kafka-consumer-perf-test kafka-reassign-partitions kafka-verifiable-producerconnect-standalone kafka-delegation-tokens kafka-replica-verification trogdorkafka-acls kafka-delete-records kafka-run-class zookeeper-security-migrationkafka-broker-api-versions kafka-dump-log kafka-server-start zookeeper-server-startkafka-configs ...
Kafka -- 重设消费者组位移
背景
Kafka和传统的消息引擎在设计上有很大的区别,Kafka消费者读取消息是可以重演的
像RabbitMQ和ActiveMQ等传统消息中间件,处理和响应消息的方式是破坏性
一旦消息被成功处理,就会从Broker上被删除
Kafka是基于日志结构(Log-based)的消息引擎
消费者在消费消息时,仅仅是从磁盘文件中读取数据而已,是只读操作,因为消费者不会删除消息数据
同时,由于位移数据是由消费者控制的,因此能够很容易地修改位移值,实现重复消费历史数据的功能
Kafka Or 传统消息中间件
传统消息中间件:消息处理逻辑非常复杂,处理代价高、又不关心消息之间的顺序
Kafka:需要较高的吞吐量、但每条消息的处理时间很短,又关心消息的顺序
重设位移策略
位移维度
直接把消费者的位移值重设成给定的位移值
时间维度
给定一个时间,让消费者把位移调整成大于该时间的最小位移
维度
策略
含义
位移维度
Earliest
把位移调整到当前最早位移处
Latest
把位移调整到当前最新位移处
Current
把位移调整到当前最新提交位移处
Specified-Of ...
Kafka -- 动态配置
背景
Kafka安装目录的config路径下,有server.properties文件
通常情况下,会指定server.properties来启动Broker
如果要设置Broker端的任何参数,必须要显式修改server.properties,然后重启Broker,让参数生效
但在生产环境,不能随意重启Broker,因此需要能够动态修改Broker端参数
社区于1.1.0正式引入了动态Broker参数
动态指的是修改参数后,无需重启Broker就能立即生效,而之前server.properties中配置的参数称为静态参数
并非所有Broker端参数都可以动态调整的,官方文档中有Dynamic Update Mode一列
read-only
与原来的参数行为一样,只有重启Broker,才能令修改生效
per-broker
动态参数,修改之后,只会在对应的Broker上生效
cluster-wide
动态参数,修改之后,会在整个集群范围内生效
使用场景
动态调整Broker端各种线程池大小,实时应对突发流量 – 比较常用
动态调整Broker端连接信息或安全配置信息
动态更新SSL ...
Java性能 -- 高性能SQL
慢SQL诱因
无索引、索引失效
锁等待
InnoDB支持行锁,MyISAM支持表锁
InnoDB支持行锁更适合高并发场景,但行锁有可能会升级为表锁
一种情况是在批量更新时
行锁是基于索引加的锁,如果在更新操作时,条件索引失效,那么行锁会升级为表锁
基于表锁的数据库操作,会导致SQL阻塞等待,影响执行速度
在写大于读的情况下,不建议使用MyISAM
行锁相对于表锁,虽然粒度更细,并发能力提升,但也带来了新的问题,那就是死锁
不恰当的SQL
SELECT *
SELECT COUNT(*)
大表中使用LIMIT M,N
对非索引字段进行排序
SQL诊断EXPLAIN
id:每个执行计划都有一个id,如果是一个联合查询,会有多个id
select_type
SIMPLE:普通查询,即没有联合查询、子查询
PRIMARY:主查询
UNION:UNION中后面的查询
SUBQUERY:子查询
table:当前执行计划查询的表,如果表有别名,则显示别名
partitions:分区表信息
type
从表中查询到行所执行的方式
由好到坏:_**system > const > eq_re ...
Kafka -- 主题管理
日常管理创建主题1$ kafka-topics --bootstrap-server localhost:9092 --create --topic t1 --partitions 1 --replication-factor 1
从Kafka 2.2版本开始,推荐使用--bootstrap-server代替--zookeeper(标记为已过期)
原因
使用--zookeeper会绕过Kafka的安全体系,不受认证体系的约束
使用--bootstrap-server与集群交互是未来的趋势
查询主题列表12345$ kafka-topics --bootstrap-server localhost:9092 --list__consumer_offsets_schemast1transaction
查询单个主题1234567$ kafka-topics --bootstrap-server localhost:9092 --describe --topic __consumer_offsetsTopic:__consumer_offsets PartitionCount:50 Replica ...
Java性能 -- 生产者消费者模式 + 装饰器模式
生产者消费者模式实现方式Object的wait/notify/notifyAll
基于Object的wait/notify/notifyAll与对象监视器(Monitor)实现线程间的等待和通知
这种方式实现的生产者消费者模式是基于内核实现的,可能会导致大量的上下文切换,性能不是最理想的
Lock中Condition的await/signal/signalAll
相对于Object的wait/notify/notifyAll,更推荐JUC包提供的Lock && Condition实现的生产者消费者模式
Lock && Condition实现的生产者消费者模式,是基于Java代码层实现的,在性能和扩展性方面更有优势
BlockingQueue
简单明了
限流算法漏桶算法通过限制容量池大小来控制流量,而令牌桶算法则通过限制发放令牌的速率来控制流量
漏桶算法
请求如果要进入业务层,就必须经过漏桶,而漏桶出口的请求速率是均衡的
如果漏桶已经满了,请求将会溢出,不会因为入口的请求量突然增加而导致系统 ...