理解Storm的內部消息緩衝機製

• Storm工作進程內部的通信（同一個Storm工作節點（主機）的線程之間）：LMAX Disruptor
• 工作進程之間的通信（通過網絡的工作節點（主機）之間）：ZeroMQ或者Netty
• 計算拓撲之間的通信：Storm並不原生支持，需要自己實現和維護，可以使用消息係統，比如：Kafka，RabbitMQ和數據庫等等。

圖片說明

在下一節討論具體細節前，我們先來看看如下這幅圖（參考原圖）：

詳細描述

現在我們對Storm的工作進程內部的消息機製有了一定了解，接下來可以深入討論細節了。

工作進程（Worker processes）

• “topology.receiver.buffer.size”參數是工作進程中的接收線程批量向執行線程的輸入隊列發送數據時的緩衝區內消息數的最大值（接收線程從網絡讀取消息），此參數如果設置過大可能會造成一些問題（心跳線程掛掉然後吞吐率直線下降），默認值是8條消息，設置的值必須是2的冪（N次方），這是為了兼容LMAX Disruptor組件。
  // 示例: 通過Java API配置 
Config conf = new Config(); 
conf.put(Config.TOPOLOGY_RECEIVER_BUFFER_SIZE, 16); // 默認值為8

  topology.receiver.buffer.size參數不是配置LMAX Disruptor隊列的大小，它是配置的一個ArrayList的長度，這個List用來作為輸入消息的緩衝，它不需要被多個線程訪問，它僅僅是工作進程所專有的，但是因為這個List的元素最終被用來填充基於Disruptor的隊列（執行器輸入對列），所以這個參數必須是2的冪，參考backtype.storm.messaging.loader.clj的launch-receive-thread!詳細信息。

• 使用“topology.transfer.buffer.size”參數配置的transfer緩衝區中的每一個元素實際上是一個tuple的列表，多個Executor中的消息發送線程將批量地把消息從outgoing發送到多個Executor共享的transfer緩衝區（Executor中包含用戶邏輯線程和消息發送線程），transfer緩衝區的大小默認是1024個元素。
  // 示例: 通過JavaAPI配置
conf.put(Config.TOPOLOGY_TRANSFER_BUFFER_SIZE, 32); // 默認值為1024

執行器（Executors）

• topology.executor.receive.buffer.size，該參數是執行器的輸入消息隊列的配置參數，隊列的每個元素是一個tuple列表，tuple被批量地加入到隊列元素中，此參數的默認配置是1024個元素，修改配置時的值必須是2的冪（適配於LMAX Disruptor）。
  // 示例: 通過Java API配置
conf.put(Config.TOPOLOGY_EXECUTOR_RECEIVE_BUFFER_SIZE, 16384); // 批量加入tuple; 默認值是1024
• topology.executor.send.buffer.size，該參數是執行器輸入消息隊列的配置參數，這個隊列的每個元素是一個單獨的tuple，默認值為1024，修改配置時的值必須是2的冪（適配於LMAX Disruptor）。
  // 示例: 通過Java API配置
conf.put(Config.TOPOLOGY_EXECUTOR_SEND_BUFFER_SIZE, 16384); // 單獨的tuple; 默認值是1024

更進一步

如何配置Storm的內部消息緩衝

如何配置Storm的parallelism（並行）參數（實際上就是配置集群中工作進程數，各個Spout和Bolt的實例數和線程數）

搞明白Storm的拓撲內部在做什麼

Sending Metrics From Storm to Graphite
Installing and Running Graphite via RPM and Supervisord

ooyala放在Github上的metrics_storm項目也是值得參考的（但我還沒有用過這個工具）。

性能優化的建議