这是一个创建于 2022 天前的主题，其中的信息可能已经有所发展或是发生改变。
 |
1
yuikns 2019-04-24 02:01:46 +08:00  1
抛个砖...
多 consumers 场景需要多个 partition，默认的貌似是 1 ？这样同时只有 1 个能访问。 |
 |
2
Universe 2019-04-24 07:30:03 +08:00 via Android 1
java Producer 发送数据调用 send 方法是异步的，会返回一个 Future 类，在到达 linger.ms 时间或 batch.size 大小时才会推送，如果程序挂掉会导致掉数据，在要求强一致性的场景中最好在 send 后再调用 flush 或者调用返回 Future 的 get 方法，确保数据发送出去后再提交 consumer 的 offset
|
 |
3
Tinet 2019-04-24 08:46:48 +08:00 1
kafka 跑在以 glusterfs 为 k8s pv backend 的集群中时，写数据之后如果马上读可能会读不到数据。glusterfs 的缓存机制引起的
|
 |
4
sigmapi 2019-04-24 09:26:20 +08:00 1
低版本(0.9) 在网络波动时可能会踢出 consumer，恢复后 consumer 拒绝连接 coordinator 导致再也消费不了，改 groupid 重启 consumer 才能解决
不确定新版本是否修复，因为我们一直没升级（说多了都是泪） |
 |
5
ReysC 2019-04-24 10:15:03 +08:00 1
硬盘要快要大，内存要大，大概是预计 2 ～ 4 倍以上。
其他 kafka 都做的很好，没发现什么问题。 除了：跑了一年过后，我换了 NSQ~ |
 |
6
troywinter 2019-04-24 13:57:43 +08:00 1
之前在某短视频独角兽工作，公司主要以 Kafka 为主，qps 峰值超过 1 亿，没有遇到什么大问题，做合理的分区和容量预估就可以，另外就是 Kafka 在单台机器上如果 partition 过多会使得随机读写变得很严重，所以这块还是要机器配置超高和控制 topic 和 partition 分布在一台机器上的数量，过多的话性能会下降比较严重；其它的问题诸如 consumer group rebalance 问题其实基本都是常识，总体来说基本没出过丢消息之类的问题。
|
 |
7
llbgurs 2019-04-25 08:09:45 +08:00
推荐 https://book.douban.com/subject/27665114/ ，讲了很多干货
|
 |
8
JohnSmith 2019-04-25 08:19:38 +08:00 via iPhone 1
有丢数据的风险
|
 |
9
andrewrong 2019-04-25 09:41:36 +08:00 1
1. 一定要做上下游的血缘管理，不然后期想删除一个 topic 的难度很大；
2. topic 和 partition 的个数一定要合理，太多性能会下降很厉害；除了磁盘的随机写还有 master-slave 的同步延迟也会比较的很高 3. 的确有丢数据的风险；除了上面人说的异步 producer 的问题，还有就是 kafka 的同步机制； ISR 的方式就算你的 ack=all 也不能完全保证你的数据写了所有的副本，通常还需要配置一个最小 ISR 的副本个数； 4. 上面有人说一个副本只能被一个 consumer 消费，这个问题的话，其实也可以通过其他的方式来处理，那就是用低级 API，offset 自己管理来做这块的操作，速度会很快，但是通常会导致 kafka 的 io 抖动比较厉害 5. 最后，kafka 真的还是一个非常不错的产品； |
Select Language