设计概述

后台同步方案的设计就是数据存储结构的设计，如何快速体现“信息变化”，如何快速计算出“变化信息”。后台数据存储结构是由同步协议中同步契约决定的。

设计方案

该方案的同步是按照业务粒度来划分，只需要同步sdk要求同步的数据。

缓存数据模型

//用户信息
UserInfo
{int64 uid; int64 user_info_version; //个人信息版本号string nickname; int64 nickname_version; //昵称版本号string avatar; int64 avatar_version; //头像版本号string signature;int64 signature_version; //签名版本号
}

//群组信息
GroupInfo
{  int64 gid;int64 group_info_version;//群组信息版本号string group_name;string group_desc;  
}

//事件信息
Event
{int64 event_id;//事件idint32 event_type; //事件类型  int64 from_uid; //事件发起者int64 gid;//群组idint64 to_uidlist; //事件当事人int64 event_version;//事件版本号 
}

//群组成员
GroupUser 
{ int64 gid; int64 user_info_version=2; //群组的所有成员中，用户信息最新的成员，他的个人信息版本号 int64 user_list_version=3; //群组成员列表版本号，只要user_list发生变化，该版本号也要发生变化list<UserInfo> user_list; //群组成员列表
}

//用户群组
UserGroup
{ int64 uid;int64 group_info_version; //用户的所有群组中，群组信息最新的群组的版本号 int64 group_list_version; //用户群组列表版本号，只要group_list发生变化，该版本号也要发生变化list<GroupInfo> group_list; //用户群组列表 
}

//好友
UserFriend
{int64 uid;int64 user_info_version;//用户的所有好友中，用户信息最新的好友，他的个人信息版本号 int64 user_list_version;//好友列表版本号，只要user_list发生变化，该版本号也要发生变化list<UserInfo> user_list;//好友列表
}

//群组事件
GroupEvent
{list<Event> event_list;//事件列表
}

// GroupMemberSync业务契约需要的请求信息 
GroupMemberSync { int64 gid; int64 user_info_version=2; //群组的所有成员中，用户信息最新的成员，他的个人信息版本号 int64 user_list_version=3; //群组成员列表版本号
}

// GroupMemberSync业务契约需要返回的信息 
GroupMemberSyncRsp { GroupMemberSync group_member_sync; list<UserInfo> users; list<Event> events; }

同步流程

业务请求处理流程：业务请求->service模块->业务在改变信息本身的同时也要记录信息的变化。

用户信息更新

->用户信息更新请求
->service模块
更新用户信息UserInfo中user_info_version版本号和相应属性nickname_version、signature_version等的版本号。
更新用户所属群组的GroupUser中user_info_version版本号和成员列表中该用户的user_info_version版本号。
更新用户所有好友的UserFriend中user_info_version版本号和成员列表中该用户的user_info_version版本号。
（复杂度为o(n)，n表示数据库中操作元素的量级，key-value数据库以key为单位，sql数据库以行为单位）

群组操作（创建群组、退出群组、添加群组成员、删除群组成员）

->创建群组、退出群组、添加群组成员、删除群组成员请求
->service模块
更新用户所属的群组GroupUser中user_list_version版本号。
更新用户群组列表UserGroup中group_list_version版本号。
在群组事件列表GroupEvent中添加一条新记录。
给SDK下发一条业务契约的同步通知，让SDK决定是否要及时同步信息。

// 同步通知
SyncNotification
{list<GroupMemberSync> group_member_sync;
}

同步驱动处理流程：同步驱动->sync模块->业务契约需要的增量更新结果

获取群组成员增量信息

->同步驱动

// 同步驱动
SyncRequest
{list<GroupMemberSync> group_member_sync;
}

->sync模块
比较GetGroupMemberList业务契约请求信息中group_list_version_1 和后台数据库中Group_User的 group_list_version_2，找出该群组的两个版本号之间的Event，得到群组中成员的增量变化。（复杂度为o(n)）
比较GetGroupMemberList业务契约请求信息中user_info_version_1 和后台数据库中Group_User的 user_info_version_2，找出该群组两个版本号之间信息发生变化的用户，得到增量的用户信息变化。（复杂度为o(n)）
->增量同步结果

// 业务契约的同步结果
message SyncResponse
{list<GroupMemberSyncRsp> group_member_sync_rsp; 
}

缺陷

按业务粒度划分会导致业务和业务之间的同步信息有交集，也就是说会产生某些元信息出现重复同步。

难点

KEY-VALUE数据库需要提供批量操作KEY的接口。
需要一个可容灾的生成全局增量序列的服务。