为什么需要关心topic的配置
这些参数会影响topic的性能和行为。
常见的参数配置
1 、partition count
一开始就要设置好partition的个数，不要在后面动态的增加partition，否则会破坏key和partition配置的对应关系。
粗略统计，每增加一个partition会给系统增加10MB/sec的吞吐量。
更多的partition意味着；
- 更好的并行性和吞吐量
- BUT 系统需要打开更多的文件
- BUT 如果一个broker挂掉，而这个broker有好多文件，需要选出新的leader broker系统才能重新工作，而过多的文件会造成延迟
- BUT 会造成更多的replicate延迟操作
建议个数：
- 一个broker里面partition的个数在2000～4000之间
- partition个数小于20000
- 每个topic的partition个数 = （1 to 2) * (# of brokers), max 10 partitions
- 例如有3个brokers, 最好设置3～6个partitions
2、replication count
增加replication factor个数，会消耗更多的磁盘空间，也会对集群造成很大的压力。
更多的RF意味着；
- 系统更强的健壮性，可以容忍N-1个broker挂掉
- BUT 更长的replication(当设置acks=all的时候，需要得到所有的broker相应)】
- BUT 更多的磁盘空间(50% more if RF is 3 instead of 2)
建议个数：3个broker
3、partitions and segments
单个partition是由segment组成的，每个segment都对应一个文件。每个segment都有一个开始和结束的位置（字节为单位的offset），对于同一个partition来说，同一时间只有唯一一个active segment，也就是说数据会被追加到active segment里面。
log.segment.bytes: the max size of a single segment in bytes
log.segment.ms: the Kafka will wait before committing the segment if not full
以上图为例，每一个segment的大小是958字节，当数据写满958个字节后，对应的segment就会关闭，再创建一个新的segment。
对于每一个segment来说，都有两个index（文件）：
an offset to position index（空间）：通过位置去定位信息
a timestamp to offset index（时间）：通过时间戳定位信息
这两个索引文件是伴随着segment存储在kafka中的
默认情况下log.segment.bytes = 1GB，设置过小会有什么影响
- 每个partition会有更多的segment
- 更多的log compaction事件
- BUT 需要打开太多的文件
实际开发中需要关心一下吞吐量，如果是3GB，就可以使用默认参数。
默认情况下log.segment.ms = 1 week，设置过小会有什么影响
- 产生更多的log compaction
4、Log Cleanup Policy
可以删除不需要的数据，维护kafka cluster的成本更低，同时有更高的性能。
log cleanup发生在partitions segment上面！
每当partition创建一个segment后，都会触发一个潜在的log cleanup需求，因此，如果segment比较小，就会有更多的log cleanup需求。
默认情况下，segment是1GB。
policy 1 ：log.cleanup.policy = delete
- 有最大有效时间，一般默认保存一周；
- 有最大容量，默认无限大。
policy 2 ：log.cleanup.policy = compact
- 根据key来删除数据；
- 如果有相同的key就会删除之前相同key的value；
- 不会限制存储时间和数据大小。
相当于是快照数据。
其它参数
- max.message.bytes
默认1MB，可以发送给topic的单个message的大小，如果修改需要同步修改consumer侧的参数值。 - min.isync.replicas
默认是1，最少的需要的replica的响应数量。 - unclean.leader.election
默认是true, 是否允许位做完数据同步的replica作为leader broker。
