Zhaohui Yu

@xkrivzooh websocket连proxy这里有一个逻辑的：websocket需要轮询所有proxy，然后寻找agent的连接在哪一台proxy上，所以直接暴露proxy不管是放在nginx后面，还是lvs域名都不行（除非你给每台proxy一个域名）。 合理的方式就是 websocket 通过nginx连接web ui(一个域名)，由ui去选具体哪一台proxy，然后去连接。

@doodoocoder 谢谢 不过选最后一个就代表选的是真实ip么？ 是巧合，还是确实就是这样呢？有依据么 这里确实困扰我很久

@doodoocoder 配置也是一个办法，但是有点麻烦，每一台都要去单独配置，我看看有没有别的什么办法

@doodoocoder 不过可以加上配置的选项

@sxlvalue 适合啊，他们已经在生产上线了

Good idea

后面有时间我们会整理这一块，也欢迎大家提交pr

没有做过性能相关的测试对比，不过从公开的数据看qmq的性能数据和rocketmq差不多，处于相同的数量级 qmq和rocketmq, kafka的区别更多的是在设计模型上的考量，这个就看各个公司的业务类型 关于设计模型，可以参考qmq的设计文档，如果你发现qmq的模型正好解决了某些其他mq没有解决的痛点，那么qmq或许是一个不错的选择

QMQ最开始的定位是用于业务中的消息中间件，在业务使用中我们并不推荐将所有数据都通过消息来传递，这往往会导致时序等问题，我们更推荐使用消息传输一些关键信息，而消费方使用这些关键信息查询到最新信息。 举一个例子，假设我们在订单系统中使用消息来发送订单变更事件，如果将订单所有信息都放在消息里，这样消息消费方在收到消息后因为具备所有他需要的消息很有可能就会拿这些消息去做业务处理，而订单可能有多个不同的变更方，这样一来很有可能消费方使用消息里的订单数据时订单已经发生了变更，那么消费方就使用了一个错误的数据来处理，我们这个时候更推荐消费方使用比如订单号去查询到最新版本的订单。 所以这种使用key/value的方式设置消息的API是我们有意为之。

Ctrip + http://www.ctrip.com/