明白了  太感谢了

引用：xxfx007 发表于 2018-02-27 09:42
我当时是想，摇奖的时候，转盘每动一下，要从server上同步一下组里的信息，再分发给组里的各个用户。

你 ...

抽奖的过程不需要发，每个人只需要收到两个指令：开始、结束，就可以了。
过程你完全可以在各自的端做动画模拟就行了，定时发完全没有意义，应从实际出发，不要理想化

我当时是想，摇奖的时候，转盘每动一下，要从server上同步一下组里的信息，再分发给组里的各个用户。

你说的意思我大概明白了，就说建组这个人发一个开始游戏，然后server把这个群发给成员，各自成员的手机转盘就开始转，不用同步server的数据，之后建组的人发一个结束游戏，这时候把算出的结果，群发给成员，各自成员的转盘收到结果，并停止转动。 整个过程 建组的人一共发两次消息。

如果是照你说的要做的就是摇奖游戏，为何定时发送？摇出来就发给这个组不就行了吗，跟群聊道理一样啊

非常感谢回答，我这两天写了一下代码，但是还是有点思路上想不通的地方，请指点一下。

1，“在一个Timmer周期到来的时候启动多个线程同时工作从而加快效率。”        是不是timer执行一次，开一个新线程去给整个组发消息，这样线程之间不影响？

2，生产者消费者模型我知道点皮毛，是不是共同维护一个消息队列，服务端只往里加但不发送，在客户端定时的是队列里取？

3，我想做一个小游戏，一个人新建一局，几个人加入该局，开始摇奖，这几个人就是一组，摇奖的信息就给该组发送，然后可能有很多组，就想实现这么个场景。

先回答第一个问题，关于怎么能加快推送效率、容错的问题：
这个问题从业务上来说不复杂，但要实现起来还是要动一些脑筋，你可以弄一个生产者消费者模型出来，在一个Timmer周期到来的时候启动多个线程同时工作从而加快效率。

你想单独维护自已的在线列表的话，直接在服务端的回调里监听用户上线、下线回调就行了（OnlineProcessor也是通过这个原理实现的，请放心使用）：
（API文档请见：ServerEventListener。用户上线了就加入到你自已的列表，下线了就从列表中移除，就是这么简单）