原始上报方案

原有的客户端上报方式为：客户端定时循环将自身的全量核心数据从客户端上报到服务端，并将其作为心跳数据的来源。

上述表述的关键词：定时、全量、心跳

1. 定时上报：客户端需要定时的将数据上报到服务端，这部分数据其实都是一样的。那么为什么还要定时上报了？当时主要考虑了如下2个情况：

   • 客户端在服务端之前启动

   • 服务端宕机后，如果没有定时数据上报，会导致服务端没有数据存在

2. 全量上报：因为是定时的全量上报，服务端无法识别这些数据是新的还是旧的，所以存在2个问题。数据流量大，网络占用多。

   • 服务端处理所有客户端上报的数据，CPU压力大。

   • 后续的优化主要也是针对这2点进行处理的。

改进方案

引入了新的上报机制：

1. 折分之前将数据包和心跳包合二为一的处理方式，拆分后心跳包和数据包独立

2. 关于心跳包有如下3个机制

   • 心跳包中仅仅发送部分最核心的信息，数据量非常小，所以发送间隔可以设置的小些。

   • 心跳包每次发送后收到的数据也非常小，仅仅为后端服务器的唯id

   • 心跳包如果发送出现错误，那么会在内存有个机制，数据包的上报需要依赖这个策略

3. 数据包的上报有如下3机制

   • 数据包仅仅会在应用每次启动后发送一次

   • 当心跳包收到的服务端d同内存上次记录的不同的时候，数据包会重新上报

   • 当心跳包发送出现异常后数据包会重新上报。