本文描述一种基于消息的会话列表差量更新的实现，也算是属于原创吧，哈。
先描述一下，用户在消息列表界面看到的“与某人或某个群的对话列表”，此处称为会话列表。
对，奏是这个图所示的列表。
本文描述的方案，在存储方面选用的存储是mongodb。其实在做之前没有特意为实现细节去选db，而是确定选用mongodb之后，基于它的特性来细化方案(对于海量数据级别的实现基于mongodb比较有优势，便于扩展，但是对于数据量较小的企业，选用mongodb作为存储有点尴尬，一个是小数据量对于存储的扩展要求不高，另一个是mongodb性能赶不上其他的nosql)。但是我相信基于其他的存储也可以做到。下面分开描述这个需求要做的事情。
1. 用户每次登录首先去拉取会话列表，差量返回有过修改(删除)或者有新消息（任何设备未拉取过）的会话列表，会话附带一条消息返回。
2. 要求会话列表是云端存储的，设备间要能同步。我在安卓手机上面做了删除会话Ca(C代表会话，a代表对方的id)操作，切换到另一台手机(比如苹果)需要告知会话Ca被删除。我在安卓手机与韩梅聊过天，并生成了会话记录Ua，切换到另一台手机，需要拉到这个会话Ua。
3. 要求消息是差量更新的，而且每个会话里只拉取最新的一条消息记录。差量更新时，只有包含新消息的会话才会返回。为了保证最省流量(帮助用户省流量的产品才是良心产品)，没有新消息或者没有会话更改的，一律不返回数据。这个消息或会话差量更新的实现使用数据版本号来做。
客户端看到的会话伪代码数据结构简要描述如下：
conversation
{
uint32 delta_flag;//差量操作标志，增删
uint64 snapshot;//数据版本号
uint64 peer_id;//对方的id,标识与谁产生的会话
MsgInfo lastest_msg;//最新的消息
uint32 unread_msg_num;//本会话的未读消息数
}
差量会话同步数据的实现在客户端看来只有一步，具体在服务器的实现分为1.同步有过修改的会话列表，2.同步新消息，再根据消息生成会话列表，3.对1,2的结果做交集。
先介绍服务端在实现这个方案所涉及到的存储数据结构。
消息的存储结构简要伪代码：
MsgInfo
{
uint64 id;//这是给某人存储的消息
uint64 from_id;//消息发送方
uint64 to_id;//消息接收方
uint64 msg_id;//标识一条消息
uint32 msg_time;//消息的产生时间
string msg_content;//消息内容
}
会话的存储结构简要伪代码：
ConversationInfo
{
uint32 delta_flag;//差量操作标志，增删
uint64 snapshot;//数据版本号
uint64 peer_id;//标识与谁产生的会话
MsgInfo lastest_msg;//最新的消息
}
涉及到mongodb的特性：
mongodb是介于sql和nosql之间的产品，有sql域的概念。可以对文档的部分字段更新，可以在查询数据的时候指定排序的域及其排序方式，更新数据的时候匹配就更新或者不更新，更新数据时没有匹配就插入新数据，更新数据同时返回更新之后(或者更新之前的)的数据。
会话列表的更新时机及更新的字段：
每产生一条消息的时候，就会相应的为每个用户更新会话信息，更新的内容就是最新消息和差量操作标志(新增)，还有一些支持其他特性字段，此处无关不列出了，但是此处不更新会话的数据版本号。
会话信息的更新时机有多个，上述做法会导致db写的复杂度上升。还有一种是同步的时候做更新。这种做法会导致db读的复杂度上升，暂不描述。
会话列表的删除时机及做法：
当用户手动删除某个会话或者清空会话列表时，会与服务器进行交互，客户端请求的参数包括会话的peer_id、当前会话中的最大消息id。peer_id用于查询会话，消息id用于判断请求是否已过期。如果是过期的请求，将不会删除会话。如果条件都符合，就将db中的会话进行标记删除，注意此处并没有将数据清除。
接下来描述删除请求过期场景：
1. 用户在设备A没有联网的情况下手动点删除会话Cc，本地将会话删除，同时将这个删除请求缓存在本地，等待下次联网时告知服务器。然后用户在设备B与用户c聊天，聊完之后并未删除这个会话Cc。之后设备A联网，将之前缓存的删除请求上传服务器执行，此时服务器将Cc标记删除，但是用户在设备B上并未删除会话Cc，导致设备B的数据与服务器不一致。这就是A的删除请求过期导致数据不一致。
2. 用户在某个时间点手动删除会话Cc，本地会话先清空，在这个删除请求未在服务器执行之前，c发过来一条消息，服务器更新了会话列表，然后客户端也同步消息到本地，本地再次生成这个会话，之后服务器执行删除操作。现在的情况是服务器认为会话已删除，本地则是新增会话，数据出现不一致。
所以为了解决请求过期导致的数据不一致问题，我们在请求中添加了操作版本号(不过此处使用的是最大消息id)。删除操作时，当服务器判断到客户端请求中的消息id小于服务器会话中保存的消息id，就不执行删除操作。
会话列表的同步：
用户登录完成之后就要同步会话列表，其请求的参数包括本地会话最大版本号和本地消息的最大版本号。两个版本号共同用于差量同步会话列表。
会话列表的最大版本号只能同步到用户手动更新过的会话列表，并不能同步到有新消息的会话列表，因为有消息产生的时候并没有更新会话列表的版本号。[1]
消息的最大版本号则用于同步新消息，服务器使用消息生成会话列表，并与上述同步到的会话列表做合并，两者合并的结果就是差量的会话列表。[2]
优化的点：
当客户端请求中的会话最大版本号为0时，仅仅通过[1]就可以把全量会话列表同步到，不需要再同步消息。因为会话列表中已经有最新消息。同时，删除的会话列表也不用返回，因为本地数据是空的，返回删除过的会话列表毫无意义。
单人消息的会话列表机制db访问时间复杂度：
产生一条消息会为消息双方更新会话信息，这里有两次写操作，所有设备共用这个信息。
拉取会话列表时，一次遍历会话列表操作，一次遍历新消息操作，故有两次读操作。
所以平均db访问时间复杂度为O(k)，k为常量4
群消息的会话列表机制db访问时间复杂度：
产生一条消息会为群里所有用户更新会话信息，有n次写操作。
拉取会话列表时与单人一致。
所以平均db访问时间复杂度为O(n+k)，n为群用户数，k为常量2。所以对于群的会话列表实现需要进行方案修改。
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
会话列表同步优化：
上述流程是
1.同步有过修改的会话列表，
2.同步新消息，再根据消息生成会话列表，
3.对1,2的结果做交集。
可以优化为
1.同步会话版本号比客户端请求中的版本号大的或者消息版本号比客户端请求中的消息版本号大的会话列表，
2.直接返回上述结果。
因为会话中的消息是最新的，只要满足(服务器会话版本>客户端会话版本 或者 服务器消息版本>客户端消息版本)这个条件，下发的会话列表一定是差量包含最新消息的。
