[计数] 请问在论坛里怎么计算每个帖子的点计量的？？

powerpolly

SATAND兄的广开思路是正确的，很多东西都不是唯一解，我们不应该老是学习学习学习再学习，应该按自己的想法做点事情。

SATAND

原帖由 "wangyih" 发表：


人家两位都说的那么清楚了，这世界上那有什么同时在线过万的bbs
象你说的如果是访问量很大，而且没有钱构架服务器群，那呢只好放弃计数
其实我想真的这样要放弃的很多，不光是计数。没准直接改成留言板
我们只..........

我自97年开始接触技术，99年结束技术生涯
最后的作品就是 php+gnu c+inbuilt mysql 的网关
之后，准备写诗
呵呵
写诗是吃饱了撑的没事做的人的乐趣，比如Q君，自称诗人。当然，他比我有钱而且比我多一个老婆，我想也正是有了老婆后的幸福与枯燥造就了他的“吃饱了撑的没事做”
我发现自己没有足够的钱去写诗，连泡姑娘的钱都不够用，所以大部分时间还在跟coder打交道，无聊的时候写写情色小说，那个只需要生活就够了，不需要钱和激情
我了解年轻人的浮躁，和承受鼓励后的负荷，而且，有些羡慕

SATAND

原帖由 "powerpolly" 发表：
大家好，
      neoanthropic的一篇贴子看来引起一番唇枪舌剑，两位仁兄各执一词都有一定道理，我这里也补充一下，象贴子计数、网页点击量等涉及到“大量”计数单位的问题，目前普遍采用数据库。我于是提出几个焦点..........

同意你的前提，却不同意你的结论。

1,update=select+io....|
...................................|  =>;>;    select==update
2,select>;>;io...............|

但是上述结论的前提是一次select同一次update比较。
有个问题：select是协议锁，可以多线；update是互斥锁，必须锁定全表、独占并安排队列。

两位老兄一直提到“现在常用”这个词语。现在常用并不一定代表了真理，只是一种不可替代的、权衡后比较有利的权宜之计罢了。
说实话，我推崇的用文本计数，不能超过几十个页面的，否则会有大量的、不可预料内存开销，这点我已经自己测试过了。我再次通读了firebird的代码，发现即便如此强悍的文件公告板系统，没有、也是不能加入帖子访问量计数：它要应付艰苦的环境（没有集群，没有分流）下的大访问量（同时在线过万）。
论坛从bbs分离出来，无所谓进步退步，各有所需。比如在教育网，水母和糊涂就只能用bbs而不能用论坛，如果你们没有维护过，根本不能理解同时在线上万人是怎样的情形。再比如网易，同时在线量也不小，但是他们不能选择telnet的bbs，因为面向社会上的网民，没有那么多人能够控制telnet。幸运的是，网易有钱，所以他们可以通过集群进行分流。

如此，问题应该这样分析：如果有一个论坛（个人性质的），访问量不大，那么数据表计数比较合适。如果是访问量很大（似乎不太可能），而且没有钱构架服务器群，那呢只好放弃计数，无论你用php还是jsp还是cgi-bbs。

我们再看怎么设计数据表计数：
默认，
select == update >;>; io
那么，不考虑io，以不影响访问有效信息（帖子）为重点，将计数的开支从访问中分离出去，也就是说我们来建立一张关联帖子id和counter的表，每次访问，相当于操作2张表，io（2）开支为io（1）*2*y（y为校正参数，1<y<2，毕竟度量张表不同于简单的累加），相对于select和update，依然可以忽略。
如此，在浏览方面，文章数据表就没有写入操作了，只有可以并发的select。而另一张计数表，则需要在每次浏览时作update操作。帖子的计数不要直接写在文章输出脚本里，而是通过inframe插入，或者js切入，如此，即便计数一时读不出来，也不会影响帖子的浏览——而这，才是需要重点保证的。

或者，我们的思路都太局限了，应该用完全不同的方式解决。
如果经典的就是不可颠覆的，那么，我们怎么能够进步呢。
如果我们站在代码前线的人都不能创新，那么国软又怎能赶英超美呢。
：）

powerpolly

大家好，
      neoanthropic的一篇贴子看来引起一番唇枪舌剑，两位仁兄各执一词都有一定道理，我这里也补充一下，象贴子计数、网页点击量等涉及到“大量”计数单位的问题，目前普遍采用数据库。我于是提出几个焦点：
      A》凡涉及大量需要计数的对象只可能考虑在数据库里实现；
      B》update包括一次select和一次I/O；
      C》同时的多个请求可以在单独进程执行；
      D》查询请求的执行通过“游标”进行，每个查询ID都有自己的游标，游标实质是一个指针，update操作通过当前指针进行。
      如果不同意上述几点，您不必看下面的文章。
      对A的说明：
         如果只是少量计数单位如部分网页需要计数点击量，完全可以用读写文件来实现，不必大动干戈用数据库，但对于贴子而言，任何一篇贴子均要计数，从几十万到成百上万的贴子规模来看，用读写文件显然是不明智的，又因为贴子都是放在库里，所以只考虑用数据库实现。
      为简化问题，可以假定现在只要求找到一个贴子并显示贴子内容并且还要更新点击量字段，于是我们向DB提交Select，游标指针定位于该记录，于是取出用于前台的数据，并update点击率字段，前面已说明update包括select过程和I/O过程，而此时的游标正指向该记录，所以不必再select，直接I/O，到此，问题的焦点集中在select和I/O谁开销大的问题。
   I/O的开销，包括I/O队列等待、磁盘寻道、读写指定扇区的时间， 大家应该很清楚I/O时间几乎是固定不变，这里无需多说，数据库服务器一般都是高速SCSI接口，读写速度是普通IDE接口（10ms以下）的n倍以上，再看select的开销，容易理解的是：随着贴子数的迅速增加，哪怕最顶尖的服务器，从几十万、几百万的贴子中进行一次select至少在10~100ms级，各位可以亲自检测一下自己的服务器响应时间，由此得出结论是
      select的开销>;>;I/O开销。
      即update开销远小于select开销（条件是先进行select），这个结论应该可以说明楼主所述的问题，关于这个问题希望到此为止，再进行下去无非是口水战。也希望借这个机会能交一些朋友，共同进步。

SATAND

sina是支那的发音吧
而且前几天盛传的那个流言说只要在sina的论坛谈论sina与支那的意思就会被封
我试过，结果我的免费信箱都不能用了

jhsea3do

谁说sina是日本的东西了....