场景：记录一个用户上次浏览图书的第几章第几节第几题,用 redis 还是 mysql 呢？

[yuyang1992test]

个人感觉不是一个重要的数据，比较倾向于用 redis,如果用 mysql 的话估计得分表了吧？ 表的数量=userCount * bookcount redis 的 key userID:{uid}:bookId:{bookID} val: '1-2-5', 表示第 1 章第 2 节第 3 题。 存的都是他们的 id

[xmai]

如果你需要读取性能和高并发，用 redis 。每个用户使用一个唯一的键名，如 user:{user_id}:book:{book_id}来记录其浏览位置，包括章、节和题号并将用户的浏览位置以字符串形式 ‘1-2-5’ 保存到 Redis 中。

如果你需要更加复杂的查询操作或者有较大的数据量，用 mysql 一把梭。

[libook]

高频读取用 Redis ，低频读取存数据库，不需要跨端就记录到客户端/浏览器本地，部分场景还可以记录到 URL 里。

[gulu]

KISS

[yuyang1992test]

@gulu kiss 是什么

[yuyang1992test]

@libook 这个数据丢失是不是可以接受的是关键

[XiLingHost]

这种没有固定的格式的，随意性比较大的数据，可以考虑用 nosql 比如说 mongodb 、es 之类的东西存，这些是有持久化的

[oneisall8955]

redis 一把梭，一般这种用户行为也会接上埋点，丢失数据能找回来，不慌

[yuyang1992test]

@XiLingHost 现在依赖的就只有 mysql 和 redis,不太可能为了这个需求引入一个中间件

[yuyang1992test]

@oneisall8955 那还设置过期时间吗

[bigbigeggs]

这种存图书的，后端怎么设计的。比如第一页的内容如何返回前端的，毕竟前端可能是小屏幕也可能是大屏幕，甚至可以伸缩等等，怎么分割呢

[yuyang1992test]

@bigbigeggs 我这边只存章节和题目，类似于教材答案

[yuyang1992test]

@bigbigeggs 小说的话一页一页的村吧，至于显示问题就是前端做适配了

[aLazarus]

我记得 b 站的 url 可以分享进度，多平台之间也可以同步进度，可能是 url+redis 的方式实现的？

[dongtingyue]

前端存储加 mysql 。redis 没必要吧。

[LouGaZen]

@yuyang1992test #4 Keep It Simple and Stupid ，取各单词的首字母

[picone]

用户本地存储。。

[yuyang1992test]

@picone 存到 app 吗？那 app 卸载重装是不是就没了？

[yuyang1992test]

@libook 那存到 app 的话，岂不是一卸载就没了吗

[yuyang1992test]

@xmai 没有复杂查询，也没有高并发

[yuyang1992test]

@picone 那卸载了不就没了嘛

[yuyang1992test]

@dongtingyue 那相当于书的详情一个接口，查询最后浏览的是一个接口，当前端存储没有的时候去请求？

[xmai]

@yuyang1992test #19 数据一直存在于 redis 中，可能会占用大量内存，redis 设置过期时间又会丢失用户浏览记录，如果确实需要长期存储还是 mysql 吧

[yuyang1992test]

@xmai 也是，内存要比硬盘贵

[libook]

@yuyang1992test #18 我回复说了，看具体使用场景。

我们做的 APP 中有些书签功能就是记录在本地的，因为用户并没有跨端同步的诉求，而且多人共用的个别功能用户还要求不要多端同步。

如果你的产品设计上需要可靠保存这个信息，就记录到服务器上，如果不需要可靠保存，就没必要浪费服务器的空间和算力。

需要可靠保存的话，存在 Redis 里还需要给 Redis 做持久化，或者复制一份给数据库，否则 Redis 重启数据就丢失了。

你的需求有很多实现方案，具体用哪一种取决于你的详细需求。