本帖最后由 roj234 于 2021-8-24 21:57 编辑

首先，解锁卡不能取消非常正常，比起政治原因，我觉得也有数据量的问题
旷工水馆按发帖时间排序要bbs的服务器处理0.7s ( 看底下, 还是有redis的情况

既然有了redis，何不搞一个“解锁缓存”

当你使用解锁卡的时候，把这个帖子加入缓存
缓存有大小限制，按QPS定，比如50
这里不要太大，我的北师大版数学书上说了个分机问题，说啥1000个用户要95%概率能要到分机要几个分机
那么，这里同样可以说： 我保证你解锁的帖子 95% 概率 接下来 n 分钟不要解锁卡

这个缓存全站共享，有同时查看这个帖子的就不要解锁卡了 （可选，毕竟没几个人会去看）
缓存除了保存帖子内容 还保存用卡的时间

删除缓存机制：
   新的解锁的帖子挤掉了这个帖子
   超时
   用户手动点击按钮取消 （可选，好吧，我觉得没人会去做这个按钮

这样我们就可以方便的翻页，然后搞不好这种情况都可以有 （人少的话）
我下午解锁了个插件，晚上把配置改炸了，又去看，结果还没锁

END
哦，再补充下，我觉得可以不要考虑同步啊，锁啊之类的问题，多几个帖子又不会怎么样,并发再多也不至于两指令一瞬间来几百个用解锁卡的吧

还有个问题：旷工水馆那么多帖子何不删掉一点

删掉了你的经验不就没了一贴2经验，而且回复也有1/3经验

本帖最后由 roj234 于 2021-8-24 21:32 编辑

删数据库的数据就好了，你的积分又不是即时计算
而且如果有积分记录的引用问题一并删除不就好了
或者加一个“已被删除的帖子”的积分来源
==============================
就打开这个页面，触发了28条SQL查询...
我又试着开了一个锁住的帖子，第一次也是28条，后面就是19条
我又试着开了一个回复不少的帖子，是47条
我不知道这么多sql怎么来的，离谱
这里给个不知道有没有用的建议，毕竟discuz的代码没仔细看过
获取用户信息的话可以试试把uid塞一起？
select * from user where id = 3

select * from user where id = 4

select * from user where id = 5

===>

select * from user where id in (3, 4, 5)


还有，编辑器老是莫名其妙的少掉几个换行

比起政治原因，你觉得还是数据量的问题？
难道为了流量真的可以违反政策？
你难道以为说着玩的吗？

我只是陈述而已

我不否认可能有内容会违反政策

但是你觉得给几十万个数据排序很简单么

也许我说的绝对了，应该叫“双方面的原因？”

帖子删不删除不能看是不是水贴，除非违反了对应规定才会被删除，否则就算是发卡也不能删除帖子，如果只是因为占地方或者什么流量的问题早就删了

限制了分页数的。而且对于数据库来说，几十万个数据排序很难？

那为什么旷工水管按照发帖时间排序要0.7s的执行时间，其他页面都是0.0x秒呢

本帖最后由 xmdhs 于 2021-8-24 23:18 编辑

discuz 可以对不同的地方设置不同的缓存时间，排序是没有设置的，如果你观察够仔细的话，可以看看你发出去的帖是不是不会第一时间出现在列表里。且即使是锁帖了，又不是从数据库中移除，减轻了什么服务器压力？

即使服务器真的负载不起，也应该是加机器，而非删除数据，尤其是对于论坛。（就是锁帖这种，发帖者之类的都很难接受了，用这种理由删帖是要人换一个地方发内容吗。你能判断茶馆里那么多帖子什么是有价值什么是没价值吗，为的就是按时间排序时能快零点几秒？）

你可以自己下载一个 discuz 玩玩，虽然 mcbbs 不会完全一样，但是至少也要先了解一下再去提这方面的建议。

论坛目前的解锁是热力值，完全可以解锁后翻页。

嗯，我去试了试，确实可以翻页了，那么这个帖子也没啥意义了
不过之前确实有帖子不行... 算了，不去管它

本帖最后由 SHEEP_REALMS 于 2021-8-25 10:16 编辑

百万级别的数据排序对数据库来说毫无压力，缓存和运算才是论坛的主要压力。
如果没有分页查询，炸的应该是客户端而不是服务器，如果你网络流量足够的话（
论坛底层在列出主题列表时还会预加载最后几个回帖，最次的挨个查一次，优化一下整个主题列表不包括附加信息的获取两次查询就能完成，根本不存在数据压力。不过考虑到Discuz!屎一样的代码我们就当它查了26次好了。
矿工茶馆首页有缓存，而排序页没有缓存，所以就出现了响应时间的差异。

已阅，解锁早已改为根据热力值了的。