感谢诸位，对我找房子也有参考价值。

我这里想拉取的列表是比如现在有几个聊天好友的列表。而不是聊天消息。

如果分页，肯定牵扯到数据到变化，比如我分到第三页，有一个数据叫张三。这时候，数据变化，我分到第四页，又查到了这个张三的数据。（服务端数据变化）


那如果维持一个 list 列表，每次拉取数据，放 list 列表处理，这个容量限制呢？

@xuanbg 你这个魔改的分页，假设你在第三页找到会话。。。 从这里开始我就不明白什么意思了。
下边是微信 sdk 的说明

```
由于本地会话可能很多（例如超过 500 个），一次性全部加载完毕可能会耗时很久，导致界面展示比较慢。为了提升用户体验，getConversationList() 接口支持分页拉取能力：

首次调用 getConversationList() 接口时，可以指定其参数 nextSeq 为 0，表示从头开始拉取会话列表，并指定 count 为 50， 表示一次拉取 50 个会话对象。
IM SDK 按照从新到旧的顺序拉取会话列表，当首次拉取会话列表成功后，getConversationList() 的回调结果 V2TIMConversationResult 中会包含下次分页拉取的 nextSeq 字段以及会话拉取是否完成的 isFinish 字段：
如果 isFinished 返回 true，表示所有会话已经拉取完成。
如果 isFinished 返回 false，表示还有更多的会话可以拉取。此时并不意味着要立刻开始拉取“下一页”的会话列表。在常见的通信软件中，分页拉取通常由用户的滑动操作触发的，用户每下拉一次会话列表就触发一次分页拉取。
当用户继续下拉会话列表时，如果还有没有拉取下来的会话列表，可以继续调用 getConversationList 接口，并传入新一轮的 nextSeq 和 count 参数（数值来自上一次拉取返回的 V2TIMConversationResult 对象）。
重复执行 步骤 3 直至 isFinished 返回 true 。

```

那如果不分页的话，如果会话比较多怎么处理

@philonic 客服系统会话列表你哪里怎么处理呢，现在牵扯分页问题

@zibber 感谢

@zibber 可以推荐下你用过比较好的，现在从 php 转 go 。
私底下先走通下。

明白了，谢谢大家
```
writermem responseWriter
Request *http.Request
Writer ResponseWriter

```

比如 hash 保存用户信息，以前帖子有提示容易做成热 key 和大 value 。这个大 value 指的是 hash 里边所有的值呢，还是单纯的 key field

就比如用户信息，我可以存 string,也可以存 hash 。
这之间的取舍，还不太清晰。

@NoString 广告行业其实还是比较不错的，对性能要求也比较高。
而且广告系统更多的还是业务和技术之间的取舍。

广告行业里边大数据就是你现在做的工作。统计广告最终消耗金额，统计各自点击，展示数据。然后入库。

@谢谢大家，我再思考思考

@liushaokang

好友记录表主要记录该客服接待的线索。
系统流转表可以理解成日志

你提供的思路还是非常好的，给人耳目一新感觉。

@liushaokang 对，要的就是这种效果。

简而言之，就是把针对这个用户会话。从客服 A 身上转移到客服 B 上边。
那牵扯到 A 客服的主键 ID 都要替换成客服 B

这需要操作的表数据就比较多了。

不太清楚你说的统计和分析到底是怎么一回事