菜单

MySQL中达成高质量高并发计数器方案(举个例子小说点击数)

2019年6月6日 - sqlite

MySQL中达成高质量高并发计数器方案

   未来有无尽的连串,对计数器的落到实处甚是随便,举例在促成网站作品点击数的时候,是这样设计数据表的,如:”article_id,
article_name, article_content, article_author,
article_view……在article_view中著录该小说的浏览量。诈1看就好像寻常。对于小站,比如本博客,便是那般做的,因为小菜的博客难道会涉及并发难题吗?答案明了,一天非常的少IP,而且未来不会十分大。

  言归正传,对小说资源音讯类为主的品类,在浏览1个页面包车型地铁时候不止要进行大量的查(查询上文的记录,已经所属分类的名字、紧俏小说资源信息商议、TAG等),还要进行写操作(更新浏览数点击数)。把稿子的详尽内容和计数器放在一张表就算对开垦很有益于,不过会形成数据库的压力过大(不然怎么大品种都要分库分表呢)。

  那么,分两张表存放就好了么?一张表存小说详细信息,另一张表单独存计数器。

  代码如下:

  CREATE TABLE `article_view`(

  `article_id` int(11) NOT NULL,

  `view` int(11) NOT NULL,

  PRIMARY KEY (`article_id`)

  )ENGINE=InnoDB;

  这种格局,尽管分担了文章表的压力,不过每当有二个进程请求更新的时候,都会发生全局的互斥锁,只好串行,不可能互相。在高并发下会有较长的等候时间。

  另一种比较好的办法是对每二个文章的计数器不是单排,而是多行,例如吧,一百行。每趟随机更新当中一行,该小说的浏览数正是全部行的和。

  代码如下:

  CREATE TABLE `article_view`(

  `article_id` int(11) NOT NULL,

  `pond` tinyint(四) NOT NULL COMMENT ‘池子,就是用来随机用的’,

  `view` int(11) NOT NULL,

  PRIMARY KEY (`article_id`,`pond`)

  )ENGINE=InnoDB;

  小访问量的自由池子9十八个自然多了,三五个足矣。每趟访问的时候,随机贰个数字(1-十0)作为pond,怎么样该pond存在则更新view+一,否则插入,view=1。借助DUPLICATE
KEY,否则在先后里是促成得先SELECT,推断一下再INSERT大概UPDATE。

  代码如下:

  INSERT INTO `article_view` (`article_id`, `pond`, `view`)
VALUES (`123`, RAND()*100, 1) ON DUPLICATE KEY UPDATE
`view`=`view`+1

  获取钦点作品的总访问量的时候:

  代码如下:

  SELECT SUM(`view`) FROM `article_view` WHERE
`article_id`=’123′

  PS:凡事都以双刃剑。为了更加快的读大家一般要殉国局地事物。在读对比多的表要加速读的进程,在写较多的表要加紧写的速度。各自权衡。在加快读的快慢的时候,大家就义的并不只是写的属性,还会有开采费用,开采变的更复杂,维护资金财产等。所以并不是读的快慢越快越好,供给找三个平衡点。

http://www.bkjia.com/Mysql/900360.htmlwww.bkjia.comtruehttp://www.bkjia.com/Mysql/900360.htmlTechArticleMySQL中实现高性能高并发计数器方案
今后有无数的体系,对计数器的落到实处甚是随便,举例在完成网站小说点击数的时候,是这样设计数据表…

今日有过多的项目,对计数器的兑现甚是随便,比方在贯彻网址小说点击数的时候,是如此设计数据表的,如:”article_id,
article_name, article_content, article_author,
article_view……在article_view中著录该小说的浏览量。诈一看就像从未难题。对于小站,譬喻本博客,正是这么做的,因为小菜的博客难道会涉嫌并发难题吧?答案明显,一天没有多少IP,而且事后不会十分的大。

言归正传,对小说资源新闻类为主的品种,在浏览2个页面包车型大巴时候不但要开始展览大量的查(查询上文的笔录,已经所属分类的名字、火爆作品资源音信斟酌、TAG等),还要实行写操作(更新浏览数点击数)。把稿子的事无巨细内容和计数器放在一张表固然对开辟很方便,但是会招致数据库的压力过大(不然怎么大品类都要分库分表呢)。

那正是说,分两张表存放就好了么?一张表存小说详细音信,另一张表单独存计数器。

复制代码 代码如下:

CREATE TABLE `article_view`(
`article_id` int(11) NOT NULL,
`view` int(11) NOT NULL,
PRIMARY KEY (`article_id`)
)ENGINE=InnoDB;

这种艺术,即使分担了作品表的下压力,但是每当有二个历程请求更新的时候,都会产生全局的互斥锁,只好串行,无法相互。在高并发下会有较长的守候时间。

另壹种比较好的艺术是对每三个小说的计数器不是单排,而是多行,例如吧,一百行。每一次随机更新在那之中一行,该小说的浏览数正是全部行的和。

复制代码 代码如下:

CREATE TABLE `article_view`(
`article_id` int(11) NOT NULL,
`pond` tinyint(4) NOT NULL COMMENT ‘池子,正是用来随机用的’,
`view` int(11) NOT NULL,
PRIMARY KEY (`article_id`,`pond`)
)ENGINE=InnoDB;

小访问量的妄动池子九二十个肯定多了,三多少个足矣。每便访问的时候,随机三个数字(一-十0)作为pond,怎样该pond存在则更新view+一,不然插入,view=一。借助DUPLICATE
KEY,不然在程序里是贯彻得先SELECT,判定一下再INSERT大概UPDATE。

复制代码 代码如下:

INSERT INTO `article_view` (`article_id`, `pond`, `view`)
VALUES (`123`, RAND()*100, 1) ON DUPLICATE KEY UPDATE
`view`=`view`+1

获取钦命作品的总访问量的时候:

复制代码 代码如下:

SELECT SUM(`view`) FROM `article_view` WHERE
`article_id`=’123′

PS:凡事都以双刃剑。为了越来越快的读我们平常要就义局地东西。在读相比较多的表要加紧读的进度,在写较多的表要增长速度写的速度。各自权衡。在加速读的快慢的时候,大家就义的并不止是写的习性,还会有开拓开销,开采变的更复杂,维护资金财产等。所以并不是读的快慢越快越好,必要找三个平衡点。

您也许感兴趣的稿子:

相关文章

发表评论

电子邮件地址不会被公开。 必填项已用*标注

网站地图xml地图