同步协议优化讨论——技术整理20180118

1. 需要同步的文章列表server端去重

原因：
同步协议升级到v4导致的历史遗留问题，接口返回结果为 >= last_sync_time的结果集，导致最后一篇更新的文章总是会被info接口返回需要更新(=)

影响：
客户端（包括PC）每次都要去重、影响同步速度、流量浪费

相关接口：
/articles/info

优化方案：

• server 待调研（涉及大量老数据以及v4.0前老版本APP）
• 产品 需要统计v4.0前老版本的占有率，并给出强制升级策略

2. 修复传时间戳的情况下del_include无效bug

原因：
历史遗留，测试未发现bug

影响：
客户端（包括PC）会拉到已删除的list数据，要多一步数据筛选

相关接口：
/articles/info

优化方案：
server 修复 & native配合

3. 优化网络异常下，两次create请求的处理逻辑

原因：
server收到重复的create请求时，会转update逻辑，考虑多设备push导致版本不一致，所以没入库，因此造成数据丢失。
目前线上实现是，server返回了409有冲突，客户端新建了一份本地副本，新建一篇新文章。

影响：
目前线上弱网情况下，客户端多出N份同一文章的副本

相关接口：
/articles/push

优化方案：
server优化 & Native配合

同一个localId做二次create提交的时候：

server如果确定未被其他设备修改过，返回serverId，如果客户端本地此时有同一serverId的文章，走去重逻辑留当前新的这个，如果没有则走正常create成功逻辑。
server不确定的时候走类似409逻辑，通知客户端create失败，且告诉客户端目前服务器里的冲突文章的最后修改时间和版本号，客户端对比最后修改时间和版本号来决定覆盖还是新建副本。

4. 图片存储作为基础服务剥离出来（同步/绑定/存储分开）

原因：
图片存储和图片业务关系耦合较重，有之前未测到的逻辑漏洞（图片关系绑定完了才认为是上传完了）。

影响：
客户端图片已传但绑定关系未传情况下，server会认为图片未传，客户端因此重复上传，浪费流量

相关接口：

询问没有上传过的图片接口(sync/img/absent)
获取断点图片已成功上传部分的index接口(sync/img/break)
上传图片接口(sync/img/upload)
图片组绑定接口(sync/img_group/bind)
获取图片信息接口(sync/img/obtain)

优化方案：
server重构 & Native配合重构（原则上native可以不做修改）

目前Android会存URL，ios不会存（可以通过img的id去获取URL）

5. 信纸&字体优化

优化方案：
server按之前方案优化(三端共用一套接口)

6. 生成H5，WiFi比4G慢问题

优化方案：

• 产品需要梳理p1是否加入同步协议
• Android可以配合产品，走一些不依赖server的逻辑试一试