Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly
Sign up
Appearance settings

Commit 8b789e3

Browse files 
2 parents 70949c6 + 3a3ef45 commit 8b789e3

File tree

10 files changed

+1309
-0
lines changed

10 files changed

+1309
-0
lines changed

‎JDK/并发编程/Java线程池ThreadPoolExecutor.md

Lines changed: 1267 additions & 0 deletions
Large diffs are not rendered by default.

‎TODO/uml/Java总结知识点.pos

Lines changed: 1 addition & 0 deletions
Large diffs are not rendered by default.
Lines changed: 20 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,20 @@
1+
@startuml
2+
title: ReplicaManager#appendRecords
3+
4+
actor ReplicaManager as ReplicaManager
5+
6+
alt requiredAcks值合法
7+
ReplicaManager -> ReplicaManager : 写入消息集到本地日志
8+
ReplicaManager -> ReplicaManager : 构建写入结果状态
9+
alt 等待其他副本完成写入
10+
ReplicaManager -> ReplicaManager : 创建延时请求对象
11+
ReplicaManager -> ReplicaManager : 交由 Puratory 管理
12+
else
13+
ReplicaManager -> ReplicaManager : 调用回调逻辑
14+
end
15+
else requiredAcks值非法
16+
ReplicaManager -> ReplicaManager : 构造特定异常对象
17+
ReplicaManager -> ReplicaManager : 封装进回调函数执行
18+
end
19+
20+
@enduml

‎TODO/uml/mysql.xmind

314 KB
Binary file not shown.

‎TODO/uml/spring.xmind

254 KB
Binary file not shown.
33.3 KB
Loading[フレーム]
34.4 KB
Loading[フレーム]
30.8 KB
Loading[フレーム]
71.6 KB
Loading[フレーム]
Lines changed: 21 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,21 @@
1+
kafka高性能原理
2+
==============
3+
       最近翻了下kafka官方关于kafka设计的文档,面试上用,这里就总结下自己了解到的kafka设计上支持那么大吞吐量的原因
4+
消息传递及存储
5+
------------
6+
       从上层设计来说,kafka的生产者支持批量发送消息(可以设置发送的内容最大大小和最长等待时间)当这些批量的消息到达kafak的broker上后会通过硬盘的线性写操作将日志记录进硬盘,这种操作的速度是很快的(中间也涉及到操作系统的pagecache,kafka也可以设置这种缓存刷盘的频率比如:一秒刷一次,每条消息刷一次,按照操作系统的配置去刷),这个是说从生产者发送消息给broker很快,那么消费者消费速度呢?kafka在消费上使用pull的方式去主动向broker节点请求获取消息,而具体的offset是由消费者去指定的(这个offset其实broker上也有维护一份,但是我理解的是拉取offset的决定权是掌握在消费者手里的,只不过如果消费者挂了后,其他替代的消费者如何知道原来的offset呢,那就需要broker也存一份),Kafka底层是通过linux的sendfile函数直接将消息存储的消息内容转发到网络的socket buffer然后在copy到NIC buffer发送到网络上。这个用到的是零拷贝技术,而正常的情况是需要以下几步:
7+
8+
> 1,从硬盘读取到pagecache
9+
> 2,从pagecache读取到用户内存
10+
> 3,从用户内存读到socket buffer中
11+
> 4,从socket buffer读取到 NIC buffer中然后NIC自动硬件发送(这步是不需要耗费CPU时间的)
12+
>>kafka使用零拷贝总共节省了从pagecache拷贝到用户内存和从用户内存拷贝到socket buffer的两次拷贝,节省了拷贝过程中用户态和心态的切换,同时因为网卡,显卡,声卡等支持了DMA也就是直接访问主内存而不需要经过CPU,那么网卡可以直接访问硬盘的pagecache而不需要在经过pagechche到socket buffer的这一步拷贝真正实现了零拷贝。
13+
14+
15+
      而kafka消费方式是通过消费者拉取的方式而消费者可以根据自己的消费速度批量拉取消息,消息又都是顺序读,所以kafka在发送消息给消费者的时候速度也很快。同时,kafka也支持数据的压缩,这种压缩的数据在生产者,broker,消费者都是一致的可以直接传输。
16+
17+
集群
18+
---------------
19+
20+
       说到大吞吐量必须也得涉及到kafka集群,现将Kafka集群我认为的重点知识记录如下:
21+
       主要涉及两个方面吧,**一个是多boker节点,一个是主从复制**。Kafka使用多croker节点来进行负载均衡,而生产者按照topic发送消息到broker的规则可以选用轮询或者指定规则,消费者按照group进行消费,每个group中只会有一个消费者消费同一条消息,如果同一个group中有消费者挂了,那么这个消费者对应消费的broker也会分配到同一个group中的其他消费者上。但是如果broker挂了呢?这就需要用到kafka的主从节点设置了。其实broker的从节点数据同步方式跟普通的消费者没什么区别,而在同步数据的时候主节点会维护一套ISR节点群,在这个节点群的从节点,kafka认为他们的数据是比较完整的,如果主节点挂了之后,这些从节点的任意一台节点都可以替换主节点。那么怎么保证一个消息会被同步到从节点了呢,这个可以在生产者配置acks=0,1,-1来决定一条消息只有在收到多少个从节点的确认后才算真正的落地成功,当选择-1的时候那么在ISR集合中的所有节点都要收到这条消息并返回确认后,这条消息才算发送成功,这个时候延迟也会比较高,所以可以根据线上系统的特点来综合判断这个配置如何设置。

0 commit comments

Comments
(0)

AltStyle によって変換されたページ (->オリジナル) /