简书自动保存功能的实现原理分析
微wx笑
2022-06-14【网页网站】
2
0关键字：
简书 自动保存
简书自动保存功能的实现原理分析写文章的页面，打开开发者工具，编辑文章，会看到每次修改文章内容时，基本上不到一秒不操作，如果文章内容发生了修改，就会执行一次put请求Request URL
简书自动保存功能的实现原理分析
写文章的页面，打开开发者工具，编辑文章，会看到每次修改文章内容时，基本上不到一秒不操作，如果文章内容发生了修改，就会执行一次put请求
- Request URL:https://www.jianshu.com/author/notes/93806368
- Request Method:PUT
- Status Code:200 OK
- Remote Address:47.92.108.93:443
- Referrer Policy:strict-origin-when-cross-origin
请求发送的数据包括：
虽然是有版本，但是每次修改并不是差异性提交，而是把所有文章内容都提交到了服务器。
那他们的服务器上是怎么存储数据的呢？
每个版本都是保存的完整的数据吗？如果是这样的话，那要多占用多少数据库存储空间啊！
如果不是，那是怎么实现的呢？内容提交到服务器之后再做对比，再进行处理吗？
每次修改都提交完整的内容，这对带宽也是很大的浪费啊。
创建文章时一共有四个请求
请求发送的数据
响应内容
很奇怪为什么新建的文章内容肯定是空的，却要执行一次获取文章内容的请求
- Request URL:https://www.jianshu.com/author/notes/102808414/content
- Request Method:GET
2022-06-28更新
发现每次修改排序的时候，都是提交整个ID列表，后台是怎么实现的呢？
猜测可能是把ID都存储在一个字段里了，
大公司，应该会做这方面的架构，有可能ID顺序给每个人建个缓存
每次取数据，先从缓存取出ID,然后按ID从库中取
按主键ID从库中取，是性能最佳的
select * from table where id in (idstr)
select in() 的方式会不会影响效率呢？
in传递的值有索引的话效率应该是很高的，还有什么方式比直接通过索引查询快呢？
当然，传递的值比较大，其内部实现也是要循环的。
这可以通过分页来控制。
另外，参考“探讨select in 在postgresql的效率问题”，只有在in内数据到了10，000个的时候执行时间会有比较大的变化，但也不过是在300多ms内完成。
本文由 微wx笑 创作，采用 署名-非商业性使用-相同方式共享 4.0 许可协议，转载请附上原文出处链接及本声明。
原文链接：https://www.ivu4e.cn/blog/web/2022-06-14/1239.html
