关于CNBeta的投票机制问题
今早由于刚才那篇文章，我投了一票，结果我发现这投票大有猫腻，明明是只有39票支持，我一投后，马上就变成了60票。。（这不坑人吗？）我无语，然后马上去找其它评论来投票试试，以下是投票前后
投票前 | 投票后
3 | 6
11 | 19
114 | 139
26 | 39
29 | 40
0 | 1
0 | 2
0 | 1
1 | 2
1 | 5
1 | 6
完全无规律性，而且在0票的进候，我分别投了三次的结果完全不一致。。当时我觉得他是否是来了一个随机函数来扩大网站的人气支持.
但细想一下，CNBETA应该不会如此儿戏，这种情况或许有其客观存在原因。
我感觉是缓存与数据交换的真空问题
在这个设想的基础上，我做了一个操作，我看到一个评论当前票数是6票，那么我就去投了一票，结果显示是9票，然后我刷新一下网页，当前评论仍然是6票
这个操作后，刚才的断言的可能性变得相当的大
在 一般的缓存级别服务应用中，用户对于网站的访问所得的请求数据来源于CACHE服务器，这段数据可能是服务器持久层中常驻内存的数据或是专门的缓存单元， 而CACHE服务器会在特定的时间间隔去向DATA服务器更新数据，从而达到数据的同步性，但一般越是海量的数据服务器，这个间隔越大，有些甚至是24小 时或更多，比如移动的报表系统。当然用户一般情况下不能和DATA数据服务器打交道，但是会有特殊的请求事件会与 DATA服务器直接通信，而本文所说的那个投票机制问题就出在此次。
CNBETA的数据访问量在国内是相当大的，所以他一定会有自己的缓存单元服务器和数据交换服务器，而一般情况都是如图所示的简单模型的扩展，像 CNBETA的数据访问量是如此之大，频繁的更新缓存会在很大程度上造成服务器极大的压力，而这段时间间隔造成的缓存与真实数据的差别就无可厚非了。更何 况，CNBETA为了网站安全起见，对缓存单元全部设为只读级别，那么意味着缓存的变更唯有数据服务器的推送触发。
而我们在投票这个功能上，因为采用的是AJAX机制，在这种机制下，只能从DATA服务器上读取数据，这样我们看到的其实是真实结果，但是页面数据全来自 于CACHE服务器，在刷新之后，数据又再次“回滚”。而对于这种不是“BUG”的BUG，我想CNBETA工程师或许早已发现，但是却没有一个最优解， 这种问题也算是矛与盾的交集，也就是缓存与数据服务器的真空问题。
对于这个问题，有几个前提必要条件：
1. AJAX投票功能正常使用，返回值为真实值
2. 一定要采用缓存
3. 保障服务质量
在以上三点的前提下，这个BUG的解决就有点烦人了
CNBETA 对于数据的获取很可能是用的LAZY=false模式，这样去主动在缓存中去查找所有关联数据集展现出来，如果要消除这个BUG，无可厚非的要使用户刷新 时去主动获取DATA服务器当前的真实数据，但这样一来，CNBETA会惨不堪言。而正如一些砖家所说，最大可能的减少数据并发数，增加数据索引关系，加 强数据逻辑性，是解决高并发高压力的大型WEB站点的王道。。。。
想起曾经的博客园的访问速度一度变的相当的慢，追根溯底却仅仅只是因为STRUTS的配置文件上全部用‘*’来声明，虽然这种声明方式很省事，却极大的增 加了APACHE的压力，当访问量增多，路径变多的时候，APACHE会一次又一次的全局搜索所有可能匹配的路径和方法，再好的服务器在这种情况下，服务 质量都会变的惨白。。
WEB远远不只是网页这么简单。