App后台开发笔记

第九章-上
App后台架构
聊天架构
由于弱网性的缘故，信号不稳定响应时间长，出现丢包等问题，减少数据往返的次数，如果一长连接的形式，可能出现App和服务器突然中断，而且没法通过连接端口异常进行判断 他的危害导致一直占用服务器的资源，和发送消息的异常，有效的防止这种现象 使用心跳机制，App特定时间想服务器发送一次，让服务器知道改连接还在
服务器检查App的连接三个方式

1. 服务器每次记录连接收到的最后的心跳包时间，每个一段时间去检查所有连接，缺点在于服务器同时检查所有连接，连接数目较大时，对性能有影响
2. 服务器为每一个连接建立一个定时器，到规定时间去断开，如果收到就重设定时器，这个缺点在于每一个连接建立一个独立的定时器，如果连接数目过多，还是会建立上万个定时器，销毁系统资源
3. 采用时间轮片的方式为每一秒设置一个桶，如果超时为60秒就有60个桶，然后60个桶是个循环队列，第一个桶放一秒后要超时的连接，第二个桶放两秒后要超时的时间，每一个连接收到心跳就包自己放到第60个桶的中，每秒的定时器吧第一个桶所在的连接中断

常用的聊天协议是XMPP 基于xml的消息协议，基于这个协议开源的连体服务器 有Ejobberd和openfire两个，App的通信协议一般是使用TCP协议 tcp协议是面向连接，流提供可靠的服务协议。
TCP协议有个常见的沾包问题，当网络上的数据包到接收端，程序会预先设定缓存区大小去数据，假设用户缓存区为15字节，当第一个数据包10个字节 第二个数据包为10个字节，这是要缓存区的数据包含了第一个数据包和部分第二个数据包，当数据取出的时候会有沾包问题，解决这个问题在于制定合理的协议格式，每个数据包中标明了这个包的长度，这样程序就可以处理包的数据。MySQl协议，中一个数据包 前三个字节是数据包的长度，第四个字节是数据包的序列号，剩下的字节是数据。
处理丢包的情况，
这么确定客户的是否接受到消息，这么确定需要重发那些消息。

传统的IM协议中是基于队列的消息发送给反馈机制
服务器发送消息给客户的，客户的需要发送确认收到的应答，如果过了一段时间服务器没收到，就重发这个消息 这中方式会有两个问题

1. 如果客户的收到消息，并且发送了确认信息，但是网络中断，导致服务器收不到应答，客户端会重复收到该消息。
2. 由于移动端的弱网性，每条消息都是费时，服务器维护每个消息的状态也是容易出错

基于版本的的消息协议
每个消息有一个自增且不重复的版本号， 服务器推送消息给客户端，App收到这个信息向服务器返回消息同步的消息，服务器根据版本号，把大于这个版本号的所有消息推给App，如果App收到消息网络中断，等网络正常，app向服务的发送消息同步信号，吧本地的消息版本号带上，流程还是会走通

整体的架构
连接层，业务层和持久层
连接层只负责 与App保持连接，并把消息队列转发给逻辑处理。

在连接层注意的问题
连接层的服务器很少启动，一旦重启会导致大量的App断线，并在短时间内重连服务器，服务器一瞬间涌入大量请求类似DDOS攻击，合理的杜绝：当连接层准备重启的时候，发送一条消息到连接这太服务器上的app然他连接别的服务器，不可使用当前的服务器，使用动态接入点App访问接入点的时候，根据各个连接服务器的负载进行综合计算返回一个连接服务器的ip给app