一、CBS架構演進
1. CBS雲硬盤
什麼是雲硬盤呢？騰訊雲的雲硬盤叫 CBS，CBS 就是 Cloud Block Storage，基於雲的分佈式塊存儲服務。
雲的概念聽起來很玄乎，其實我理解的雲的核心技術就是分佈式，雲是分佈式的一個商業包裝，通過雲這個接口把它推出去，給大家提供就像水、電一樣的基礎服務，這是我給雲的定義。
雲裏邊最核心的是分佈式技術，雲硬盤也是基於分佈式去實現的一個硬盤，跟電腦裏面的硬盤功能相同，但是又比個人電腦裏的硬盤有更豐富的能力。
比如基於分佈式實現，性能上就使得橫向拓展的能力非常好。個人電腦硬盤只能提供幾百兆的吞吐能力，CBS 基於雲的硬盤可以提供更大的存儲性能，我們現在可以做到5GB，這是本地傳統物理硬盤很難做到的。
在可靠性方面，CBS 是基於多副本的存儲策略，也就是說原則上會將用戶數據存多份，一般是三份，這樣的策略讓數據的可靠性更強。
另外是可用性方面。傳統的物理硬盤壞了，上面的數據就丟了，也就影響到了用戶的服務。但是雲硬盤不一樣，它是基於分佈式實現的，當這一塊硬盤故障的時候可以快速進行隔離，因爲是多副本存儲數據的，另外的副本就可以及時的提供服務，不影響用戶的可用性。
當前雲硬盤服務主要的對象是大家在騰訊雲上買的雲主機，是給雲主機提供持久化的塊存儲服務的。
以上這些就是我給 CBS 雲硬盤下的定義，首先它是基於分佈式技術實現的，就像個人電腦硬盤一樣，硬盤可以提供的所有能力它都可以提供，並且在高性能、可靠性和可用性進行了增強，提供持久化的塊存儲服務。
2. CBS架構演進
CBS 的演進經過了三代架構 —— CBS apllo、CBS atlas 和 HiSTOR。塊存儲最早是從 2011 年開始做的，當時不叫 CBS，而是叫 TBS。最早的一代架構是基於以前騰訊雲架構平臺部已有的存儲平臺打造了塊存儲的服務。但這個已有的存儲平臺一開始並不是爲塊這個場景專門設計的，所以存在很多問題。
2013 年、2014 年是雲發展比較快的階段，當 2014 年規模到了幾個 PB 的時候，發現當時的架構不能承載用戶的需求，所以在 2014 年時用 CBS apllo 及時替代了更老的一代架構，適應了雲快速發展的需求，快速的把塊存儲的規模從幾 PB 增加到了上百 PB，個人認爲這是非常優秀的一代架構。
但是到 2016 年，雖然以前的架構很優秀，但是成本方面會略高一些、性能上也不盡如意，所以在2016年希望能夠在成本和性能方面有所改進，性能這也是本期我要講的主題。
在 2016 年我們設計了新一代 CBS 架構 Atlas，2017 年 Atlas 正式上線接用戶業務。
目前在騰訊雲上跑的主流的架構是 CBS atlas，承載着數 EB 的數據規模。現在很多用戶把數據放在雲上，騰訊雲上也已經衍生了幾十億、上百億、甚至上千億美金的獨角獸公司出來，他們就是依賴於雲去支撐他們的服務。
在現在這個階段，就要全場景的看用戶的需求，最主要的一塊就是對性能的要求慢慢成爲了矛盾的焦點。原先預計雲盤很快便會取代本地盤，但在去年的時候發現取代的節奏在變緩，分析之後發現用戶仍用本地盤是因爲雲盤某些場景沒有服務好，典型的是關於 DB 的需求。
雲盤是基於分佈式的，中間通過網絡互聯，天生比本地盤的延時略高，但是到底高多少呢？如果高的程度能夠在提供的優勢可以覆蓋住的情況下，用戶就會願意用 CBS 盤，但如果影響大於優勢，那麼用戶就不接受了。
這時候這個矛盾就凸顯出來了，要解決用戶在性能上的需求，這時候“極速存儲”就應運而生，它在性能上有了很大的提升。到今年上半年的時候平臺側就達到了我們認爲能夠滿足用戶需求的能力，今年 8 月產品層面推出相關產品。
以上就是我參與的三代架構以及前面沒有參與那代架構演進的歷程。我列了三個時間點，其中2014年是非常重要的時間點，雲快速發展推出 applo 架構，2017 年推出 atlas 架構，到去年爲了解決用戶全面上雲對性能的要求，我們投入精力搞了 HiSTOR 的架構。
3. CBS存儲系統
CBS 存儲系統架構到底是怎麼樣的呢？最新的架構可以分成三塊：
- 客戶端
- 存儲集羣
- 控制集羣
先介紹一下存儲集羣，存儲系統很重要的一塊就是存儲集羣，這是後端的存儲給用戶提供存儲服務；另外給用戶提供服務肯定要有個接入點，也就是前面的客戶端；分佈式系統要有對集羣做控制的模塊，也就是控制集羣，當然控制模塊本身也是多機的分佈式系統；CBS存儲系統可以分爲這三塊。
今天要講的是塊存儲，其實現在 CBS 存儲系統已經被打造成了統一的存儲平臺，現在騰訊雲上購買的雲文件也是這一套存儲系統提供的服務，另外雲原生的數據庫，後端的存儲系統也是它。
CBS 的存儲系統 HiSTOR 的特點首先是極簡的架構。多年前我也對外分享過一個“大道至簡”的設計理念，用極簡的架構滿足用戶的需求是最好的。
整個集羣分爲三部分，客戶端直接訪問存儲，中間沒有傳統的存儲系統的接入模塊，所以是一種極簡的架構。
另一個特點是統一存儲。我們提供的不僅是塊存儲服務，而是多種存儲類型服務共享的一個平臺。CBS 存儲系統爲什麼一直向前演進呢？因爲要解決問題。
Atlas 取代 Applo 核心的目的是什麼？首先是成本，因爲架構層面足夠的簡單，只有兩層，沒有中間的接入集羣、接入設備和其他的管理設備是沒有的，所以在成本上是大大的降低了。
這套架構比之前的架構在成本上有優勢，物理成本上節約了 50% 左右，但產品怎麼能夠讓用戶去買單呢？要讓用戶有買單的意願就要做到成本足夠低，成本問題是幾年前解決用戶上雲的需求的主要矛盾。
慢慢的在用戶上雲了以後，包括核心的業務開始往雲上切，騰訊雲上已經孕育出了很多十億、上百億、上千億美金的獨角獸公司，這個時候如何讓用戶放心把業務放到雲上呢？一定要讓其用得放心，質量一定要過關，解決成本問題後我們投入大量的精力在質量上。
質量要過關，可靠性、可用性和數據安全方面一定要過關。
二、CBS新的挑戰
現在很多公司已經把它的全部業務都放到雲上，這時候就需要把他服務好，讓他用得爽。雲盤相對本地盤主要的劣勢就是延時相對本地盤比較高，所以今天要講的主題是怎麼在這一點上有所突破。
性能方面有三個維度，除了一再強調的延時維度，還有吞吐維度和 IOPS 的維度。
1. 吞吐維度
吞吐維度指的是帶寬。現在很多大數據場景、AI 訓練的場景對帶寬的需求非常大，SSD 雲盤提供的 260 兆的帶寬，跟用戶需求是有落差的，所以除了在延時上需要做到極致以外，帶寬方面也要滿足用戶的需求。
2. IOPS
以前都是本地盤間的比較，大家覺得 IOPS 不是個矛盾點，本地物理硬盤隨機訪問的IOPS 也就是在 200、300 的級別。而云盤產生之後，最老的一代產品能夠提供的是幾千的IOPS。
當時是可以滿足需求，但慢慢的上雲的場景越來越多後，雲主機的母機上單個服務對 IOPS 的需求不高，但是加在一起需求就變得很大。
3. 延時維度
延時維度最典型的是 DB 的業務。可能多年前放在雲硬盤上的數據價值並不高，但是 DB 數據價值密度非常高，如何把 DB 應用場景服務好也是需要花很大的精力思考的問題。
三、CBS低延時結構優化
1. CBS延時優化
那麼 CBS 延時如何優化呢？很多人提出過很多具體手段，但是總結起來就是兩個方面，一是怎麼把併發做上去，二是怎麼把延時做下來。
把併發做上去，這是分佈式存儲天然有的優勢，只是技術實現上的難度大小而已，但跟延時比起來並不是這麼困難。
低延時無非是兩種手段，首先用更快的硬件去解決，另外是怎麼把軟件 IO 棧做到儘量的扁平化，本期的主要是基於軟件的維度考慮延時優化，具體是從 CBS 的四個維度入手：分佈式層面優化、接入端、存儲側和中間交互的網絡的優化方面。
2. 分佈式架構
CBS 存儲系統是極簡的架構，客戶端訪問存儲中間就是網絡，涉及優化的也就是三個層面加一個架構，我們按這幾點來進行分解。
首先從架構層面，CBS altas 直接從客戶端訪問存儲，是兩層分佈式架構，沒有傳統的接入點也就沒有了接入瓶頸。另外是客戶端直接訪問存儲中間訪問路徑可以做到最短，這就是當前架構的優勢。
說起來很簡單，但做成兩層架構實現起來技術難度很大。首先是路由管理上如何做？CBS 的存儲系統用的路由方式是一致性哈希，這就涉及到哈希路由如何推送到客戶端。
本身路由的變更是由控制集羣維護的，路由更新後如果直接推送客戶端的話看起來很簡單，但面對雲上的集羣規模就會發現問題。騰訊目前是上百萬臺的規模，如果把一個信息推送到上百萬個節點根本是不可行的事情。
所以在實現上我們想個了方式叫“惰性路由同步”，集羣管理節點變更後不是直接推送客戶端而是推送到存儲節點，再由節點中轉到客戶端。
爲什麼這樣可行呢？接入節點上百萬臺，但是存儲節點比客戶端節點是數量少得多，推送到存儲節點對中心控制節點的負載是可以容忍的，所以先推送到存儲節點，之後對中控系統來說工作就完成了，推送也就完成了。
惰性路由同步的惰性體現在哪裏？起名字的時候我們借鑑了內核內存分配的方式，內核去申請內存的時候只是一個虛擬的，並沒有把真實物理內存分配給你。
分佈式架構里路由同步的策略也是類似的，先推送之後並不急於推送到客戶端節點，如果有需求訪問存儲的時候，再同步把路由推送到客戶端節點。這時候拿到最新的路由就可以訪問到需要的數據了，使用的時候再去推送的策略便是“惰性路由同步”。
架構層面，原先的架構雖然說是兩層，但因爲是多副本存儲，數據到了存儲節點後還有一次複製的過程，需要再複製成多份數據存到節點上去，這時候雖然架構上是極簡的，但寫的時候有兩次的路由，就相當於數據走了兩跳。
爲了做到延時上的極簡，我們是根據 IO 大小做了不同的策略，如果是小 IO 的話，走的是以前的模式，直接客戶端出三份，這樣對小 IO 便只需要一跳。
但爲什麼大 IO 不這麼做呢？客戶端出流量的話，出三份其實是佔用計算的網絡流量的，所以這樣是需要跟前端計算的同事協商的。但小的 IO 這麼做，不需要增加前端的計算帶寬，這就是爲什麼大小 IO 需要做不同策略的原因。
3. CBS接入端
上圖所示的客戶端架構是一個主流的架構，接入方式是基於 iSCSI 的通用塊設備接入，虛擬機通過訪問存儲的時候是 QEMU 訪問一個主機上的塊設備，往下走 SCSI 設備。
SCSI 的底層就是 iSCSI initiator，通過網絡訪問 CBS 的客戶端，然後再訪問後端存儲。路徑非常的長，首先要複製數據、切換訪問內核，之後通過 iSCSI ，再通過網絡訪問 CBS 的客戶端，客戶端再通過網絡把數據發出來，中間經過了多少次的上下文切換和數據拷貝，所以延時上非常不友好。
有沒有其他的接入方式呢？第一次想這個問題的時候是在 2016 年，我們在設計架構時，當時想直接用共享內存的方式把數據旁路出來，就不用經過這麼多次的來來回回的切換了。
後來老闆們說你爲什麼這麼做呢，英特爾搞了一個更好的東西，就是可以直接在虛擬機上把數據旁路出來，也就是 SPDK。IO 設備是虛擬機的話，SPDK 可以做 IO 的後端，直接把數據同步出來，再把客戶端做到 SPDK 裏面，這個數據路徑是要短非常多。
虛擬機裏面直接用數據共享的方式跟 SPDK 交互數據，SPDK 在後端訪問存儲，再經過網絡處理，比起剛纔說的來來回回好幾次要簡單得多了。
但是不是這樣就做到極致了呢？最初做的方式是 SPDK 跟客戶端的訪問沒有在一個線程裏面，而是兩個線程，之間通過共享內存。
但這樣對延時並不友好，因爲經過了線程的一次切換，哪怕只是幾個微秒的區別，但在一個超高性能場景中幾微秒也是比較多的。所以我們又做了優化，把客戶端跟 SPDK 放在同一個線程裏做，這樣就沒有線程上下文的切換了。
總結下來，是用 SPDK 的接入方式取代了 iSCSI 的接入方式，用零拷貝的輪詢方式取代了原來兩線程數據共享的方式。最後是有一個水平擴展的能力，這跟延時無關。
剛纔提到老闆們站的高度更高，在 2016 年便提出了用 SPDK，那 SPDK 到底是什麼呢？
這是一個英特爾用來做高性能存儲的開發套件，提供一些 lib 庫之類的工具，通過它做高性能存儲的應用開發。具體技術實現首先是在用戶態實現的，可以減少對內核的切換，用戶態、內核間的上下文切換對 CPU 消耗也比較高，另外就是輪詢，說白了就是 CPU 的死轉。SPDK 主要就是這些方面的技術。
4. CBS存儲引擎
2016 年在做架構的時候，首先開發了一個高性能的開發框架叫 CEDA。這是基於封裝的事件驅動的框架，核心理念是基於微服務模型，是事件驅動的、事件觸發的高性能的開發框架，存儲引擎是基於 CEDA 框架實現的。
膠片裏面有個 DATA POOl，也就是數據池，IO 過來之後從數據池中分配數據存儲的內存，整個生命週期數據不做拷貝，所以可以做到數據零拷貝。
核心路徑上跟其他的 SPDK 理念一樣，不是用事件驅動的方式，而是用輪訓方式，雖然對 CPU 消耗高了，但沒有線程的喚醒和休眠，可以做到相對比較好的水平。
存儲引擎訪問硬盤，現在用的也是 SPDK 方式，可以儘量的減少訪問硬盤時在用戶端內核進行切換的時間消耗。
但這個過程仍然有一次切換，說白了還是沒有達到極致，用戶態的任務調度可以讓一個 IO 的處理從進存儲引擎到最後落地訪問存儲硬件整個在一個上下文裏面做，沒有切換的開銷，這樣就可以把延時做到極致。
5. CBS (極速型雲盤) 網絡
架構、客戶端、存儲引擎、中間是網絡，我們之所以把網絡放到最後，並不是說它不重要。軟件做到這樣是相當不錯的，但它的延時和網絡比起來還是小巫見大巫，一次跳轉的話大幾十個 us。
那麼如何在網絡上做優化呢？騰訊有兩款產品，CBS 極速型雲盤和增強型雲盤，極速雲盤是網絡層面用的 RDMA，遠程直接內存訪問，說得簡單一些就是一個硬件卸載的理念，把網絡的協議的處理儘量放在硬件裏面做，這樣可以旁路掉操作系統內核的工作。
在硬件和用戶態的應用之間直接共享數據，也就是全棧都沒有了內存的拷貝，也不需要內核和用戶態做協議的解析處理，這些硬件就幫你做了。通過這種操作這樣可以把延時降到極至，用的是旁路內核減少切換的理念。
那我們做得跟別人做的有什麼不同呢？總結起來，我們做的比較好的幾點，雖然是 RDMA 網絡，但我們並不單純是 RDMA，而是 RDMA 和 TCP 並存，在故障的時候可以快速自動切換。
另一方面擁塞控制，騰訊雲的量級是百萬級別的服務器規模，放眼全球 RDMA 的使用超過一萬臺機器規模的都很少，RDMA 集羣應用規模一般並不大，RDMA 的擁塞控制是比較大的隱患，或者說是現在存在的主要問題之一。
CBS 的 RDMA 擁塞控制層面如何做的呢？除了硬件提供的擁塞控制能力，應用層也做了控制，比如存儲和客戶端的交互用的 RDMA_read 方式。
RDMA 有幾種交互方式，一種是 send/recv 方式，一種是 read/write 的交互方式，簡單而言，前一種模式交互流程是短的、少的，但是切入應用之後會有一次數據的拷貝，因爲要有交互協議處理的 buff 和應用之間的 buff 拷貝，對大 IO 來說並不友好。
另一種方式 RDMA_read，最主要的好處是沒有了剛纔說的拷貝過程，所以對大 IO 比較友好，但是交互流程比前面說的方式要多幾跳，這樣對小 IO 並不友好。
所以從交互協議層面來說，用了這兩種相結合的方式。當需要帶寬的時候用的是 read 方式，當需要短的延時時候用的是 send/recv 方式。
用 read 方式做擁塞控制，存儲側來看，比如需要去寫個數據到存儲的時候，先跟存儲握手一次，告訴他我要寫了，這時候存儲向客戶端發一個 read 指令，控制權完全在存儲。
因爲整個集羣模型是非常多的客戶端訪問少量的存儲，存儲本身是容易發生擁塞的點，存儲端主動的發起數據的讀寫請求的話，可以根據自己的負載去做擁塞控制，這是基於應用的擁塞控制的可行性，以上是 CBS 在 RDMA 網絡方面做得相對比較有特色的幾個方面。
6. CBS（增強型雲盤）網絡
極速雲盤用的是 RDMA 網絡，增強型雲盤用的是 TCP 網絡，TCP 網絡是延時消耗的大頭，內核協議處理佔了整個網絡延時的百分之八九十，如果還是用 TCP 網絡的話就看如何解決掉內核佔消耗比較高的問題就可以了。
內核 TCP 方式是內核消耗高，因爲上下文切換很頻繁，解決這個矛盾放到用戶態來看，就是協議處理放到用戶態，沒有上下文切換。騰訊做的 ZTCP 用戶態協議棧同時也可以零拷貝，用戶協議也做了用戶態零拷貝以求性能的極至，這是增強型雲盤的網絡協議的優化。
7. CBS網絡模型對比
CBS 網絡模型的交互方式有三種：
- 傳統的內核 TCP 協議棧交互；
- 極速雲盤用的 RDMA 網絡交互；
- 增強型雲盤用的用戶態 TCP 協議棧交互。
我們對三者進行一個對比。內核態 TCP 把 TCP 解析放到內核，主要問題是頻繁的上下文的切換、太多的數據拷貝，這是它的問題。
用戶態協議棧是減少數據拷貝和上下文的切換，騰訊做 ZTCP 的特點是同時支持零拷貝，RDMA 是不需要軟件做而是硬件來幫助做，協議棧卸載到硬件裏面以求做到旁路掉內核、數據零拷貝，達到這個技術的要求，同而將延時降到最低，這是三種網絡交互形式的對比。
四、CBS延時優化成果
1. CBS延時能力
我們的 CBS 延時優化到底做到了什麼水平呢？上圖是產品化的時候開發同學測的數據，能夠做到的是 140 us 左右，百微秒級別，這還不是最新的數據，現在可以做到100 us 到 120 us 之間。
當前給到產品化的能力就是 100 us 到 150 us，研發側可以做 100 us 到 120 us 之間。接下來要做到什麼程度呢？給產品的目標是希望年底能夠做到 50 us 到 100 us 這樣的水平。
2. 產品化
產品化層面，8 月 13 日的時候產品側推出了一個叫增強型 SSD 雲硬盤的產品，這已經是正式的產品化了，可以在騰訊雲官網買到，現在極速型 SSD 雲硬盤也已經開始公測了。
以上就是我和大家分享的CBS在架構演進及基於當前最新的架構打造的百微秒級別的極速雲盤產品的情況，謝謝觀看。
五、Q&A
Q：支持幾PB到上百PB的瓶頸是什麼呢？
A： 從成本層面來看，就是在合理成本的情況提供讓客戶接受的產品。從質量層面看，就是怎麼能夠提供用戶可以接受的可靠性和可用性的一個產品。我認爲主要的瓶頸就是成本和質量，這個做大規模主要的兩個瓶頸點。
Q：一致性哈希將來遷移時怎麼避免數據遷移？
A： 數據遷移不能避免，但可以考慮如何減少。在實現上有一些儘量減少數據遷移的方式，比如去做路由分裂的時候，最粗暴的方式是把一個哈希分區的數據遷到兩個裏面去，避免的方式我只遷移分裂的一個新分區的數據，另一個分區還繼承老的分區屬性，這樣剩餘一般數據就不用遷移。
Q：高併發小 IO 高的話，client 會不會佔計算節點的 CPU 和內存很高？
A： 在 RDMA 協議層面我們是用了兩種相結合的方式，對於小 IO 用的 send/recv 的方式，對大 IO 用的是 read/write 的方式。這麼做的原因，是在大 IO 的情況下儘量減少對 CPU 的消耗，提升它的吞吐性能。對於小 IO 來說只能針對一部分特徵來減少 CPU 的消耗，不能避免 CPU 的消耗。client 佔用的資源已和客戶購買雲主機的 CPU/內存做了隔離，不會影響到客戶的雲主機使用。
Q：雲硬盤未來會逐步替代物理硬盤嗎？
A： 只要用戶把它的業務逐步的放在雲上，我認爲雲硬盤取代物理硬盤是一個大趨勢。雲硬盤相對於物理硬盤它的劣勢主要就在於延時層面，其他層面雲硬盤相對於物理硬盤都是有優勢的。只要能解決延時的問題，雲硬盤取代物理硬盤是必然趨勢。
Q：不同大小 IO 通過不同方式複製，大 IO 通過 raft 之類的算法麼？小 IO 直接複製到三個 store，是自己實現的複製算法麼？
A： CBS 沒有使用raft 算法，數據複製部分是使用自研的算法。
Q：新的架構在容災層面怎麼考慮的？
A： 分爲兩個層面，一個是元數據層面，一個是數據層面。元數據層面分爲集羣元數據和存儲原數據。集羣元數據也是三副本，我們會把原數據的變更，操作的流水，包括元數據本身記錄下來，所以原則上你的集羣元數據是可以恢復到任何一個時間點的。
存儲的元數據怎麼去解決？存儲的元數據跟集羣原數據一樣，我們會把所有變更記錄到硬盤上，包括變更流程也會記錄下來。另外一層面，會像集羣元數據一樣會把它弄到異構系統裏面。
還有一個層面，可能有些元數據只是記載了硬盤的一個位置，準確的說它是記在兩副本，但是記在一起的，物理位置是連續的。
在最新的架構裏面，兩個元數據的備份是放在硬盤的不同的位置，但不管你放幾份，放到哪裏，如果有人惡意破壞，那你還是會把數據搞丟。
怎麼去避免這種情況？我們現在最新的架構裏面做了一個離散元數據，就把所有的元數據的數據記在一起，去落地到硬盤上，每一個數據它都帶了自身的元數據，即使你把元數據集中區給抹掉了，我一樣可以從通過存在的數據把元數據恢復出來。從而保證元數據的安全。因爲元數據是描述數據的數據，是最重要的數據。如果它丟了即使數據存在那也等同於丟失，所以元數據就顯得異常重要，這幾個能力都是在元數據層面的安全加固。
容災還涉及到數據的容災，這方面我們是有快照能力的，未來幾天的直播中也會有其他小夥伴介紹這點，在這我就不深入講解了。
Q：雲盤的帶寬是否會佔用母機帶寬，擁塞時如何抉擇？
A： 現在數據多副本複製，我是有兩種策略，一種是先把那個數據路由到一個主節點處，主節點再把它複製成多份，這是一種策略。還有一種策略就是直接從客戶端分三份出來去做存儲，後面這種方式會佔用計算帶寬，所以我會根據 IO 的大小做不同的策略。不管怎樣，CBS使用帶寬是不佔用客戶購買雲主機的帶寬，也不會影響到客戶的雲主機使用。
Q：雲硬盤和對象存儲的差別是什麼？如果是把硬盤雲化，請問是支持多少種文件系統格式？
A： 雲硬盤相對比較「熱」，也就是延時比較敏感。雲硬盤和本地的物理硬盤其實是一樣的，你就跟普通物理硬盤一樣用它就行了，可以根據需要格式化爲自己需要的文件系統
Q：很多時候，網絡 rtt 有十幾 ms，雲硬盤延遲會很高？
A： 騰訊雲的網絡沒有這麼差，應該是在百微秒級別。
Q：老師，請問大IO/小IO的分界點是多少？
A：這個大小判定方式是不一樣，客戶端是 4K，存儲集羣內部 IO 是 32K。
Q：存量的雲主機支持極速型雲盤嗎？
A： 極速型雲盤目前公測中，如果有需要，可以官網頁面提交申請，會有專人聯繫，感謝！
Q：雲硬盤能實現一盤多機掛載嗎？多機同時操作，怎麼保障一致性？
A： 支持。雲硬盤是塊存儲，塊存儲級別不能保障讀寫衝突的一致性問題。需要文件系統或應用層面保證，所以適用於oracle rac這些已經實現分佈式鎖的場景。
作者介紹：
王銀虎，騰訊雲存儲專家工程師
王銀虎，騰訊雲存儲專家工程師，2010年加入騰訊，帶領團隊建設騰訊存儲平臺，主導騰訊EB級存儲平臺發展。十餘年一直深耕存儲領域，從硬件到軟件、從內核到應用開發、從單機存儲到分佈式，全維度多角度深入一線。目前負責騰訊彈性塊存儲平臺、騰訊雲硬盤的設計和研發工作。個人精於海量存儲技術的研究，旨在支持騰訊低成本、高性能、高可靠的EB級雲存儲服務。
本文轉載自公衆號雲加社區（ID：QcloudCommunity）。
原文鏈接：