1. 對於fabric中的每個通道。
orderer 將其對映到 kafka叢集中的一個 topic ，即一個通道對應一個 topic。每個 topic 只建立一個分割槽（partion）. 因為訊息在單個分割槽裡面是有序的，這樣就保證了交易的順序。
2 .OSN：orderer service node
主要功能: 1. client 端認證 2.允許 client 的 SDK 和 channel 進行互動 3.過濾並且驗證 configure transactions
3. ttc-x time to cut
關於結塊操作：
為了提高 OSN 的效率，將kakfa的交易資料按照批次出塊，這樣可以減少驗證次數，減少簽名(因為簽名比較費時)。
所以引入了 batch 機制，即設定一個 batchSize 引數，一旦交易數達到閾值，就會進行切塊操作。
但是按照 數量出塊，又會帶來新的問題：因為出塊是非同步的，假設設定 batchSize=1000，orderering 需要發出1000個交易的batch，現在已經有了999個交易儲存在記憶體中，只需要等待一個交易就可以生成新的區塊，但是沒有交易發往orderering了，這時候前面的999個交易就被動延遲了。這是不可接受的。
為了解決這個問題，引入了出塊時間 batchTimeout,即用另外一個維度-時間去觸發切塊操作。這樣既超時或者達到批次上限都會觸發結塊操作。
因為不同的 OSN 之間都是通過kakfa叢集獲取資料，並沒有直接的關聯，而且OSN之間效能不一樣，所以OSN的出塊的時間很難一致。最終也會導致出塊所包含的交易不一致，這也是不可以接受的。
所以引入了 ttc-x 的概念，各個OSN之間到了切塊的時間，都會往kafka 叢集中對應的 topic 發出一個 ttc-x 的訊息，ttc-x 也屬於kafka中的訊息，這個訊息也會和其他正常的交易資訊放到同一個分割槽裡，所以ttc-x和其他的訊息都是有序的。
每個OSN切塊的操作都以第一個讀取到的 ttc-x 為準，進行出塊操作，後續重複的 ttc-x 訊息都忽略掉，這樣就達到了出塊的高度和區塊裡的交易數一致。
只是每個OSN 效能不一樣，出塊的時間不一樣而已。
4.賬本檔案的儲存地址
進入對應的 orderer.example.com 的docker容器： docker exec -it orderer.example.com bash
cd 到 /var/hyperledger/production/orderer/chains
即可以看到 blockfile_xxxxxx格式的檔案。
本作品採用《CC 協議》，轉載必須註明作者和本文連結