# Copyright IBM Corp. All Rights Reserved.
#
# SPDX-License-Identifier: Apache-2.0
#
# 我們使用K和Z分别代表Kafka叢集和ZooKeeper叢集的節點個數
#
# 1）K的最小值應該被設定為4（我們将會在第4步中解釋，這是為了滿足crash容錯的最小節點數。
# 如果有4個代理，那麼可以容錯一個代理崩潰，一個代理停止服務後，channel仍然可以繼續讀寫，新的channel可以被建立）
# 2）Z可以為3,5或是7。它的值需要是一個奇數避免腦裂（split-brain）情況，同時選擇大于1的值為了避免單點故障。
# 超過7個ZooKeeper servers會被認為overkill。
#
version: '2'
services:
kafka1:
container_name: kafka1
hostname: kafka1
image: hyperledger/fabric-kafka
restart: always
environment:
# ========================================================================
# Reference: https://kafka.apache.org/documentation/#configuration
# ========================================================================
#
# broker.id
- KAFKA_BROKER_ID=1
#
# min.insync.replicas
# Let the value of this setting be M. Data is considered committed when
# it is written to at least M replicas (which are then considered in-sync
# and belong to the in-sync replica set, or ISR). In any other case, the
# write operation returns an error. Then:
# 1. If up to M-N replicas -- out of the N (see default.replication.factor
# below) that the channel data is written to -- become unavailable,
# operations proceed normally.
# 2. If more replicas become unavailable, Kafka cannot maintain an ISR set
# of M, so it stops accepting writes. Reads work without issues. The
# channel becomes writeable again when M replicas get in-sync.
#
# min.insync.replicas = M---設定一個M值（例如1<M<N，檢視下面的default.replication.factor）
# 資料送出時會寫入至少M個副本（這些資料然後會被同步并且歸屬到in-sync 副本集合或ISR）。
# 其它情況，寫入操作會傳回一個錯誤。接下來：
# 1）如果channel寫入的資料多達N-M個副本變的不可用，操作可以正常執行。
# 2）如果有更多的副本不可用，Kafka不可以維護一個有M數量的ISR集合，是以Kafka停止接收寫操作。Channel隻有當同步M個副本後才可以重新可以寫。
- KAFKA_MIN_INSYNC_REPLICAS=2
#
# default.replication.factor
# Let the value of this setting be N. A replication factor of N means that
# each channel will have its data replicated to N brokers. These are the
# candidates for the ISR set of a channel. As we noted in the
# min.insync.replicas section above, not all of these brokers have to be
# available all the time. In this sample configuration we choose a
# default.replication.factor of K-1 (where K is the total number of brokers in
# our Kafka cluster) so as to have the largest possible candidate set for
# a channel's ISR. We explicitly avoid setting N equal to K because
# channel creations cannot go forward if less than N brokers are up. If N
# were set equal to K, a single broker going down would mean that we would
# not be able to create new channels, i.e. the crash fault tolerance of
# the ordering service would be non-existent.
#
# 設定一個值N，N<K。
# 設定replication factor參數為N代表着每個channel都儲存N個副本的資料到Kafka的代理上。
# 這些都是一個channel的ISR集合的候選。
# 如同在上邊min.insync.replicas section設定部分所描述的，不是所有的代理（orderer）在任何時候都是可用的。
# N的值必須小于K，如果少于N個代理的話，channel的建立是不能成功的。
# 是以，如果設定N的值為K，一個代理失效後，那麼區塊鍊網絡将不能再建立新的channel---orderering service的crash容錯也就不存在了。
- KAFKA_DEFAULT_REPLICATION_FACTOR=3
#
# zookeper.connect
# Point to the set of Zookeeper nodes comprising a ZK ensemble.
# 指向Zookeeper節點的集合，其中包含ZK的集合。
- KAFKA_ZOOKEEPER_CONNECT=zookeeper1:2181,zookeeper2:2181,zookeeper3:2181
#
# zookeeper.connection.timeout.ms
# The max time that the client waits to establish a connection to
# Zookeeper. If not set, the value in zookeeper.session.timeout.ms (below)
# is used.
#- KAFKA_ZOOKEEPER_CONNECTION_TIMEOUT_MS = 6000
#
# zookeeper.session.timeout.ms
#- KAFKA_ZOOKEEPER_SESSION_TIMEOUT_MS = 6000
#
# socket.request.max.bytes
# The maximum number of bytes in a socket request. ATTN: If you set this
# env var, make sure to update `brokerConfig.Producer.MaxMessageBytes` in
# `newBrokerConfig()` in `fabric/orderer/kafka/config.go` accordingly.
#- KAFKA_SOCKET_REQUEST_MAX_BYTES=104857600 # 100 * 1024 * 1024 B
#
# message.max.bytes
# The maximum size of envelope that the broker can receive.
#
# 在configtx.yaml中會設定最大的區塊大小（參考configtx.yaml中AbsoluteMaxBytes參數）。
# 每個區塊最大有Orderer.AbsoluteMaxBytes個位元組（不包括頭部），假定這裡設定的值為A（目前99）。
# message.max.bytes和replica.fetch.max.bytes應該設定一個大于A。
# 為header增加一些緩沖區空間---1MB已經足夠大。上述不同設定值之間滿足如下關系：
# Orderer.AbsoluteMaxBytes < replica.fetch.max.bytes <= message.max.bytes
# （更完整的是，message.max.bytes應該嚴格小于socket.request.max.bytes的值，socket.request.max.bytes的值預設被設定為100MB。
# 如果想要區塊的大小大于100MB，需要編輯fabric/orderer/kafka/config.go檔案裡寫死的值brokerConfig.Producer.MaxMessageBytes，
# 修改後重新編譯源碼得到二進制檔案，這種設定是不建議的。）
- KAFKA_MESSAGE_MAX_BYTES=103809024 # 99 * 1024 * 1024 B
#
# replica.fetch.max.bytes
# The number of bytes of messages to attempt to fetch for each channel.
# This is not an absolute maximum, if the fetched envelope is larger than
# this value, the envelope will still be returned to ensure that progress
# can be made. The maximum message size accepted by the broker is defined
# via message.max.bytes above.
#
# 試圖為每個通道擷取的消息的位元組數。
# 這不是絕對最大值，如果擷取的資訊大于這個值，則仍然會傳回資訊，以確定可以取得進展。
# 代理所接受的最大消息大小是通過上一條message.max.bytes定義的。
- KAFKA_REPLICA_FETCH_MAX_BYTES=103809024 # 99 * 1024 * 1024 B
#
# unclean.leader.election.enable
# Data consistency is key in a blockchain environment. We cannot have a
# leader chosen outside of the in-sync replica set, or we run the risk of
# overwriting the offsets that the previous leader produced, and --as a
# result-- rewriting the blockchain that the orderers produce.
# 資料一緻性在區塊鍊環境中是至關重要的。
# 我們不能從in-sync 副本（ISR）集合之外選取channel leader，
# 否則我們将會面臨對于之前的leader産生的offsets覆寫的風險，
# 這樣的結果是，orderers産生的區塊可能會重新寫入區塊鍊。
- KAFKA_UNCLEAN_LEADER_ELECTION_ENABLE=false
#
# log.retention.ms
# Until the ordering service in Fabric adds support for pruning of the
# Kafka logs, time-based retention should be disabled so as to prevent
# segments from expiring. (Size-based retention -- see
# log.retention.bytes -- is disabled by default so there is no need to set
# it explicitly.)
#
# 除非orderering service對Kafka日志的修剪增加支援，
# 否則需要關閉基于時間的日志保留方式并且避免分段到期
# （基于大小的日志保留方式log.retention.bytes在寫本文章時在Kafka中已經預設關閉，是以不需要再次明确設定這個配置）。
- KAFKA_LOG_RETENTION_MS=-1
- KAFKA_HEAP_OPTS=-Xmx256M -Xms128M
ports:
- "9092:9092"
extra_hosts:
- "zookeeper1:172.31.159.137"
- "zookeeper2:172.31.159.135"
- "zookeeper3:172.31.159.136"
- "kafka1:172.31.159.133"
- "kafka2:172.31.159.132"
- "kafka3:172.31.159.134"
- "kafka4:172.31.159.131"
docker-kafka2.yaml 檔案内容和解釋如下：
# Copyright IBM Corp. All Rights Reserved.
#
# SPDX-License-Identifier: Apache-2.0
#
# 我們使用K和Z分别代表Kafka叢集和ZooKeeper叢集的節點個數
#
# 1）K的最小值應該被設定為4（我們将會在第4步中解釋，這是為了滿足crash容錯的最小節點數。
# 如果有4個代理，那麼可以容錯一個代理崩潰，一個代理停止服務後，channel仍然可以繼續讀寫，新的channel可以被建立）
# 2）Z可以為3,5或是7。它的值需要是一個奇數避免腦裂（split-brain）情況，同時選擇大于1的值為了避免單點故障。
# 超過7個ZooKeeper servers會被認為overkill。
#
version: '2'
services:
kafka2:
container_name: kafka2
hostname: kafka2
image: hyperledger/fabric-kafka
restart: always
environment:
# ========================================================================
# Reference: https://kafka.apache.org/documentation/#configuration
# ========================================================================
#
# broker.id
- KAFKA_BROKER_ID=2
#
# min.insync.replicas
# Let the value of this setting be M. Data is considered committed when
# it is written to at least M replicas (which are then considered in-sync
# and belong to the in-sync replica set, or ISR). In any other case, the
# write operation returns an error. Then:
# 1. If up to M-N replicas -- out of the N (see default.replication.factor
# below) that the channel data is written to -- become unavailable,
# operations proceed normally.
# 2. If more replicas become unavailable, Kafka cannot maintain an ISR set
# of M, so it stops accepting writes. Reads work without issues. The
# channel becomes writeable again when M replicas get in-sync.
#
# min.insync.replicas = M---設定一個M值（例如1<M<N，檢視下面的default.replication.factor）
# 資料送出時會寫入至少M個副本（這些資料然後會被同步并且歸屬到in-sync 副本集合或ISR）。
# 其它情況，寫入操作會傳回一個錯誤。接下來：
# 1）如果channel寫入的資料多達N-M個副本變的不可用，操作可以正常執行。
# 2）如果有更多的副本不可用，Kafka不可以維護一個有M數量的ISR集合，是以Kafka停止接收寫操作。Channel隻有當同步M個副本後才可以重新可以寫。
- KAFKA_MIN_INSYNC_REPLICAS=2
#
# default.replication.factor
# Let the value of this setting be N. A replication factor of N means that
# each channel will have its data replicated to N brokers. These are the
# candidates for the ISR set of a channel. As we noted in the
# min.insync.replicas section above, not all of these brokers have to be
# available all the time. In this sample configuration we choose a
# default.replication.factor of K-1 (where K is the total number of brokers in
# our Kafka cluster) so as to have the largest possible candidate set for
# a channel's ISR. We explicitly avoid setting N equal to K because
# channel creations cannot go forward if less than N brokers are up. If N
# were set equal to K, a single broker going down would mean that we would
# not be able to create new channels, i.e. the crash fault tolerance of
# the ordering service would be non-existent.
#
# 設定一個值N，N<K。
# 設定replication factor參數為N代表着每個channel都儲存N個副本的資料到Kafka的代理上。
# 這些都是一個channel的ISR集合的候選。
# 如同在上邊min.insync.replicas section設定部分所描述的，不是所有的代理（orderer）在任何時候都是可用的。
# N的值必須小于K，如果少于N個代理的話，channel的建立是不能成功的。
# 是以，如果設定N的值為K，一個代理失效後，那麼區塊鍊網絡将不能再建立新的channel---orderering service的crash容錯也就不存在了。
- KAFKA_DEFAULT_REPLICATION_FACTOR=3
#
# zookeper.connect
# Point to the set of Zookeeper nodes comprising a ZK ensemble.
# 指向Zookeeper節點的集合，其中包含ZK的集合。
- KAFKA_ZOOKEEPER_CONNECT=zookeeper1:2181,zookeeper2:2181,zookeeper3:2181
#
# zookeeper.connection.timeout.ms
# The max time that the client waits to establish a connection to
# Zookeeper. If not set, the value in zookeeper.session.timeout.ms (below)
# is used.
#- KAFKA_ZOOKEEPER_CONNECTION_TIMEOUT_MS = 6000
#
# zookeeper.session.timeout.ms
#- KAFKA_ZOOKEEPER_SESSION_TIMEOUT_MS = 6000
#
# socket.request.max.bytes
# The maximum number of bytes in a socket request. ATTN: If you set this
# env var, make sure to update `brokerConfig.Producer.MaxMessageBytes` in
# `newBrokerConfig()` in `fabric/orderer/kafka/config.go` accordingly.
#- KAFKA_SOCKET_REQUEST_MAX_BYTES=104857600 # 100 * 1024 * 1024 B
#
# message.max.bytes
# The maximum size of envelope that the broker can receive.
#
# 在configtx.yaml中會設定最大的區塊大小（參考configtx.yaml中AbsoluteMaxBytes參數）。
# 每個區塊最大有Orderer.AbsoluteMaxBytes個位元組（不包括頭部），假定這裡設定的值為A（目前99）。
# message.max.bytes和replica.fetch.max.bytes應該設定一個大于A。
# 為header增加一些緩沖區空間---1MB已經足夠大。上述不同設定值之間滿足如下關系：
# Orderer.AbsoluteMaxBytes < replica.fetch.max.bytes <= message.max.bytes
# （更完整的是，message.max.bytes應該嚴格小于socket.request.max.bytes的值，socket.request.max.bytes的值預設被設定為100MB。
# 如果想要區塊的大小大于100MB，需要編輯fabric/orderer/kafka/config.go檔案裡寫死的值brokerConfig.Producer.MaxMessageBytes，
# 修改後重新編譯源碼得到二進制檔案，這種設定是不建議的。）
- KAFKA_MESSAGE_MAX_BYTES=103809024 # 99 * 1024 * 1024 B
#
# replica.fetch.max.bytes
# The number of bytes of messages to attempt to fetch for each channel.
# This is not an absolute maximum, if the fetched envelope is larger than
# this value, the envelope will still be returned to ensure that progress
# can be made. The maximum message size accepted by the broker is defined
# via message.max.bytes above.
#
# 試圖為每個通道擷取的消息的位元組數。
# 這不是絕對最大值，如果擷取的資訊大于這個值，則仍然會傳回資訊，以確定可以取得進展。
# 代理所接受的最大消息大小是通過上一條message.max.bytes定義的。
- KAFKA_REPLICA_FETCH_MAX_BYTES=103809024 # 99 * 1024 * 1024 B
#
# unclean.leader.election.enable
# Data consistency is key in a blockchain environment. We cannot have a
# leader chosen outside of the in-sync replica set, or we run the risk of
# overwriting the offsets that the previous leader produced, and --as a
# result-- rewriting the blockchain that the orderers produce.
# 資料一緻性在區塊鍊環境中是至關重要的。
# 我們不能從in-sync 副本（ISR）集合之外選取channel leader，
# 否則我們将會面臨對于之前的leader産生的offsets覆寫的風險，
# 這樣的結果是，orderers産生的區塊可能會重新寫入區塊鍊。
- KAFKA_UNCLEAN_LEADER_ELECTION_ENABLE=false
#
# log.retention.ms
# Until the ordering service in Fabric adds support for pruning of the
# Kafka logs, time-based retention should be disabled so as to prevent
# segments from expiring. (Size-based retention -- see
# log.retention.bytes -- is disabled by default so there is no need to set
# it explicitly.)
#
# 除非orderering service對Kafka日志的修剪增加支援，
# 否則需要關閉基于時間的日志保留方式并且避免分段到期
# （基于大小的日志保留方式log.retention.bytes在寫本文章時在Kafka中已經預設關閉，是以不需要再次明确設定這個配置）。
- KAFKA_LOG_RETENTION_MS=-1
- KAFKA_HEAP_OPTS=-Xmx256M -Xms128M
ports:
- "9092:9092"
extra_hosts:
- "zookeeper1:172.31.159.137"
- "zookeeper2:172.31.159.135"
- "zookeeper3:172.31.159.136"
- "kafka1:172.31.159.133"
- "kafka2:172.31.159.132"
- "kafka3:172.31.159.134"
- "kafka4:172.31.159.131"
docker-kafka3.yaml 檔案内容和解釋如下：
# Copyright IBM Corp. All Rights Reserved.
#
# SPDX-License-Identifier: Apache-2.0
#
# 我們使用K和Z分别代表Kafka叢集和ZooKeeper叢集的節點個數
#
# 1）K的最小值應該被設定為4（我們将會在第4步中解釋，這是為了滿足crash容錯的最小節點數。
# 如果有4個代理，那麼可以容錯一個代理崩潰，一個代理停止服務後，channel仍然可以繼續讀寫，新的channel可以被建立）
# 2）Z可以為3,5或是7。它的值需要是一個奇數避免腦裂（split-brain）情況，同時選擇大于1的值為了避免單點故障。
# 超過7個ZooKeeper servers會被認為overkill。
#
version: '2'
services:
kafka3:
container_name: kafka3
hostname: kafka3
image: hyperledger/fabric-kafka
restart: always
environment:
# ========================================================================
# Reference: https://kafka.apache.org/documentation/#configuration
# ========================================================================
#
# broker.id
- KAFKA_BROKER_ID=3
#
# min.insync.replicas
# Let the value of this setting be M. Data is considered committed when
# it is written to at least M replicas (which are then considered in-sync
# and belong to the in-sync replica set, or ISR). In any other case, the
# write operation returns an error. Then:
# 1. If up to M-N replicas -- out of the N (see default.replication.factor
# below) that the channel data is written to -- become unavailable,
# operations proceed normally.
# 2. If more replicas become unavailable, Kafka cannot maintain an ISR set
# of M, so it stops accepting writes. Reads work without issues. The
# channel becomes writeable again when M replicas get in-sync.
#
# min.insync.replicas = M---設定一個M值（例如1<M<N，檢視下面的default.replication.factor）
# 資料送出時會寫入至少M個副本（這些資料然後會被同步并且歸屬到in-sync 副本集合或ISR）。
# 其它情況，寫入操作會傳回一個錯誤。接下來：
# 1）如果channel寫入的資料多達N-M個副本變的不可用，操作可以正常執行。
# 2）如果有更多的副本不可用，Kafka不可以維護一個有M數量的ISR集合，是以Kafka停止接收寫操作。Channel隻有當同步M個副本後才可以重新可以寫。
- KAFKA_MIN_INSYNC_REPLICAS=2
#
# default.replication.factor
# Let the value of this setting be N. A replication factor of N means that
# each channel will have its data replicated to N brokers. These are the
# candidates for the ISR set of a channel. As we noted in the
# min.insync.replicas section above, not all of these brokers have to be
# available all the time. In this sample configuration we choose a
# default.replication.factor of K-1 (where K is the total number of brokers in
# our Kafka cluster) so as to have the largest possible candidate set for
# a channel's ISR. We explicitly avoid setting N equal to K because
# channel creations cannot go forward if less than N brokers are up. If N
# were set equal to K, a single broker going down would mean that we would
# not be able to create new channels, i.e. the crash fault tolerance of
# the ordering service would be non-existent.
#
# 設定一個值N，N<K。
# 設定replication factor參數為N代表着每個channel都儲存N個副本的資料到Kafka的代理上。
# 這些都是一個channel的ISR集合的候選。
# 如同在上邊min.insync.replicas section設定部分所描述的，不是所有的代理（orderer）在任何時候都是可用的。
# N的值必須小于K，如果少于N個代理的話，channel的建立是不能成功的。
# 是以，如果設定N的值為K，一個代理失效後，那麼區塊鍊網絡将不能再建立新的channel---orderering service的crash容錯也就不存在了。
- KAFKA_DEFAULT_REPLICATION_FACTOR=3
#
# zookeper.connect
# Point to the set of Zookeeper nodes comprising a ZK ensemble.
# 指向Zookeeper節點的集合，其中包含ZK的集合。
- KAFKA_ZOOKEEPER_CONNECT=zookeeper1:2181,zookeeper2:2181,zookeeper3:2181
#
# zookeeper.connection.timeout.ms
# The max time that the client waits to establish a connection to
# Zookeeper. If not set, the value in zookeeper.session.timeout.ms (below)
# is used.
#- KAFKA_ZOOKEEPER_CONNECTION_TIMEOUT_MS = 6000
#
# zookeeper.session.timeout.ms
#- KAFKA_ZOOKEEPER_SESSION_TIMEOUT_MS = 6000
#
# socket.request.max.bytes
# The maximum number of bytes in a socket request. ATTN: If you set this
# env var, make sure to update `brokerConfig.Producer.MaxMessageBytes` in
# `newBrokerConfig()` in `fabric/orderer/kafka/config.go` accordingly.
#- KAFKA_SOCKET_REQUEST_MAX_BYTES=104857600 # 100 * 1024 * 1024 B
#
# message.max.bytes
# The maximum size of envelope that the broker can receive.
#
# 在configtx.yaml中會設定最大的區塊大小（參考configtx.yaml中AbsoluteMaxBytes參數）。
# 每個區塊最大有Orderer.AbsoluteMaxBytes個位元組（不包括頭部），假定這裡設定的值為A（目前99）。
# message.max.bytes和replica.fetch.max.bytes應該設定一個大于A。
# 為header增加一些緩沖區空間---1MB已經足夠大。上述不同設定值之間滿足如下關系：
# Orderer.AbsoluteMaxBytes < replica.fetch.max.bytes <= message.max.bytes
# （更完整的是，message.max.bytes應該嚴格小于socket.request.max.bytes的值，socket.request.max.bytes的值預設被設定為100MB。
# 如果想要區塊的大小大于100MB，需要編輯fabric/orderer/kafka/config.go檔案裡寫死的值brokerConfig.Producer.MaxMessageBytes，
# 修改後重新編譯源碼得到二進制檔案，這種設定是不建議的。）
- KAFKA_MESSAGE_MAX_BYTES=103809024 # 99 * 1024 * 1024 B
#
# replica.fetch.max.bytes
# The number of bytes of messages to attempt to fetch for each channel.
# This is not an absolute maximum, if the fetched envelope is larger than
# this value, the envelope will still be returned to ensure that progress
# can be made. The maximum message size accepted by the broker is defined
# via message.max.bytes above.
#
# 試圖為每個通道擷取的消息的位元組數。
# 這不是絕對最大值，如果擷取的資訊大于這個值，則仍然會傳回資訊，以確定可以取得進展。
# 代理所接受的最大消息大小是通過上一條message.max.bytes定義的。
- KAFKA_REPLICA_FETCH_MAX_BYTES=103809024 # 99 * 1024 * 1024 B
#
# unclean.leader.election.enable
# Data consistency is key in a blockchain environment. We cannot have a
# leader chosen outside of the in-sync replica set, or we run the risk of
# overwriting the offsets that the previous leader produced, and --as a
# result-- rewriting the blockchain that the orderers produce.
# 資料一緻性在區塊鍊環境中是至關重要的。
# 我們不能從in-sync 副本（ISR）集合之外選取channel leader，
# 否則我們将會面臨對于之前的leader産生的offsets覆寫的風險，
# 這樣的結果是，orderers産生的區塊可能會重新寫入區塊鍊。
- KAFKA_UNCLEAN_LEADER_ELECTION_ENABLE=false
#
# log.retention.ms
# Until the ordering service in Fabric adds support for pruning of the
# Kafka logs, time-based retention should be disabled so as to prevent
# segments from expiring. (Size-based retention -- see
# log.retention.bytes -- is disabled by default so there is no need to set
# it explicitly.)
#
# 除非orderering service對Kafka日志的修剪增加支援，
# 否則需要關閉基于時間的日志保留方式并且避免分段到期
# （基于大小的日志保留方式log.retention.bytes在寫本文章時在Kafka中已經預設關閉，是以不需要再次明确設定這個配置）。
- KAFKA_LOG_RETENTION_MS=-1
- KAFKA_HEAP_OPTS=-Xmx256M -Xms128M
ports:
- "9092:9092"
extra_hosts:
- "zookeeper1:172.31.159.137"
- "zookeeper2:172.31.159.135"
- "zookeeper3:172.31.159.136"
- "kafka1:172.31.159.133"
- "kafka2:172.31.159.132"
- "kafka3:172.31.159.134"
- "kafka4:172.31.159.131"
docker-kafka4.yaml 檔案内容和解釋如下：
# Copyright IBM Corp. All Rights Reserved.
#
# SPDX-License-Identifier: Apache-2.0
#
# 我們使用K和Z分别代表Kafka叢集和ZooKeeper叢集的節點個數
#
# 1）K的最小值應該被設定為4（我們将會在第4步中解釋，這是為了滿足crash容錯的最小節點數。
# 如果有4個代理，那麼可以容錯一個代理崩潰，一個代理停止服務後，channel仍然可以繼續讀寫，新的channel可以被建立）
# 2）Z可以為3,5或是7。它的值需要是一個奇數避免腦裂（split-brain）情況，同時選擇大于1的值為了避免單點故障。
# 超過7個ZooKeeper servers會被認為overkill。
#
version: '2'
services:
kafka4:
container_name: kafka4
hostname: kafka4
image: hyperledger/fabric-kafka
restart: always
environment:
# ========================================================================
# Reference: https://kafka.apache.org/documentation/#configuration
# ========================================================================
#
# broker.id
- KAFKA_BROKER_ID=4
#
# min.insync.replicas
# Let the value of this setting be M. Data is considered committed when
# it is written to at least M replicas (which are then considered in-sync
# and belong to the in-sync replica set, or ISR). In any other case, the
# write operation returns an error. Then:
# 1. If up to M-N replicas -- out of the N (see default.replication.factor
# below) that the channel data is written to -- become unavailable,
# operations proceed normally.
# 2. If more replicas become unavailable, Kafka cannot maintain an ISR set
# of M, so it stops accepting writes. Reads work without issues. The
# channel becomes writeable again when M replicas get in-sync.
#
# min.insync.replicas = M---設定一個M值（例如1<M<N，檢視下面的default.replication.factor）
# 資料送出時會寫入至少M個副本（這些資料然後會被同步并且歸屬到in-sync 副本集合或ISR）。
# 其它情況，寫入操作會傳回一個錯誤。接下來：
# 1）如果channel寫入的資料多達N-M個副本變的不可用，操作可以正常執行。
# 2）如果有更多的副本不可用，Kafka不可以維護一個有M數量的ISR集合，是以Kafka停止接收寫操作。Channel隻有當同步M個副本後才可以重新可以寫。
- KAFKA_MIN_INSYNC_REPLICAS=2
#
# default.replication.factor
# Let the value of this setting be N. A replication factor of N means that
# each channel will have its data replicated to N brokers. These are the
# candidates for the ISR set of a channel. As we noted in the
# min.insync.replicas section above, not all of these brokers have to be
# available all the time. In this sample configuration we choose a
# default.replication.factor of K-1 (where K is the total number of brokers in
# our Kafka cluster) so as to have the largest possible candidate set for
# a channel's ISR. We explicitly avoid setting N equal to K because
# channel creations cannot go forward if less than N brokers are up. If N
# were set equal to K, a single broker going down would mean that we would
# not be able to create new channels, i.e. the crash fault tolerance of
# the ordering service would be non-existent.
#
# 設定一個值N，N<K。
# 設定replication factor參數為N代表着每個channel都儲存N個副本的資料到Kafka的代理上。
# 這些都是一個channel的ISR集合的候選。
# 如同在上邊min.insync.replicas section設定部分所描述的，不是所有的代理（orderer）在任何時候都是可用的。
# N的值必須小于K，如果少于N個代理的話，channel的建立是不能成功的。
# 是以，如果設定N的值為K，一個代理失效後，那麼區塊鍊網絡将不能再建立新的channel---orderering service的crash容錯也就不存在了。
- KAFKA_DEFAULT_REPLICATION_FACTOR=3
#
# zookeper.connect
# Point to the set of Zookeeper nodes comprising a ZK ensemble.
# 指向Zookeeper節點的集合，其中包含ZK的集合。
- KAFKA_ZOOKEEPER_CONNECT=zookeeper1:2181,zookeeper2:2181,zookeeper3:2181
#
# zookeeper.connection.timeout.ms
# The max time that the client waits to establish a connection to
# Zookeeper. If not set, the value in zookeeper.session.timeout.ms (below)
# is used.
#- KAFKA_ZOOKEEPER_CONNECTION_TIMEOUT_MS = 6000
#
# zookeeper.session.timeout.ms
#- KAFKA_ZOOKEEPER_SESSION_TIMEOUT_MS = 6000
#
# socket.request.max.bytes
# The maximum number of bytes in a socket request. ATTN: If you set this
# env var, make sure to update `brokerConfig.Producer.MaxMessageBytes` in
# `newBrokerConfig()` in `fabric/orderer/kafka/config.go` accordingly.
#- KAFKA_SOCKET_REQUEST_MAX_BYTES=104857600 # 100 * 1024 * 1024 B
#
# message.max.bytes
# The maximum size of envelope that the broker can receive.
#
# 在configtx.yaml中會設定最大的區塊大小（參考configtx.yaml中AbsoluteMaxBytes參數）。
# 每個區塊最大有Orderer.AbsoluteMaxBytes個位元組（不包括頭部），假定這裡設定的值為A（目前99）。
# message.max.bytes和replica.fetch.max.bytes應該設定一個大于A。
# 為header增加一些緩沖區空間---1MB已經足夠大。上述不同設定值之間滿足如下關系：
# Orderer.AbsoluteMaxBytes < replica.fetch.max.bytes <= message.max.bytes
# （更完整的是，message.max.bytes應該嚴格小于socket.request.max.bytes的值，socket.request.max.bytes的值預設被設定為100MB。
# 如果想要區塊的大小大于100MB，需要編輯fabric/orderer/kafka/config.go檔案裡寫死的值brokerConfig.Producer.MaxMessageBytes，
# 修改後重新編譯源碼得到二進制檔案，這種設定是不建議的。）
- KAFKA_MESSAGE_MAX_BYTES=103809024 # 99 * 1024 * 1024 B
#
# replica.fetch.max.bytes
# The number of bytes of messages to attempt to fetch for each channel.
# This is not an absolute maximum, if the fetched envelope is larger than
# this value, the envelope will still be returned to ensure that progress
# can be made. The maximum message size accepted by the broker is defined
# via message.max.bytes above.
#
# 試圖為每個通道擷取的消息的位元組數。
# 這不是絕對最大值，如果擷取的資訊大于這個值，則仍然會傳回資訊，以確定可以取得進展。
# 代理所接受的最大消息大小是通過上一條message.max.bytes定義的。
- KAFKA_REPLICA_FETCH_MAX_BYTES=103809024 # 99 * 1024 * 1024 B
#
# unclean.leader.election.enable
# Data consistency is key in a blockchain environment. We cannot have a
# leader chosen outside of the in-sync replica set, or we run the risk of
# overwriting the offsets that the previous leader produced, and --as a
# result-- rewriting the blockchain that the orderers produce.
# 資料一緻性在區塊鍊環境中是至關重要的。
# 我們不能從in-sync 副本（ISR）集合之外選取channel leader，
# 否則我們将會面臨對于之前的leader産生的offsets覆寫的風險，
# 這樣的結果是，orderers産生的區塊可能會重新寫入區塊鍊。
- KAFKA_UNCLEAN_LEADER_ELECTION_ENABLE=false
#
# log.retention.ms
# Until the ordering service in Fabric adds support for pruning of the
# Kafka logs, time-based retention should be disabled so as to prevent
# segments from expiring. (Size-based retention -- see
# log.retention.bytes -- is disabled by default so there is no need to set
# it explicitly.)
#
# 除非orderering service對Kafka日志的修剪增加支援，
# 否則需要關閉基于時間的日志保留方式并且避免分段到期
# （基于大小的日志保留方式log.retention.bytes在寫本文章時在Kafka中已經預設關閉，是以不需要再次明确設定這個配置）。
- KAFKA_LOG_RETENTION_MS=-1
- KAFKA_HEAP_OPTS=-Xmx256M -Xms128M
ports:
- "9092:9092"
extra_hosts:
- "zookeeper1:172.31.159.137"
- "zookeeper2:172.31.159.135"
- "zookeeper3:172.31.159.136"
- "kafka1:172.31.159.133"
- "kafka2:172.31.159.132"
- "kafka3:172.31.159.134"
- "kafka4:172.31.159.131"
