注册
登录
| 关键词： 瓶子 数据 更新 important 更多 客户端 时间 增量 问题 服务 |
QQ邮箱4.0增加了漂流瓶功能，记录一下做漂流瓶过程中碰到的问题。增量更新漂流瓶有我的瓶子列表，需要跟后台保持同步，于是当然就需要个增量更新方案，在常见的两种增量更新方案—对比和日志中，选择了后面一种，因为按目前漂流瓶后台的情况，可以很容易地支持这种方式，不需要记录每一步操作，只需要按时间作为key查找这段时间内数据的增删改就行了。这种方案对前端来说这种方式更是方便，只需要记录一个sync-key，往上请求就行。具体实现方式是：1.请求列表，返回数据，以及后端当前服务器时间svrtime2.下一次请求列表，客户端带上上次返回的svrtime，后端从数据库查出svrtime和当前时间这段时间内列表数据的增删改，返回给客户端后端瓶子有updateTime字段，数据新增或更新时会记录当前时间，所以很容易找到一段时间内所有增改的数据。对于删除，后端删除瓶子时是不会删除瓶子记录的，只会把瓶子标记成已删除，有个标志日期，所以也可以找到时间段内删除的瓶子。加载更多瓶子列表不会一次性全部加载，每次请求返回20个瓶子，所以需要个加载更多的功能把后面的瓶子拉回来。实现的方式是把客户端列表最后一个瓶子的id上法给服务端，服务端把所有瓶子按时间排序后找到这个瓶子id对应的位置，返回它后面的20条数据给客户端。瓶子是按时间排序的，瓶子的时间会变化，例如回复一个很早的瓶子，这个瓶子时间就会更新，跑到列表的最上面来，这样的场景导致加载更多会有问题。1.最后一条数据被更新如上图，客户端列表当前状态是Bottle1-Bottle40排列，这时服务端Bottle40已经被更新，跑到最上面了，客户端还没有更新过来，这时点击客户端的加载更多，会把Bottle40作为游标上发给服务端，期望返回Bottle40以后的数据，结果服务端返回的是Bottle1-Bottle20。结果导致的效果是加载更多完成后列表上的数据完全没变化，再点多少次加载更多都一样。2.最后一条数据被删除再看看瓶子被删除的情况，上发Bottle40到服务端后，服务端已经无法找到Bottle40的位置，只能什么都不返回，表现跟上述瓶子被更新的情况一样。加载更多的实现是以前后端数据一致为前提的，上述问题就是前后端数据不一致导致的，解决方法也挺简单，就是加载更多会对列表做一次增量更新，若有更新，直接返回增量更新的内容，若无更新才执行加载更多的流程，确保数据一致的前提下才进行加载更多。时序问题客户端的愿望是跟服务端数据保持一致，但在请求发出->返回的间隙中会出现一些数据不一致的问题，例如：发送漂流瓶->后台接收到请求，客户端尚未接收到返回->加载漂流瓶列表->把发送成功的瓶子拉回来了->本地还有一个发送中的瓶子（没有id）->出现两个一样的瓶子->发送漂流瓶请求返回客户端除了发送瓶子，发送聊天，回复海滩瓶也有同样的问题。为解决这个问题，为这些可能会关联依赖的请求做了个队列，让发送漂流瓶的请求完成后再发出请求，就不会出现上述问题了。这个队列属于逻辑层，不能在网络层直接做，而请求是异步的，用原生的GDC队列无法让异步的请求排队，为此做了个简单的异步队列：01020304050607080910111213141516171819202122
声明：文章版权归原作者所有 部分文章转自互联网 如有侵权请联系
[邮箱地址] 删除
|
