是这样的，我们正常就是println，我感觉基本上可以定位我所有问题 ， 但也不排除由于并行性通过println无法复现的问题，目前来看只能靠经验了 。只要常见并发尝试，经过分析是可以找到的 。go很快会推出调试工具的~
Q5:协议栈是基于tcp吗？
是否有协议拓展功能？协议栈是tcp，整个系统tcp长连接，没有考虑扩展其功能~如果有好的经验 ， 可以分享~
Q6:问个问题，这个系统是接收上行数据的吧，系统接收上行数据后是转发给相应系统做处理么，是怎么转发呢，如果需要给客户端返回调用结果又是怎么处理呢？
系统上行数据是根据协议头进行转发，协议头里面标记了产品和转发类型，在coordinator里面跟进产品和转发类型，回调用户 ， 如果用户需要阻塞等待回复才能后续操作，那通过再发送消息 ， 路由回用户 。因为整个系统是全异步的 。
Q7:问个pushsdk的问题 。pushsdk的单连接，多app复用方式，这样的情况下以下几个问题是如何解决的：1）系统流量统计会把所有流量都算到启动连接的应用吧？而启动应用的连接是不固定的吧？2）同一个pushsdk在不同的应用中的版本号可能不一样，这样暴露出来的接口可能有版本问题 ， 如果用单连接模式怎么解决？
流量只能算在启动的app上了，但一般这种安装率很高的app承担可能性大，常用app本身被检测和杀死可能性较少，另外消息下发量是有严格控制 的 。整体上用户还是省电和省流量的 。我们pushsdk尽量向上兼容，出于这个目的 ， push sdk本身做的工作非常有限，抽象出来一些常见的功能，纯推的系统，客户端策略目前做的很少，也有这个原因 。
Q8:生产系统的profiling是一直打开的么？
不是一直打开 ， 每个集群都有采样，但需要开启哪个可以后台控制 。这个profling是通过接口调用 。
Q9:面前系统中的消息消费者可不可以分组？类似于Kafka 。
客户端可以订阅不同产品的消息，接受不同的分组 。接入的时候进行bind或者unbind操作
Q10:为什么放弃erlang,而选择go ， 有什么特别原因吗？我们现在用的erlang？
erlang没有问题，原因是我们上线后，其他团队才做出来 ， 经过qa一个部门对比测试 ， 在没有显著性能提升下 ， 选择继续使用go版本的push ， 作为公司基础服务 。
Q11:流控问题有排查过网卡配置导致的idle问题吗？
流控是业务级别的流控，我们上线前对于内网的极限通信量做了测试，后续将请求在rpc库内，控制在小于内部通信开销的上限以下.在到达上限前作流控 。
Q12:服务的协调调度为什么选择zk有考虑过raft实现吗？golang的raft实现很多啊，比如Consul和ectd之类的 。
3年前 ， 还没有后两者或者后两者没听过应该 。zk当时公司内部成熟方案，不过目前来看，我们不准备用zk作结合系统的定制开发，准备用自己写的keeper代替zk ， 完成配置文件自动转数据结构，数据结构自动同步指定进程，同时里面可以完成很多自定义的发现和控制策略，客户端包含keeper的sdk就可以实现以上的所有监控数据，profling数据收集，配置文件更新，启动关闭等回调 。完全抽象成语keeper通信sdk，keeper之间考虑用raft 。
Q13:负载策略是否同时在服务侧与CLIENT侧同时做的 (DISPATCHER 会返回一组IP)？另外 ， ROOM SERVER/REGISTER SERVER连接状态的一致性|可用性如何保证? 服务侧保活有无特别关注的地方? 安全性方面是基于TLS再加上应用层加密?
会在server端做，比如重启操作前，会下发指令类型消息，让客户端进行主动行为 。部分消息使用了加密策略 ， 自定义的rsa+des，另外满足我们安全公司的需要，也定制开发很多安全加密策略 。一致性是通过冷备解决的 ， 早期考虑双写，但实时状态双写同步代价太高而且容易有脏数据，比如register挂了 ， 调用所有room，通过重新刷入指定register来解决 。
推荐阅读
- 射击潜入游戏，潜伏射击类游戏
- 公众号怎么找到小编码呢，微信公众号代码怎么找
- 盈通显卡7300怎么样，盈通显卡7300怎么样啊
- linux进程终止的命令 linux终止进程命令带什么参数
- cpu和emc是什么，emc和pct的区别
- 关于postgresql排序分页的信息
- 阿里云服务器普通，阿里云服务器用处
- gcgo语言 go语言gtk
- mysql索引长什么样，mysql索引是啥