2019-09-25假如现在有用户A和B，以及三个接入节点S1，S2和S3，A给B发消息。A和B都查询最优接入节点，分别对应S1和S2节点。A–＞S1最优没问题，但S2–＞B一定是最优的吗？不一定，上下行通道隔离后，查询最优节点是客户端给节点发消息，代表的是该节点的上行通道是最优的，并不代表节点到客户端的下行通道是最优的。作者回复: 嗯，如果是通道隔离的话，针对上行通道和下行通道都需要进行接入点最优化选择。
5
2019-09-25希望老师可以出一篇监控的文章。。感谢感谢作者回复: 在后面的课程中会专门降到监控这一块的内容，敬请期待。。
1
2019-12-04主要应该是 上行下行 也就是输入输出之间的同步问题 同时如果按照文中的设计 单个 长链接 上行 如何做到上行之间的有序 去重 重发 就会很复杂 这样 输入之间 输入输出之间 就需要考虑更多的问题
2019-12-03两个通道隔离之后，如果消息队列里消息比较多，会不会影响消息的实时性？作者回复: 消息的实时性和是否拆分成两个通道关系不是很大，即使是在同一个长连通道里，服务端如果不能及时处理收到的消息，也会消息在服务端堆积，没办法快速投递。所以要解决的还是要提升服务端消息路由分发的能力。
2019-11-11问题1：短链接怎么idle几分钟呢？http不是无状态的吗？
问题2：如果上行通道和下行通道隔离，是不是2者对应两个不同的集群呢？作者回复: 1.短连接可以是tcp协议的呀，idle几分钟的主要目的是为了避免发消息这些行为需要每次建连影响体验同时也降低长连维护的开销。
2.一般连接层尽量隔开，因为分成两个连接的目的就是避免互相影响。
2019-11-04还有个问题，为什么上行通道不直接使用长连接，而要使用长连接。作者回复: 如上面回复：上行通道的连接不需要心跳，连接的保持对系统消耗是非常小的，这也是为什么上行通道没有再维护另一个长连的原因，一种折中的方式。
- 2019-11-04上下行通道隔离能够隔离保护我们的消息接收和消息发送，那么通道隔离会不会带来一些负面影响呢？
1.需要维护两个连接，消耗一定客户端性能。作者回复: 上行通道的连接不需要心跳，连接的保持对系统消耗是非常小的，这也是为什么上行通道没有再维护另一个长连的原因，一种折中的方式。
2019-10-08上下行通道隔离，消息发送方采用短链接，除了基于http tunnel不适合长连接的考量，还有其他因素吗？
作者提到可避免客户端维护多个长连接的开销，可是单纯的tcp连接应该不会耗费多少资源，和每次都采用短连接相比，还能接受连接不断的创建和关闭的代价。作者回复: 上下行通道分离还可以避免上行发消息操作被下行push消息所影响，比如直播场景中下行消息下推量巨大。维护长连接的开销除了连接保持，还有一系列的比如心跳发送等必备的行为，对于用户流量，电量不是很友好。这里的短连接也不一定是每次都需要重新建连，比如说可以保持idle几分钟，这样即能解决频繁消息发送复用一个连接的问题，也不需要维护一个真正的长连接。
2019-09-26老师在第十课的<自动智能扩缩容：直播互动场景中峰值流量的应对>中提到关于上下隔离的优点"能够隔离各自上行操作，避免下行推送通道产生影响，轻量、独立的长连接服务容易扩容。";坑没踩过，准备等十一长假开始自己写一个IM并在特定范围内试用-到时候就知道有哪些坑了。
进阶篇已经用到了不少基础篇和场景篇的知识：属于一边学习一边复习过程吧；期待老师的后续分享。
2019-09-26HTTP Tunnel在下行通道也会使用吗，如果存在代理的情况，下行通道发送给代理的数据如何再转发给客户端作者回复: 我们自己的业务中目前只用于上行短连通道中。理论上也是可以用在下行通道的，因为底层也都是基于TCP的，但是走http代理的问题在于连接一般很难保证不被代理断开，所以维护住一个真正的长连接比较困难。
2019-09-25既然客户端可以通过跑马竞速，选出一个最快ip链接。为什么服务器要返回一个排序IP列表？客户端还依据这个列表顺序进行判断么？作者回复: 实际上不冲突，服务器可以结合自身的压力按不同等级来返回排序的IP列表。客户端优先选择压力等级最小的多个IP进行竞速。
1- 2019-09-25老师，有3点不明白！
1:基于tcp的长链接不是全双工吗？为什么下行会影响上行呢？我的理解是，这里的影响不是通道影响，其实是服务器处理能力的影响，是这样吗？
2:HTTP Tunnel这个东西确实没用过！如果他是基于http的短链接，那它也没法实现一个完整的即时消息系统呀！比如他们拿不到服务器的推送消息！
3:在老师说的把通道和业务隔离上，我明白确实需要这样优化！有一点不明白的是，这里的通道和服务是不是可以理解为链接服务和业务逻辑服务！比如链接服务只管链接，链接服务和业务逻辑通过消息队列解耦！但是如果是这样的话，用户的链接映射维护是在链接服务中呀！不在业务层！
老师的问题，我感觉因为隔离开了，所以就不是“原子”的了，那么就可能存在能发看不到，能看到发不出去的情况展开作者回复: 1. 在消息下推数据量持续很高时，tcp链路的稳定性会下降，拥塞机制可能会导致消息的发送也被阻塞，另外就是你提到的高并发推送压力下服务端处理能力也容易出现瓶颈。
2. HTTP Tunnel一般用在短连接发消息的场景里。
3. 通道和业务隔离可以理解为 维护连接的服务和业务逻辑服务分开，连接映射的维护是在连接层处理的，但不一定就在连接服务里，比如可以维护在中央的资源里，方便其他连接服务集群里的机器来共享使用。
在同一个通道里也不一定是原子的呀，发送成功了也可能推送失败。通道隔离的一个问题在于如果上行通道通过短连接实现的话，可能会存在发消息时才建立连接的情况（为了简单，没有心跳机制，一段时间不发消息就会强制断开），所以用户体验上会差一些。另外，额外的通道部署上也有额外的维护开销。 4 
2019-09-25通道隔离的最大问题个人觉得连接断开时机问题，比如A断开，B什么时候断开，要做跟踪记录作者回复: 通道隔离为什么要做跟踪记录呀？实际上通道隔离的一个问题在于如果上行通道通过短连接实现的话，可能会存在发消息时才建立连接的情况（为了简单，没有心跳机制，一段时间不发消息就会强制断开），所以用户体验上会差一些。另外，额外的通道部署上也有额外的维护开销。
1