awesome framework for room based logic.
所有重大，独立性强的，可以，理应模块化的代码，不应当依赖非系统包。即使依赖此仓库的其他包，也是不应当的。
彻底模块化，并实现独立的测试用例为基本规范。
1、记录所有的用户列表---用户上下行数据记录，离线-连接记录，能够做统一的排错分析。
2、系统的qps，需要统计以每分钟为采样频率的qps。
3、定时任务统计
4、匹配模式的数据统计。
我们经常能遇到一个需求： 某一个topic，发布者希望知道有没有订阅者处理，处理的结果是怎样的？这是综合了rpc与mq两者的特点抽象的一个常见需求。 rpc有一个显著的缺点，如进程拆分较多，例如超过3个进程，某一个进程需要调用其他某个进程的服务，必须要知道此接口由什么进程提供，对应进程的调用地址。对于三个进程来说，调用其他两个进程的rpc，就需要维护一个topic与地址的映射关系表了。 对于那些拆分成超过10个进程的结构来说，维护rpc是一个很繁琐的事情。
rpc还有一个显著的问题，即同一服务多开，提供负载均衡，需要调用者自己维护和实现重试机制。或者需要一个中心节点来维护rpc的负载均衡，这样一来，又多了一次远程调用。
框架内部实现了一个轻量级的mq，提供了4种类型的模型。
1、可靠随机发布。
可靠随机指的是，mq将消息随机选择一个订阅者做处理。同一消息可均等相应mq的消息，即所有进程状态是一致的。
此模型提供超时机制。
发布者可阻塞等待订阅者的处理结果返回，就像http/rpc请求一样。函数定义如下
func (a *AmqClientPublisher) PubReliableToRandomOne(data []byte, cmd anet.PackHeadCmd) (resp *anet.PackHead, isTimeout bool)
2、可靠指定发布。
可以指定发布指的是，一个消息的订阅者可能有多个，但是只有一个能返回处理结果，或者做出处理。
一个常见的应用常见举例：
一个聊天服务器负载1万用户，十万用户在线，均分在十台服务器上。
用户a需要发消息给用户b，所有进程都可订阅聊天消息，消息队列将a发给b的消息发布给十台服务器，其中，如果用户b在线负载在服务器s上，则用户a的进程将收到发送成功的消息，否则，此消息收到超时返回，即用户b不在线。
此需求可有无数种方案实现。此消息队列模型提供了一种极简单的方案。
函数定义如下
func (a *AmqClientPublisher) PubReliableToSpecOne(data []byte, cmd anet.PackHeadCmd) (resp *anet.PackHead, isTimeout bool)
3、不可靠全部扇出发布
此模型会会把消息扇出给所有的订阅者，此模型与大多数人所用的普通订阅/发布模型一致。此模型不做消息持久化，只要有订阅者，哪怕是一个订阅者，消息会立刻从缓存队列中扇出。
如未有订阅者在线，消息队列缓存3秒，3秒内有订阅者上线，会被消费掉，如3秒等待周期未有订阅者上线，消息会被丢弃。
func (a *AmqClientPublisher) PubUnreliableToAll(data []byte, cmd anet.PackHeadCmd) (err error)
4、不可靠随机扇出
此模型会把消息随机扇出给一个订阅者，至少会保证是在线的订阅者。此模型亦不提供持久化。此模型内部亦提供了3秒钟的缓存周期，尽量周全订阅者重启的原因。
func (a *AmqClientPublisher) PubUnreliableToRandomOne(data []byte, cmd anet.PackHeadCmd) (err error)
消息队列使用框架封装的anet库作为网络层的支持，anet提供了完善的断线重连以及tcp、websocket两种网络协议的支持。tcp协议的阻塞式消息请求在8700k型号CPU的家用台式机上，压测结果超过45万QPS。性能上是没有问题的。 anet库提供了极简化的tcp服务器和tcp客户端接口。有经历线上产品的检验，可以在生产环境实际使用。
消息队列内置的3秒缓存周期仅仅是考虑到订阅者宕机，自动重启的这个间隙，这一特定场景。 此mq库极轻量级。其中可靠随机发布模型，在作者这台4710MQ型号CPU的笔记本上面能达到4万QPS，8700k的CPU上的压测结果接近10万QPS。 压测和单元测试的覆盖度接近50%，截至2022年6月10日，可以使用在预言性质的产品上。提交的issue，作者会提供排查处理。