增量更新模型的讨论

客户端和服务端的数据同步过程当中，客户端有缓存，不须要每次都是全量刷新，因此能够采用增量的方式更新。

每次在客户端进行刷新的时候，服务端会将最新的增删改操做推送到客户端，客户端对其缓存进行操做，以保持数据的同步。

最原始的方法 - Full Transfer

[图片来自参考文献 1]

咱们要实现的是数据的同步，那么咱们只要每次在本地列表须要更新时，将全部后端数据库的信息拉取到本地，进行对比，若是有新增就新增，有修改就修改，若是新来的版本里面某一项不见了，就直接在本地缓存中删除该项便可。

优势：

• 写接口时很清爽，它是最简单的实现

缺点：

• 服务端发送多余的数据
• 只能用于小数据量，在数据量比较大的时候，单次刷新的操做就耗费不少网路流量。

应用场景：IMAP 协议，新闻类 APP 中的每日头条，如 Yahoo News Digest

在 CalDAV 日历协议中，每一个日历事件都拥有一个 ETag 来标记它的版本信息，客户端对比服务器发来的 ETag 来决定要不要更新某项日历事件，此处的 ETag 和 HTTP headers 中 Last-Modified 和 ETag 实际上是同样的东西，用于标记版本信息。这种方式即为接下来要提到的 Timestamp Transfer。

根据修改时间来拉取增删改信息 - Timestamp Transfer

[图片来自参考文献 1]

客户端存储上次拉取的数据的 Timestamp，在请求更新数据时，携带该 Timestamp 做为本地数据版本信息。数据库内每行数据设置一个 LAST_UPDATE_TIME 字段，服务器将比该时间更新的数据返回给客户端。

优势：

• 相对于 Full Transfer 来讲减小了冗余数据的传输

缺点：

• 传输时 Timestamp 做为版本信息须要精确控制，请求错误的版本号可能带来本地数据的不许确
• 已经删除的数据其实已经不存在了，取不到 LAST_UPDATE_TIME

第二个缺点能够经过设置 IS_DELETE 字段来避免，每次删除数据时，仅仅更新 LAST_UPDATE_TIME 和设置 IS_DELETE 为 True 来标记已删除。此处带来的缺点是，被删除的数据继续占用空间，不过当只有一个客户端时，能够在客户端确认删除缓存中相应数据后删除数据库中 IS_DELETE 为 True 的数据，这个方法被成为 Soft Delete.

结合算法和修改时间来拉取增删改信息 - Mathematical Transfer

[图片来自参考文献 1]

服务器接收到客户端发来的更新请求时，将客户端根据 Reconciliation 算法生成的值来肯定要返回给客户端的增删改信息。此处说的 Reconciliation 算法的做用与 Checksum 校验和相似，用于校验数据是否已经修改。

优势：

• 避免了查询数据库时对 LAST_UPDATE_TIME 的条件过滤

缺点：

• Reconciliation 算法普适性低
• Reconciliation 算法开发周期长

增删改日志 - SYNC

服务端记录数据的每次操做都记录进一个增量数据库，数据库内记录了每条操做的对象 ID 和操做的内容。此处思想相似于 Patch 补丁操做，客户端发送一个 Timestamp 信息，服务器将这个时间之后的全部增删改操做返回给客户端，客户端再进行打补丁操做，使得最终结果与服务端同步。

优势：

• 保持了全部数据的精确可同步

缺点：

• 客户端好久不更新之后单次的更新补丁很大
• 若是数据改动不少，那记录操做的表将会变得很大

场景

咱们如今的需求是，有一个订单模块，某一用户在 APP 中能够点击刷新订单列表，将服务器上其全部订单显示出来。

# 订单更新操做
def order_update(request):
    # 对其中一个订单作更新操做
    order = Order.objects.get(id=1)
    order.update_time = time.time()
    order.save()
    # 设置缓存内的版本信息
    cache_time = time.time()
    cache.set('order_list_' + str(request.user.id), cache_time, 3600 * 24 * 7)
    return JsonResponse({})


# 返回订单列表
def order_list(request):
    # 保存客户端的版本信息 since，即 timestamp
    since = request.GET.get('since') or 0
    since = float(str(since))
    # 取出缓存中最新版本信息 since_cache
    since_cache = cache.get('order_list_'+ str(request.user.id))
    # 若是客户端携带版本信息为 0，说明客户端请求全量更新
    # 或者当缓存中版本新于客户端版本信息，则返回 update_time 新于客户端版本的全部条目
    if (since == 0) or since_cache and (since_cache > since):
        orders = Order.objects.filter(user=request.user, update_time__gt=since)
        data = [order.id for order in orders]
        return JsonResponse({
            'status': 1001,
            'since': since_cache,
            'data': data
        })
    # 没有更新，直接返回最新的缓存时间
    else:
        return JsonResponse({
            'status': 1001,
            'since': since_cache,
            'data': []
        })

筛选的状况

有时候咱们只须要更新知足筛选条件的条目，客户端利用 Timestamp Transfer 来进行拉取全部增删改信息，可是只针对知足筛选条件的那些项目进行更新操做，其他的直接丢弃。

参考文献

• DATA SYNCHRONIZATION PATTERNS IN MOBILE APPLICATION DESIGN
• 两种增量更新方案
• RFC 4791 - CalDAV
• AppSync.org
• Evernote Synchronization via EDAM
• Object Synchronizer