Issues Template

[crossoverJie]

在提交issue之前请回答以下问题，谢谢!

你使用的是哪个版本

预期结果

实际结果

重现结果的步骤

其他相关信息

[baikimi]

刚才了解决了 那这个呢
2017-08-29 11:14:28,079 DEBUG [org.apache.zookeeper.ClientCnxnSocketNIO] - Ignoring exception during shutdown output
java.nio.channels.ClosedChannelException
at sun.nio.ch.SocketChannelImpl.shutdownOutput(SocketChannelImpl.java:797)
at sun.nio.ch.SocketAdaptor.shutdownOutput(SocketAdaptor.java:407)
at org.apache.zookeeper.ClientCnxnSocketNIO.cleanup(ClientCnxnSocketNIO.java:207)
at org.apache.zookeeper.ClientCnxn$SendThread.cleanup(ClientCnxn.java:1185)
at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1110)
2017-08-29 11:14:29,182 INFO [org.apache.zookeeper.ClientCnxn] - Opening socket connection to server 192.168.0.188/192.168.0.188:2181. Will not attempt to authenticate using SASL (unknown error)
2017-08-29 11:14:50,184 WARN [org.apache.zookeeper.ClientCnxn] - Session 0x0 for server null, unexpected error, closing socket connection and attempting reconnect
java.net.ConnectException: Connection timed out: no further information
at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:717)
at org.apache.zookeeper.ClientCnxnSocketNIO.doTransport(ClientCnxnSocketNIO.java:361)
at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1081)
2017-08-29 11:14:50,184 DEBUG [org.apache.zookeeper.ClientCnxnSocketNIO] - Ignoring exception during shutdown input
java.nio.channels.ClosedChannelException

[crossoverJie]

@baikimi 请不要在该Issues回复，提Issues按照模板重新提交。

[baikimi]

方便加你QQ吗？
想向你学习，如果方便我QQ 946530182

[crossoverJie]

@baikimi 哥们真不是我说。。。请不要在该issue回复，这个仅仅作为模板显示作用。

有问题可以提Issues，或者是邮件都可以。

但在提问之前建议你看下 http://www.jianshu.com/p/60dd8e9cd12f 这样更加事半功倍。

[fanpei91]

如何用一句话激怒程序员？———— “方便加你QQ吗？我QQ 946530182”

[1156721874]

秒杀那个，kafka消费端要多台机器，消费一定要快，如果不快的话，由于你前边都是乐观锁，队列里边会有很多版本号一样的，这样就会有很多数据到了后期消费的时候，是失败的（当然你做了限流），然后我有个疑问是：我有多台机器去消费，比如ABC三台consumer，我用kafka的广播模式，同一条消息会被ABC得到消费，只有由于乐观锁的原因，消息在A创建了订单，在B和C都拒绝了，那这样其实ABC三台机器都是瓶颈（他们有必要不重复接受），如果我让1-26条消息，1-10让A消费，11-20让B消费，21-26让C消费，这样就得使用单播模式，，，单播模式可能就要指定分区生产和指定分区消费，这样的话扩展性不灵活，，，，楼主有没有什么方案？

[crossoverJie]

我用kafka的广播模式，同一条消息会被ABC得到消费，

如果是采取的消费组模式，同时 group.id 是一样的那肯定不会被 ABC 都取到消息，只会有一个消费者拿到消息。

[1156721874]

我用kafka的广播模式，同一条消息会被ABC得到消费，

如果是采取的消费组模式，同时 group.id 是一样的那肯定不会被 ABC 都取到消息，只会有一个消费者拿到消息。

那这样，得到消费机会的那台机器会一直得到消费机会，其他的2台一直得不到消费机会。多态部署也就失去意思了，，啊~~~~好矛盾~~~

[crossoverJie]

那这样，得到消费机会的那台机器会一直得到消费机会，其他的2台一直得不到消费机会。多态部署也就失去意思了，，啊~~~~好矛盾~~~

并不会啊，假设一个 Topic 有 4 个分区，启动了三个进程去消费这个 Topic 。

• A 进程启动了 2 个 Consumer 实例。
• B 进程 3 个 Consumer 实例。
• C 进程 3 个 Consumer 实例。

当三个进程都启动起来一定会出现有些进程能取到数据，有些不能。

但总共加起来一定是 4 个 Consumer 实例消费到数据，只是随机分配在三个进程中的。

假设现在是 A 进程和 B 进程中各有两个 Consumer 实例在消费数据（2+2=4 分区数）。

这时进程 C 宕机了，Kafka 就会自动选择 B 进程中那个空闲的 Consumer 去消费数据（也就是 Consumer 的 Rebalance）。

这样也就达到了多台部署的作用了：容错性，挂掉一台其他的 Consumer 还可以接着消费。

[1156721874]

那这样，得到消费机会的那台机器会一直得到消费机会，其他的2台一直得不到消费机会。多态部署也就失去意思了，，啊~~~~好矛盾~~~

并不会啊，假设一个 Topic 有 4 个分区，启动了三个进程去消费这个 Topic 。

• A 进程启动了 2 个 Consumer 实例。
• B 进程 3 个 Consumer 实例。
• C 进程 3 个 Consumer 实例。

当三个进程都启动起来一定会出现有些进程能取到数据，有些不能。

但总共加起来一定是 4 个 Consumer 实例消费到数据，只是随机分配在三个进程中的。

假设现在是 A 进程和 B 进程中各有两个 Consumer 实例在消费数据（2+2=4 分区数）。

这时进程 C 宕机了，Kafka 就会自动选择 B 进程中那个空闲的 Consumer 去消费数据（也就是 Consumer 的 Rebalance）。

这样也就达到了多台部署的作用了：容错性，挂掉一台其他的 Consumer 还可以接着消费。

我看了一下这张图 好像明白你说的什么意思了。http://kafka.apache.org/documentation/#intro_consumers
就拿这张图来说， 我是这样理解的：有26条消息，生产的时候，1-10可能去了p0,10-15可能去了p2，16-20可能去了p3,20-26可能去了p4（当然实际是随机放到某个分区），然后消费的时候，就像图片里边那样画的去消费，但是，比如说在p0里边的一条消息A，会被C1和C3收到，由于咱们的秒杀系统，一次购买只能生成一个订单，也就是说A要么在C1产生订单，要么在C3产生订单，那么在这种模式下（一个topic多了broker，一个topic多个分区，2个不同的groupid订阅了同一个topic），肯定要加分布式锁，A被C1消费了，C3不能再生成订单。

[crossoverJie]

@1156721874

是的，如果 Topic 有多个分区肯定得分布式锁才行。但这样加锁解锁后的效率也会降低。

所以我建议对于秒杀这样的场景 Topic 只需要一个分区即可，这样可以保证信息的顺序以及避免使用锁，直接将请求由并行变为串行。

不过这样吞吐量就会下降，但对于秒杀来说吞吐量本身就不高，我觉得是可以接受的。