SSM
SSM copied to clipboard
crossoverJie
Issues Template
刚才了解决了 那这个呢 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
@baikimi 哥们真不是我说。。。请不要在该issue回复，这个仅仅作为模板显示作用。
有问题可以提Issues，或者是邮件都可以。
但在提问之前建议你看下 http://www.jianshu.com/p/60dd8e9cd12f 这样更加事半功倍。
秒杀那个，kafka消费端要多台机器，消费一定要快，如果不快的话，由于你前边都是乐观锁，队列里边会有很多版本号一样的，这样就会有很多数据到了后期消费的时候，是失败的（当然你做了限流），然后我有个疑问是：我有多台机器去消费，比如ABC三台consumer，我用kafka的广播模式，同一条消息会被ABC得到消费，只有由于乐观锁的原因，消息在A创建了订单，在B和C都拒绝了，那这样其实ABC三台机器都是瓶颈（他们有必要不重复接受），如果我让1-26条消息，1-10让A消费，11-20让B消费，21-26让C消费，这样就得使用单播模式，，，单播模式可能就要指定分区生产和指定分区消费，这样的话扩展性不灵活，，，，楼主有没有什么方案？
我用kafka的广播模式，同一条消息会被ABC得到消费，
如果是采取的消费组模式，同时 group.id 是一样的那肯定不会被 ABC 都取到消息，只会有一个消费者拿到消息。
我用kafka的广播模式，同一条消息会被ABC得到消费，
如果是采取的消费组模式，同时
group.id是一样的那肯定不会被 ABC 都取到消息，只会有一个消费者拿到消息。
那这样，得到消费机会的那台机器会一直得到消费机会，其他的2台一直得不到消费机会。多态部署也就失去意思了，，啊~~~~好矛盾~~~
那这样，得到消费机会的那台机器会一直得到消费机会，其他的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 还可以接着消费。
那这样，得到消费机会的那台机器会一直得到消费机会，其他的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不能再生成订单。
@1156721874
是的，如果 Topic 有多个分区肯定得分布式锁才行。但这样加锁解锁后的效率也会降低。
所以我建议对于秒杀这样的场景 Topic 只需要一个分区即可，这样可以保证信息的顺序以及避免使用锁，直接将请求由并行变为串行。
不过这样吞吐量就会下降，但对于秒杀来说吞吐量本身就不高，我觉得是可以接受的。