1

1

抛个砖...
多 consumers 场景需要多个 partition，默认的貌似是 1 ？这样同时只有 1 个能访问。

2

1

java Producer 发送数据调用 send 方法是异步的，会返回一个 Future 类，在到达 linger.ms 时间或 batch.size 大小时才会推送，如果程序挂掉会导致掉数据，在要求强一致性的场景中最好在 send 后再调用 flush 或者调用返回 Future 的 get 方法，确保数据发送出去后再提交 consumer 的 offset

3

1

kafka 跑在以 glusterfs 为 k8s pv backend 的集群中时，写数据之后如果马上读可能会读不到数据。glusterfs 的缓存机制引起的

4

1

低版本(0.9) 在网络波动时可能会踢出 consumer，恢复后 consumer 拒绝连接 coordinator 导致再也消费不了，改 groupid 重启 consumer 才能解决
不确定新版本是否修复，因为我们一直没升级（说多了都是泪）

5

1

硬盘要快要大，内存要大，大概是预计 2 ～ 4 倍以上。
其他 kafka 都做的很好，没发现什么问题。
除了：跑了一年过后，我换了 NSQ~

6

1

之前在某短视频独角兽工作，公司主要以 Kafka 为主，qps 峰值超过 1 亿，没有遇到什么大问题，做合理的分区和容量预估就可以，另外就是 Kafka 在单台机器上如果 partition 过多会使得随机读写变得很严重，所以这块还是要机器配置超高和控制 topic 和 partition 分布在一台机器上的数量，过多的话性能会下降比较严重；其它的问题诸如 consumer group rebalance 问题其实基本都是常识，总体来说基本没出过丢消息之类的问题。

8

1

有丢数据的风险

9

1

1. 一定要做上下游的血缘管理，不然后期想删除一个 topic 的难度很大；
2. topic 和 partition 的个数一定要合理，太多性能会下降很厉害；除了磁盘的随机写还有 master-slave 的同步延迟也会比较的很高
3. 的确有丢数据的风险；除了上面人说的异步 producer 的问题，还有就是 kafka 的同步机制； ISR 的方式就算你的 ack=all 也不能完全保证你的数据写了所有的副本，通常还需要配置一个最小 ISR 的副本个数；
4. 上面有人说一个副本只能被一个 consumer 消费，这个问题的话，其实也可以通过其他的方式来处理，那就是用低级 API，offset 自己管理来做这块的操作，速度会很快，但是通常会导致 kafka 的 io 抖动比较厉害
5. 最后，kafka 真的还是一个非常不错的产品；