個人博客請訪問 http://www.x0100.top
1 零拷貝
零拷貝(zero copy)技術，用於在數據讀寫中減少甚至完全避免不必要的CPU拷貝，減少內存帶寬的佔用，提高執行效率，零拷貝有幾種不同的實現原理，下面介紹常見開源項目中零拷貝實現
1.1 Kafka零拷貝
Kafka基於Linux 2.1內核提供，並在2.4 內核改進的的sendfile函數 + 硬件提供的DMA Gather Copy實現零拷貝，將文件通過socket傳送
函數通過一次系統調用完成了文件的傳送，減少了原來read/write方式的模式切換。同時減少了數據的copy, sendfile的詳細過程如下：
基本流程如下：
-
(1) 用戶進程發起sendfile系統調用
-
(2) 內核基於DMA Copy將文件數據從磁盤拷貝到內核緩衝區
-
(3) 內核將內核緩衝區中的文件描述信息(文件描述符，數據長度)拷貝到Socket緩衝區
-
(4) 內核基於Socket緩衝區中的文件描述信息和DMA硬件提供的Gather Copy功能將內核緩衝區數據複製到網卡
-
(5) 用戶進程sendfile系統調用完成並返回
相比傳統的I/O方式，sendfile + DMA Gather Copy方式實現的零拷貝，數據拷貝次數從4次降爲2次，系統調用從2次降爲1次，用戶進程上下文切換次數從4次變成2次DMA Copy，大大提高處理效率
Kafka底層基於java.nio包下的FileChannel的transferTo：
public abstract long transferTo(long position, long count, WritableByteChannel target)
transferTo將FileChannel關聯的文件發送到指定channel，當Comsumer消費數據，Kafka Server基於FileChannel將文件中的消息數據發送到SocketChannel
1.2 RocketMQ零拷貝
RocketMQ基於mmap + write的方式實現零拷貝：mmap() 可以將內核中緩衝區的地址與用戶空間的緩衝區進行映射，實現數據共享，省去了將數據從內核緩衝區拷貝到用戶緩衝區
tmp_buf = mmap(file, len);
write(socket, tmp_buf, len);
mmap + write 實現零拷貝的基本流程如下：
-
(1) 用戶進程向內核發起系統mmap調用
-
(2) 將用戶進程的內核空間的讀緩衝區與用戶空間的緩存區進行內存地址映射
-
(3) 內核基於DMA Copy將文件數據從磁盤複製到內核緩衝區
-
(4) 用戶進程mmap系統調用完成並返回
-
(5) 用戶進程向內核發起write系統調用
-
(6) 內核基於CPU Copy將數據從內核緩衝區拷貝到Socket緩衝區
-
(7) 內核基於DMA Copy將數據從Socket緩衝區拷貝到網卡
-
(8) 用戶進程write系統調用完成並返回
RocketMQ中消息基於mmap實現存儲和加載的邏輯寫在org.apache.rocketmq.store.MappedFile中，內部實現基於nio提供的java.nio.MappedByteBuffer，基於FileChannel的map方法得到mmap的緩衝區：
// 初始化
this.fileChannel = new RandomAccessFile(this.file, "rw").getChannel();
this.mappedByteBuffer = this.fileChannel.map(MapMode.READ_WRITE, 0, fileSize);
查詢CommitLog的消息時，基於mappedByteBuffer偏移量pos，數據大小size查詢：
public SelectMappedBufferResult selectMappedBuffer(int pos, int size) {
int readPosition = getReadPosition();
// ...各種安全校驗
// 返回mappedByteBuffer視圖
ByteBuffer byteBuffer = this.mappedByteBuffer.slice();
byteBuffer.position(pos);
ByteBuffer byteBufferNew = byteBuffer.slice();
byteBufferNew.limit(size);
return new SelectMappedBufferResult(this.fileFromOffset + pos, byteBufferNew, size, this);
}
tips: transientStorePoolEnable機制Java NIO mmap的部分內存並不是常駐內存，可以被置換到交換內存(虛擬內存)，RocketMQ爲了提高消息發送的性能，引入了內存鎖定機制，即將最近需要操作的CommitLog文件映射到內存，並提供內存鎖定功能，確保這些文件始終存在內存中，該機制的控制參數就是transientStorePoolEnable
因此，MappedFile數據保存CommitLog刷盤有2種方式：
-
1 開啓transientStorePoolEnable：寫入內存字節緩衝區(writeBuffer) -> 從內存字節緩衝區(writeBuffer)提交(commit)到文件通道(fileChannel) -> 文件通道(fileChannel) -> flush到磁盤
-
2 未開啓transientStorePoolEnable：寫入映射文件字節緩衝區(mappedByteBuffer) -> 映射文件字節緩衝區(mappedByteBuffer) -> flush到磁盤
RocketMQ 基於 mmap+write 實現零拷貝，適用於業務級消息這種小塊文件的數據持久化和傳輸 Kafka 基於 sendfile 這種零拷貝方式，適用於系統日誌消息這種高吞吐量的大塊文件的數據持久化和傳輸
tips: Kafka 的索引文件使用的是 mmap+write 方式，數據文件發送網絡使用的是 sendfile 方式
1.3 Netty零拷貝
Netty 的零拷貝分爲兩種：
-
1 基於操作系統實現的零拷貝，底層基於FileChannel的transferTo方法
-
2 基於Java 層操作優化，對數組緩存對象(ByteBuf )進行封裝優化，通過對ByteBuf數據建立數據視圖，支持ByteBuf 對象合併，切分，當底層僅保留一份數據存儲，減少不必要拷貝
2 多路複用
Netty中對Java NIO功能封裝優化之後，實現I/O多路複用代碼優雅了很多：
// 創建mainReactor
NioEventLoopGroup boosGroup = new NioEventLoopGroup();
// 創建工作線程組
NioEventLoopGroup workerGroup = new NioEventLoopGroup();
final ServerBootstrap serverBootstrap = new ServerBootstrap();
serverBootstrap
// 組裝NioEventLoopGroup
.group(boosGroup, workerGroup)
// 設置channel類型爲NIO類型
.channel(NioServerSocketChannel.class)
// 設置連接配置參數
.option(ChannelOption.SO_BACKLOG, 1024)
.childOption(ChannelOption.SO_KEEPALIVE, true)
.childOption(ChannelOption.TCP_NODELAY, true)
// 配置入站、出站事件handler
.childHandler(new ChannelInitializer<NioSocketChannel>() {
@Override
protected void initChannel(NioSocketChannel ch) {
// 配置入站、出站事件channel
ch.pipeline().addLast(...);
ch.pipeline().addLast(...);
}
});
// 綁定端口
int port = 8080;
serverBootstrap.bind(port).addListener(future -> {
if (future.isSuccess()) {
System.out.println(new Date() + ": 端口[" + port + "]綁定成功!");
} else {
System.err.println("端口[" + port + "]綁定失敗!");
}
});
3 頁緩存(PageCache)
頁緩存（PageCache)是操作系統對文件的緩存，用來減少對磁盤的 I/O 操作，以頁爲單位的，內容就是磁盤上的物理塊，頁緩存能幫助程序對文件進行順序讀寫的速度幾乎接近於內存的讀寫速度，主要原因就是由於OS使用PageCache機制對讀寫訪問操作進行了性能優化：
頁緩存讀取策略：當進程發起一個讀操作 （比如，進程發起一個 read() 系統調用），它首先會檢查需要的數據是否在頁緩存中：
-
如果在，則放棄訪問磁盤，而直接從頁緩存中讀取
-
如果不在，則內核調度塊 I/O 操作從磁盤去讀取數據，並讀入緊隨其後的少數幾個頁面（不少於一個頁面，通常是三個頁面），然後將數據放入頁緩存中
頁緩存寫策略：當進程發起write系統調用寫數據到文件中，先寫到頁緩存，然後方法返回。此時數據還沒有真正的保存到文件中去，Linux 僅僅將頁緩存中的這一頁數據標記爲“髒”，並且被加入到髒頁鏈表中
然後，由flusher 回寫線程週期性將髒頁鏈表中的頁寫到磁盤，讓磁盤中的數據和內存中保持一致，最後清理“髒”標識。在以下三種情況下，髒頁會被寫回磁盤:
-
空閒內存低於一個特定閾值
-
髒頁在內存中駐留超過一個特定的閾值時
-
當用戶進程調用 sync() 和 fsync() 系統調用時
RocketMQ中，ConsumeQueue邏輯消費隊列存儲的數據較少，並且是順序讀取，在page cache機制的預讀取作用下，Consume Queue文件的讀性能幾乎接近讀內存，即使在有消息堆積情況下也不會影響性能，提供了2種消息刷盤策略：
-
同步刷盤：在消息真正持久化至磁盤後RocketMQ的Broker端纔會真正返回給Producer端一個成功的ACK響應
-
異步刷盤，能充分利用操作系統的PageCache的優勢，只要消息寫入PageCache即可將成功的ACK返回給Producer端。消息刷盤採用後臺異步線程提交的方式進行，降低了讀寫延遲，提高了MQ的性能和吞吐量
Kafka實現消息高性能讀寫也利用了頁緩存，這裏不再展開