网站的点赞怎么设计?(编程科普)
1804 2022-07-08 08:59
现在快节奏的生活。表达态度已经简单到喜欢和不喜欢。已经懒得争辩什么。给你个眼神自己体会。
所以很多论坛、弹幕、微博、几乎所有社交app,都有点赞的按钮。(有的还有差评、反对、投西红柿等负面按钮)。
那么观察一个网站的点赞设计,就可以看出一个网站在顶层设计是否用心。
最不用心的设计:不登录用户可以点赞。这种点赞就是图个热闹。早期的微信集赞活动。凑够100个朋友圈点赞,免单或者打折活动。促使了这部分无意义投票活动的疯狂流行。没有啥技术含量。而且网络投票现在也已经不被正宗官方所认可。因为用户本身就无法核实关联度。有的是被亲朋好友盲目拉来看也不看活动就投给了自己不认识的人,有的是雇佣网络水军,花几毛钱就能买到一个网络名额。甚至几分钱买个赞。正经的人气,从这些点赞数量上是不会反应出分毫的。但是由于操作简单、人人可参与。只是让每个人有些许获得感。为什么是些许?因为自己感受不到哪一票是自己的。自己也不知道是不是和对方的人机在进行PK。
补救的不记名投票:为了应对上一个模式带来的弊端,有的网站对投票的主机、浏览器、IP地址、频次等做了限定。也就是网站前端js写了几行代码,判断如果是重复投票,会被拦截一部分。换一个浏览器、刷一下IP地址、等上两三分钟,就又可以投票了。所以治标不治本。
登录后才能投票:稍微负责些的网站,开始使用基本信息认证的投票。就是首先要登录这个网站,然后才能有投票资格。
有痕迹可查的投票:在登陆后才能投票的基础之上,又对投票动作进行记录。记录你投票的ID以及时间,可以限定你每天只能投一次票、可以限定你每个账户只能投一次票。这已经算是比较靠谱的网站了。
高并发投票:当选手人气高的时候很可能碰到一秒钟之内获得几十万赞的情况,这时候已经不是考虑甄别真票假票的问题了。是考验系统设计能否支撑的起记录下这些操作的本领。有的系统因为设计上忙不过来,直接崩溃了。而有高并发、高可用、高稳定性的网站,除了在系统硬件上比较给力之外,必然还存在设计上用空间来换时间的机制。比如:限流、降级、熔断三大机制。这就涉及到全场唯一的一个数据。那就是点赞记录数。保存这个数据的变量,在某一个细小的时刻,只能被操作一次。这个操作,我们可以提取出来,让全系统只能唯一的调用它。只要他自己忙得过来,那么整个投票活动就不会崩溃,就是有效的。那么如何让他忙得过来,首先是他自己需要知道自己最需要的时间,没有人催他,所有等待这个操作的调用,都必须等他上一次完成之后才能得到他的青睐。而我们知道面向对象语言,方法都是在对象体内才能存活的,那么这个全场高光且唯一的对象,我们定义为单例。就是全场单单只有他一例,我们称之为Z先生。这样。所有人的请求,都要看他的脸色。他也就不用着急,按照自己的节奏,干完一单消一单。剩下的事情交给其他机制。比如。超时提醒。如果用户投票30秒没有反应,那么系统提醒他投票失败,并提供继续投票的机会。这期间就可以删掉很多Z先生处理不过来的任务,防止信息堵塞在家门口推不开门。系统仍然是畅通的。不会积累能量导致崩溃。还可以对用户进行降级,比如第一次投票30秒之后给第二次机会,第二次投票1分钟之后给第三次机会,第三次投票之后2分钟给第四次机会等等。还可以对用户进行熔断,比如,由于投票用户过多,请5分钟之后再试。等等。
多个单例投票:需要点赞的,除了主题、还有评论、那么把这两类投票分配给两个先生,Y先生和Z先生,那么Z先生的压力就小了很多。
可撤销的投票:有赠就有减。有后悔药可以吃。有的人就是当大家都喜欢的时候,反而觉得自己没那么喜欢了。那么撤销自己的投票。可以观察系统处理的效率。
以上通过点赞来观察一个系统是否是精心设计的,基于高并发大批量的数据涌入。平时的一次两次只能看出系统是否有合理的逻辑,并不能看出系统性能上做了哪些防御以及预案。
全部评论