㈠ 計算機儲存單位有哪些儲存單位有多大
計算機存儲單位一般用B，KB，MB，GB，TB，PB，EB，ZB，YB，BB來表示,將來還會有更大的存儲單位。
它們之間的關系是：
位 bit (比特)(Binary Digits)：存放一位二進制數，即 0 或 1，最小的存儲單位。
位元組 byte：8個二進制位為一個位元組(B)，最常用的單位。
1KB (Kilobyte 千位元組)=1024B，
1MB (Megabyte 兆位元組 簡稱「兆」)=1024KB，
1GB (Gigabyte 吉位元組 又稱「千兆」)=1024MB，
1TB(Trillionbyte 萬億位元組 太位元組)=1024GB，其中1024=2^10 ( 2 的10次方)，
1PB（Petabyte 千萬億位元組 拍位元組）=1024TB，
1EB（Exabyte 百億億位元組 艾位元組）=1024PB，
1ZB (Zettabyte 十萬億億位元組 澤位元組)= 1024 EB,
1YB (Yottabyte 一億億億位元組 堯位元組)= 1024 ZB,
1BB (Brontobyte 一千億億億位元組)= 1024 YB.
註：「兆」為百萬級數量單位。
㈡ 有沒有人用sqlite作百萬級數據存儲的
SQLite是Android默認的數據存儲方式之一，也是Linux自帶的資料庫之一，很多開源項目或者商業項目都在使用。你是否使用該資料庫取決於你的用途，它是嵌入式的資料庫同時支持sql92標准，就是你可以用sql語句，而且文檔豐富，經過n多項目實際使用性...
㈢ 互聯網如何海量存儲數據
目前存儲海量數據的技術主要包括NoSQL、分布式文件系統、和傳統關系型資料庫。隨著互聯網行業不斷的發展，產生的數據量越來越多，並且這些數據的特點是半結構化和非結構化，數據很可能是不精確的，易變的。這樣傳統關系型資料庫就無法發揮它的優勢。因此，目前互聯網行業偏向於使用NoSQL和分布式文件系統來存儲海量數據。
下面介紹下常用的NoSQL和分布式文件系統。
NoSQL
互聯網行業常用的NoSQL有：HBase、MongoDB、Couchbase、LevelDB。
HBase是Apache Hadoop的子項目,理論依據為Google論文 Bigtable: A Distributed Storage System for Structured Data開發的。HBase適合存儲半結構化或非結構化的數據。HBase的數據模型是稀疏的、分布式的、持久穩固的多維map。HBase也有行和列的概念，這是與RDBMS相同的地方，但卻又不同。HBase底層採用HDFS作為文件系統，具有高可靠性、高性能。
MongoDB是一種支持高性能數據存儲的開源文檔型資料庫。支持嵌入式數據模型以減少對資料庫系統的I/O、利用索引實現快速查詢，並且嵌入式文檔和集合也支持索引，它復制能力被稱作復制集（replica set），提供了自動的故障遷移和數據冗餘。MongoDB的分片策略將數據分布在伺服器集群上。
Couchbase這種NoSQL有三個重要的組件：Couchbase伺服器、Couchbase Gateway、Couchbase Lite。Couchbase伺服器，支持橫向擴展，面向文檔的資料庫，支持鍵值操作，類似於SQL查詢和內置的全文搜索;Couchbase Gateway提供了用於RESTful和流式訪問數據的應用層API。Couchbase Lite是一款面向移動設備和「邊緣」系統的嵌入式資料庫。Couchbase支持千萬級海量數據存儲
分布式文件系統
如果針對單個大文件，譬如超過100MB的文件，使用NoSQL存儲就不適當了。使用分布式文件系統的優勢在於，分布式文件系統隔離底層數據存儲和分布的細節，展示給用戶的是一個統一的邏輯視圖。常用的分布式文件系統有Google File System、HDFS、MooseFS、Ceph、GlusterFS、Lustre等。
相比過去打電話、發簡訊、用彩鈴的「老三樣」，移動互聯網的發展使得人們可以隨時隨地通過刷微博、看視頻、微信聊天、瀏覽網頁、地圖導航、網上購物、外賣訂餐等，這些業務的海量數據都構建在大規模網路雲資源池之上。當14億中國人把衣食住行搬上移動互聯網的同時，也給網路雲資源池帶來巨大業務挑戰。
首先，用戶需求動態變化，傳統業務流量主要是端到端模式，較為穩定；而互聯網流量易受熱點內容牽引，數據流量流向復雜和規模多變：比如雙十一購物狂潮，電商平台訂單創建峰值達到58.3萬筆，要求通信網路提供高並發支持；又如優酷春節期間有超過23億人次上網刷劇、抖音拜年短視頻增長超10倍，需要通信網路能夠靈活擴充帶寬。面對用戶動態多變的需求，通信網路需要具備快速洞察和響應用戶需求的能力，提供高效、彈性、智能的數據服務。
「隨著通信網路管道十倍百倍加粗、節點數從千萬級逐漸躍升至百億千億級，如何『接得住、存得下』海量數據，成為網路雲資源池建設面臨的巨大考驗」，李輝表示。一直以來，作為新數據存儲首倡者和引領者，浪潮存儲攜手通信行業用戶，不斷 探索 提速通信網路雲基礎設施的各種姿勢。
早在2018年，浪潮存儲就參與了通信行業基礎設施建設，四年內累計交付約5000套存儲產品，涵蓋全快閃記憶體儲、高端存儲、分布式存儲等明星產品。其中在網路雲建設中，浪潮存儲已連續兩年兩次中標全球最大的NFV網路雲項目，其中在網路雲二期建設中，浪潮存儲提供數千節點，為上層網元、應用提供高效數據服務。在最新的NFV三期項目中，浪潮存儲也已中標。
能夠與通信用戶在網路雲建設中多次握手，背後是浪潮存儲的持續技術投入與創新。浪潮存儲6年內投入超30億研發經費，開發了業界首個「多合一」極簡架構的浪潮並行融合存儲系統。此存儲系統能夠統籌管理數千個節點，實現性能、容量線性擴展；同時基於浪潮iTurbo智能加速引擎的智能IO均衡、智能資源調度、智能元數據管理等功能，與自研NVMe SSD快閃記憶體檔進行系統級別聯調優化，讓百萬級IO均衡落盤且路徑更短，將存儲系統性能發揮到極致。
「為了確保全球最大規模的網路雲正常上線運行，我們聯合用戶對存儲集群展開了長達數月的魔鬼測試」，浪潮存儲工程師表示。網路雲的IO以虛擬機數據和上層應用數據為主，浪潮按照每個存儲集群支持15000台虛機進行配置，分別對單卷隨機讀寫、順序寫、混合讀寫以及全系統隨機讀寫的IO、帶寬、時延等指標進行了360無死角測試，達到了通信用戶提出的單卷、系統性能不低於4萬和12萬IOPS、時延小於3ms的要求，產品成熟度得到了驗證。
以通信行業為例，2020年全國移動互聯網接入流量1656億GB，相當於中國14億人每人消耗118GB數據；其中春節期間，移動互聯網更是創下7天消耗36億GB數據流量的記錄，還「捎帶」打了548億分鍾電話、發送212億條簡訊……海量實時數據洪流，在網路雲資源池(NFV)支撐下收放自如，其中分布式存儲平台發揮了作用。如此樣板工程，其巨大示範及拉動作用不言而喻。
㈣ 幾萬條數據的循環查詢和插入，資料庫內百萬級數據，怎麼處理
其實就跟分頁獲取數據類似，網上這種例子就比較多了，分段獲取你可以把當前獲取的最大的自增id存儲在文件、資料庫或者memcache中，下一段用大於這個做條件，然後遍歷完再更新這個數就行了。
㈤ 消息隊列之zeroMQ、rabbitMQ、kafka
首先消息是網路通訊的載體，隊列可以理解是一種先進先出的數據結構，消息隊列是存放消息的容器，是分布式系統中的重要組件。消息隊列的優勢在於：解耦、非同步、削峰，把相關性不
強的模塊獨立分開視為解耦，非同步就是非必要邏輯非同步方式處理，加快響應速度，削峰是避免短期高並發導致系統問題進行緩沖隊列處理。消息隊列的缺點在於：加強系統復雜性、系統可用性降低，使
用了消息隊列系統出現問題排查的范圍就變大、需要考慮消息隊列導致的問題。
本文說明主流的消息隊列，針對使用過的zeroMQ和rabbitMQ、Kakfa：
zeroMQ ：C語言開發，號稱最快的消息隊列，本著命名zero的含義，中油中間架構使用簡單，表面上是基於socket的封裝套接字API，在多個節點應用場景下非常靈活、架構的可擴展性很強，
實現N到M的協同處理；
zmq的socket模式： req、rep、push、pull、pub、sub、router、dealer。
（1）req和rep：請求回應模型，req和rep都可以請求和回答，不同的只是req是先send再rec，rep是先rec再send。支持N個請求端一個接收端，也支持N個接收端一個請求端。N個接收端采
用rr負載均衡。 哪個是「一」端，哪個就bind埠，「N」端就只能connect，所以，req+rep無論誰bind埠，肯定要有一個是「一」。
（2） router和dealer：隨時可以發送和接收的req和rep，看起來router+dealer跟 req+rep屬於同類功能。因為router和dealer可以隨時發送接收，所以它們可以用來做路由。一個router用來響
應N個req，然後它在響應處理的時候，再通過另一個socket把請求扔出去，接收者是另外的M個rep，這就做到N:M。
（3）pub和sub ：訂閱和推送，對應發布者和訂閱者。
（4）push和pull：就是管道，一個只推數據，一個只拉數據。
rabbitMQ ：使用erlang語言開發，高並發特點，基於AMQP（即Advanced Message Queuing Protocol）的開源高級消費隊列，AMQP的主要特徵是面向消息、隊列、路由（包括點對點和發布/
訂閱）、可靠性、安全），企業級適應性和穩定性，並且有WEB管理界面方便用戶查看和管理。以下是rabbitMQ的結構圖：
（1）Procer:數據發送方，一般一個Message有兩個部分：payload（有效載荷）和label（標簽），payload是數據實際載體，label是exchange的名字或者一個tag，決定發給哪個Consumer；
（2）Exchange: 內部 消息交換器,exchange從生產者那收到消息後，一般會指定一個Routing Key，來指定這個消息的路由規則，當然Routing Key需要與Exchange Type及Binding key聯合使用
才能最終生效，根據路由規則，匹配查詢表中的routing key，分發消息到queue中；
（3）binding：即綁定，綁定（Binding）Exchange與Queue的同時，一般會指定一個Binding key，但不一定會生效，依賴於Exchange Type；
（4）Queue：即隊列是rabbitmq內部對象，用於存儲消息，一個message可以被同時拷貝到多個queue中，queue對load balance的處理是完美的。對於多個Consumer來說，RabbitMQ 使用循
環的方式（round-robin）的方式均衡的發送給不同的Consumer；
（5）Connection與Channel： Connection 就是一個TCP的連接，Procer和Consumer都是通過TCP連接到RabbitMQ Server， Channel 是為了節省開銷建立在上述的TCP連接中的介面，大部
分的業務操作是在Channel這個介面中完成的，包括定義Queue、定義Exchange、綁定Queue與Exchange、發布消息等；
（6）Consumer：即數據的接收方，如果有多個消費者同時訂閱同一個Queue中的消息，Queue中的消息會被平攤給多個消費者；
（7）Broker: 即RabbitMQ Server，其作用是維護一條從Procer到Consumer的路線，保證數據能夠按照指定的方式進行傳輸；
（8）Virtual host：即虛擬主機，當多個不同的用戶使用同一個RabbitMQ server提供的服務時，可以劃分出多個vhost，每個用戶在自己的vhost創建exchange／queue；
rabbitMQ消息轉發中的路由轉發是重點，生產者Procer在發送消息時，都需要指定一個RoutingKey和Exchange，Exchange收到消息後可以看到消息中指定的RoutingKey，再根據當前
Exchange的ExchangeType,按一定的規則將消息轉發到相應的queue中去。三種Exchage type：
（1）Direct exchange ：直接轉發路由，原理是通過消息中的routing key，與binding 中的binding-key 進行比對，若二者匹配，則將消息發送到這個消息隊列；
比如：消息生成者生成一個message(payload是1，routing key為蘋果)，兩個binding(binding key分別為蘋果、香蕉);exchange比對消息的routing key和binding key後，將消息發給了queue1，消息消費者1獲得queue1的消息；
（2）Topic exchange： 通配路由，是direct exchange的通配符模式，
比如：消息生成者生成一個message(payload是1，routing key為quick.orange.rabbit)，兩個binding(binding key分別為*.orange. 、 *.*.rabbit)；exchange比對消息的routing key和binding key
後,exchange將消息分發給兩個queue，兩個消費者獲得queue的消息；
（3）Fanout exchange： 復制分發路由，原理是不需要routkey，當exchange收到消息後，將消息復制多份轉發給與自己綁定的消息隊列，
比如：消息生成者生成一個message(payload是1，routing key為蘋果)，兩個binding(binding key分別為蘋果、香蕉)；exchange將消息分發給兩個queue，兩個消費者獲得queue的消息；
rabbiMQ如何保證消息的可靠性？
（1）Message rability：消息持久化，非持久化消息保存在內存中，持久化消息寫入內存同時也寫入磁碟；
（2）Message acknowledgment：消息確認機制，可以要求消費者在消費完消息後發送一個回執給RabbitMQ，RabbitMQ收到消息回執（Message acknowledgment）後才將該消息從Queue中移
除。通過ACK。每個Message都要被acknowledged（確認，ACK）。
（3）生產者消息確認機制：AMQP事務機制、生產者消息確認機制（publisher confirm）。
最後， 對比一下zeroMQ、rabbitMQ、kafka主流的消息隊列的性能情況：
對比方向 概要
吞吐量 萬級 RabbitMQ 的吞吐量要比 十萬級甚至是百萬級Kafka 低一個數量級。ZeroMQ號稱最快的消息隊列系統，尤其針對大吞吐量的需求場景。
可用性 都可以實現高可用。RabbitMQ 都是基於主從架構實現高可用性。 kafka 也是分布式的，一個數據多個副本，少數機器宕機，不會丟失數據，不會導致不可用
時效性 RabbitMQ 基於erlang開發，所以並發能力很強，性能極其好，延時很低，達到微秒級。其他兩個個都是 ms 級。
功能支持 Kafka 功能較為簡單，主要支持簡單的MQ功能，在大數據領域實時計算以及日誌採集被大規模使用；ZeroMQ能夠 實現RabbitMQ不擅長的高級/復雜 的隊列
消息丟失 RabbitMQ有ack模型，也有事務模型，保證至少不會丟數據， Kafka 理論上不會丟失，但不排除批量情況下。
開發環境 RabbitMQ需要erlang支持、kafka基於zookeeper管理部署、zeroMQ程序編譯調用即可
封裝庫 基於c++開發，使用RabbitMQ-C，cppKafka，而zeroMQ基於C語言開發，無需封裝
㈥ sqlite 能存儲百萬級數據嗎
能存儲，微信ios和android客戶端就是用的sqlite存儲。一些做微商的用戶，消息數據數量常為百萬級別。
㈦ 計算機內存儲器的最小存儲單位是什麼
計算機存儲信息的最小單位，稱之為位(bit，又稱比特) 存儲器中所包含存儲單元的數量稱為存儲容量，其計量基本單位是位元組(Byte。簡稱B)，8個二進制位稱為1個位元組，此外還有KB、MB、GB、TB等，它們之間的換算關系是1Byte=8bit，1KB=1024B，1MB=1024KB，1GB=1024MB，1TB=1024GB
拓展資料：
1、計算機內存又稱為內存儲器，通常也泛稱為主存儲器，是計算機中的主要部件，它是相對於外存而言的。內存儲器是計算機中重要的部件之一，它是與CPU進行溝通的橋梁。計算機中所有程序的運行都是在內存儲器中進行的，因此內存儲器的性能對計算機的影響非常大。內存儲器(Memory)也被稱為內存，其作用是用於暫時存放CPU中的運算數據，以及與硬碟等外部存儲器交換的數據。只要計算機在運行中，CPU就會把需要運算的數據調到內存中進行運算，當運算完成後CPU再將結果傳送出來，內存的運行也決定了計算機的穩定運行。 內存是由內存晶元、電路板、金手指等部分組成的。
2、計算機內存儲器包括寄存器、高速緩沖存儲器(Cache)和主存儲器。寄存器在CPU晶元的內部，高速緩沖存儲器也製作在CPU晶元內，而主存儲器由插在主板內存插槽中的若干內存條組成。內存的質量好壞與容量大小會影響計算機的運行速度。
㈧ 百萬級數據量Kafka發送
談到大數據傳輸都會想到 Kafka，Kafka 號稱大數據的殺手鐧，在業界有很多成熟的應用場景並且被主流公司認可。這款為大數據而生的消息中間件，以其百萬級TPS的吞吐量名聲大噪，迅速成為大數據領域的寵兒，在數據採集、傳輸、存儲的過程中發揮著舉足輕重的作用。
在業界已經有很多成熟的消息中間件如：RabbitMQ, RocketMQ, ActiveMQ, ZeroMQ，為什麼 Kafka 在眾多的敵手中依然能有一席之地，當然靠的是其強悍的吞吐量。下面帶領大家來揭秘。
Kafka 如何做到支持百萬級 TPS ？
先用一張思維導圖直接告訴你答案：
Kafka 支持百萬TPS的秘密
順序讀寫磁碟
生產者寫入數據和消費者讀取數據都是 順序讀寫 的，先來一張圖直觀感受一下順序讀寫和隨機讀寫的速度：
順序讀寫 VS 隨機讀寫
從圖中可以看出傳統硬碟或者SSD的順序讀寫甚至超過了內存的隨機讀寫，當然與內存的順序讀寫對比差距還是很大。
所以Kafka選擇順序讀寫磁碟也不足為奇了。
下面以傳統機械磁碟為例詳細介紹一下什麼是順序讀寫和隨機讀寫。
碟片 和 盤面 ：一塊硬碟一般有多塊碟片，碟片分為上下兩面，其中有效面稱為盤面，一般上下都有效，也就是說： 盤面數 = 碟片數 * 2。
磁頭 ：磁頭切換磁軌讀寫數據時是通過機械設備實現的，一般速度較慢；而磁頭切換盤面讀寫數據是通過電子設備實現的，一般速度較快，因此磁頭一般是先讀寫完柱面後才開始尋道的(不用切換磁軌)，這樣磁碟讀寫效率更快。
傳統機械磁碟
磁軌 ：磁軌就是以中間軸為圓心的圓環，一個盤面有多個磁軌，磁軌之間有間隙，磁軌也就是磁碟存儲數據的介質。磁軌上布有一層磁介質，通過磁頭可以使磁介質的極性轉換為數據信號，即磁碟的讀，磁碟寫剛好與之相反。
柱面 ：磁碟中不同盤面中半徑相同的磁軌組成的，也就是說柱面總數 = 某個盤面的磁軌數。
扇區 ：單個磁軌就是多個弧形扇區組成的，盤面上的每個磁軌擁有的扇區數量是相等。扇區是最小存儲單元，一般扇區大小為512bytes。
單碟片示意圖
如果系統每次只讀取一個扇區，那恐怕效率太低了，所以出現了block（塊）的概念。文件讀取的最小單位是block，根據不同操作系統一個block一般由多個扇區組成。
有了磁碟的背景知識我們就可以很容易理解順序讀寫和隨機讀寫了。
插播維基網路定義：
順序讀寫 ：是一種按記錄的邏輯順序進行讀、寫操作的存取方法 ，即按照信息在存儲器中的實際位置所決定的順序使用信息。
隨機讀寫 ：指的是當存儲器中的消息被讀取或寫入時，所需要的時間與這段信息所在的位置無關。
當讀取第一個block時，要經歷尋道、旋轉延遲、傳輸三個步驟才能讀取完這個block的數據。而對於下一個block，如果它在磁碟的其他任意位置，訪問它會同樣經歷尋道、旋轉、延時、傳輸才能讀取完這個block的數據，我們把這種方式叫做 隨機讀寫 。但是如果這個block的起始扇區剛好在剛才訪問的block的後面，磁頭就能立刻遇到，不需等待直接傳輸，這種就叫 順序讀寫 。
好，我們再回到 Kafka，詳細介紹Kafka如何實現順序讀寫入數據。
Kafka 寫入數據是順序的，下面每一個Partition 都可以當做一個文件，每次接收到新數據後Kafka會把數據插入到文件末尾，虛框部分代表文件尾。
順序寫
這種方法有一個問題就是刪除數據不方便，所以 Kafka 一般會把所有的數據都保留下來，每個消費者（Consumer）對每個Topic都有一個 offset 用來記錄讀取進度或者叫坐標。
順序讀
Memory Mapped Files(MMAP)
在文章開頭我們看到硬碟的順序讀寫基本能與內存隨機讀寫速度媲美，但是與內存順序讀寫相比還是太慢了，那 Kafka 如果有追求想進一步提升效率怎麼辦？可以使用現代操作系統分頁存儲來充分利用內存提高I/O效率，這也是下面要介紹的 MMAP 技術。
MMAP 也就是 內存映射文件 ，在64位操作系統中一般可以表示 20G 的數據文件，它的工作原理是直接利用操作系統的 Page 來實現文件到物理內存的直接映射，完成映射之後對物理內存的操作會被同步到硬碟上。
MMAP原理
通過 MMAP 技術進程可以像讀寫硬碟一樣讀寫內存（邏輯內存），不必關心內存的大小，因為有虛擬內存兜底。這種方式可以獲取很大的I/O提升，省去了用戶空間到內核空間復制的開銷。
也有一個很明顯的缺陷，寫到 MMAP 中的數據並沒有被真正的寫到硬碟，操作系統會在程序主動調用 flush 的時候才把數據真正的寫到硬碟。
Kafka提供了一個參數：procer.type 來控制是不是主動 flush，如果Kafka寫入到MMAP之後就立即flush然後再返回Procer叫同步(sync)；寫入MMAP之後立即返回Procer不調用flush叫非同步(async)。
Zero Copy（零拷貝）
Kafka 另外一個黑技術就是使用了零拷貝，要想深刻理解零拷貝必須得知道什麼是DMA。
什麼是DMA?
眾所周知 CPU 的速度與磁碟 IO 的速度比起來相差幾個數量級，可以用烏龜和火箭做比喻。
一般來說 IO 操作都是由 CPU 發出指令，然後等待 IO 設備完成操作後返回，那CPU會有大量的時間都在等待IO操作。
但是CPU 的等待在很多時候並沒有太多的實際意義，我們對於 I/O 設備的大量操作其實都只是把內存裡面的數據傳輸到 I/O 設備而已。比如進行大文件復制，如果所有數據都要經過 CPU，實在是有點兒太浪費時間了。
基於此就有了DMA技術，翻譯過來也就是直接內存訪問（Direct Memory Access），有了這個可以減少 CPU 的等待時間。
Kafka 零拷貝原理
如果不使用零拷貝技術，消費者（consumer）從Kafka消費數據，Kafka從磁碟讀數據然後發送到網路上去，數據一共發生了四次傳輸的過程。其中兩次是 DMA 的傳輸，另外兩次，則是通過 CPU 控制的傳輸。
四次傳輸過程
第一次傳輸 ：從硬碟上將數據讀到操作系統內核的緩沖區里，這個傳輸是通過 DMA 搬運的。
第二次傳輸 ：從內核緩沖區裡面的數據復制到分配的內存裡面，這個傳輸是通過 CPU 搬運的。
第三次傳輸 ：從分配的內存裡面再寫到操作系統的 Socket 的緩沖區裡面去，這個傳輸是由 CPU 搬運的。
第四次傳輸 ：從 Socket 的緩沖區裡面寫到網卡的緩沖區裡面去，這個傳輸是通過 DMA 搬運的。
實際上在kafka中只進行了兩次數據傳輸，如下圖：
兩次傳輸，零拷貝技術
第一次傳輸 ：通過 DMA從硬碟直接讀到操作系統內核的讀緩沖區裡面。
第二次傳輸 ：根據 Socket 的描述符信息直接從讀緩沖區裡面寫入到網卡的緩沖區裡面。
我們可以看到同一份數據的傳輸次數從四次變成了兩次，並且沒有通過 CPU 來進行數據搬運，所有的數據都是通過 DMA 來進行傳輸的。沒有在內存層面去復制（Copy）數據，這個方法稱之為 零拷貝（Zero-Copy）。
無論傳輸數據量的大小，傳輸同樣的數據使用了零拷貝能夠縮短 65% 的時間，大幅度提升了機器傳輸數據的吞吐量，這也是Kafka能夠支持百萬TPS的一個重要原因。
Batch Data（數據批量處理）
當消費者（consumer）需要消費數據時，首先想到的是消費者需要一條，kafka發送一條，消費者再要一條kafka再發送一條。但實際上 Kafka 不是這樣做的，Kafka 耍小聰明了。
Kafka 把所有的消息都存放在一個一個的文件中，當消費者需要數據的時候 Kafka 直接把文件發送給消費者。比如說100萬條消息放在一個文件中可能是10M的數據量，如果消費者和Kafka之間網路良好，10MB大概1秒就能發送完，既100萬TPS，Kafka每秒處理了10萬條消息。
看到這里你可以有疑問了，消費者只需要一條消息啊，kafka把整個文件都發送過來了，文件裡面剩餘的消息怎麼辦？不要忘了消費者可以通過offset記錄消費進度。
發送文件還有一個好處就是可以對文件進行批量壓縮，減少網路IO損耗。
總結
最後再總結一下 Kafka 支持百萬級 TPS 的秘密：
（1）順序寫入數據，在 Partition 末尾追加，所以速度最優。
（2）使用 MMAP 技術將磁碟文件與內存映射，Kafka 可以像操作磁碟一樣操作內存。
（3）通過 DMA 技術實現零拷貝，減少數據傳輸次數。
（4）讀取數據時配合sendfile直接暴力輸出，批量壓縮把所有消息變成一個批量文件，合理減少網路IO損耗。