如何实现一个支持海量大并发的服务?

开发 前端
通过这样一个分布式的分层架构,海量的域名解析请求就被分摊到至少4层主机中了,再配合本地域名服务器的缓存,整个DNS系统中每台服务器的实际压力都会减少很多。于是看起来很恐怖的并发量,在众多服务器以及缓存的共同支撑之下,就显得不是那么困难了。

一、前言

提到“海量大并发”,一般人首先想到的也许是春运期间的“12306”,或者曾经风光无二的“天猫双十一”。尤其是12306,据说其在春运期间的QPS(Queries-per-second 每秒查询率)达到100万。

然而,无论“12306”或是“天猫双十一”的并发有多高,其都注定无法超越另一个网络服务的并发量,它们再大的并发都只能算这个服务所承受并发的一部分,甚至可能还是比较小的那部分,这个服务就是:DNS。

DNS为全球所有的互联网(Internet)用户提供域名解析服务,这些用户除了自然人,甚至包括大量自动运行的程序。DNS服务对互联网而言,如同空气一样重要,又如同空气一样无形。它是如此稳定而透明,就像不存在一样,实际却承受着几乎全世界最大的并发压力,而且是一年365天,时时刻刻都承受着。

而无论是“12306”还是“天猫双十一”,它们所承受的并发再大,终究是要通过请求域名的方式来进行,所以它们的压力只会是DNS系统所承受压力的一部分。所以,如果你想研究“海量大并发”,不用看那些“解密12306”的文章,踏踏实实把DNS的原理搞透彻,这"海量大并发"的绝世武功基本就是你的了。

二、关于DNS

那DNS是怎么做的呢?

要支持如此巨量的并发,可以肯定的是,仅仅依靠软件是不够的,还需要相配套的硬件支持。所以首先需要足够数量的服务器,并将其广泛架设在用户群体之中,这里的第一批服务器就是“顶级域名服务器”。

顶级域名服务器是一个集群,整体而言就像一个“内阁”,这个内阁会服务于一位皇帝,而这位皇帝就是“根域名服务器”。严格按照DNS系统来说,其实不止一位“皇帝”,即根域名服务器其实也远不止一台,这里为了简化模型就假定只有一个。

每台顶级域名服务器就是“内阁大臣”,它们共同分担皇帝的压力。但内阁是直接辅佐皇帝的,并不直接承担业务压力,所以在顶级域名服务器之下,又有一个集群,那就是“权威域名服务器”。

权威域名服务器就像设置在各个行省的“总督”,每个总督直接负责自己的一片区域,接受该区域的用户进行域名注册,并对这些域名提供解析服务。但即便是这些权威域名服务器,除了接受域名注册请求外,一般也不直接对普通用户提供域名解析服务,而是交由“本地域名服务器”来做。

图片图片

可是用户的域名注册信息都在“权威域名服务器”中,他找“本地域名服务器”做解析服务,后者怎么知道对应IP呢?

在开始时它当然不知道,所以本地域名服务器会直接上奏“DNS皇帝”这个情况,即直接请求根域名服务器。

以abc.com域名为例,根域名服务器收到某个本地域名服务器的解析服务请求后,它可以通过abc.com这个地址的顶级域名com得知负责此域名的顶级域名服务器,于是就会将域名解析请求转给它。

顶级域名服务器通过abc.com这个地址的abc查询,得知这个二级域名当初是交给哪个权威域名服务器管理后,就将解析请求交给那个权威域名服务器。于是这个权威域名服务器再查看普通用户在它这里的注册信息,于是找到abc.com对应的IP,将其返回给顶级域名服务器。

接下来顶级域名服务器将结果继续返回给根域名服务器,根域名服务器再返回给本地域名服务器,本地域名服务器最终将结果IP返回给用户主机。

图片图片

在这种方式中,本地域名服务器只用和根域名服务器打交道,叫“递归查询”,但它不是唯一的查询方式。

还有一种方式是,根域名服务器在得知负责abc.com这个域名的顶级域名服务器的IP后,会直接返回给本地域名服务器,让本地域名服务器自己去请求顶级域名服务器,而不是代为请求。后面请求权威域名服务器也是同理,这种方式就叫“迭代查询”。

图片图片

本地域名服务器在获知用户abc.com这个域名的IP后,一方面它会将结果返回给用户主机,另一方则会将此结果缓存,这样下次有用户再请求这个域名时,它就可以直接返回结果了。

这里必须着重强调下缓存,它是整个分布式架构中的重要组成部分,是分担系统压力的重要机制。

通过这样一个分布式的分层架构,海量的域名解析请求就被分摊到至少4层主机中了,再配合本地域名服务器的缓存,整个DNS系统中每台服务器的实际压力都会减少很多。于是看起来很恐怖的并发量,在众多服务器以及缓存的共同支撑之下,就显得不是那么困难了。

三、总结

DNS的域名解析服务可以如此处理,其他各种类型的服务亦是如此,区别只是并发请求的内容,但应对并发本身的手段是可以相互参考的。

责任编辑:武晓燕 来源: Web学社
相关推荐

2022-05-22 13:55:30

Go 语言

2022-06-09 07:07:35

服务GPUbatch

2023-09-08 08:22:30

2023-09-08 08:10:48

2020-03-02 17:00:24

程序员数据库MySQL

2022-08-08 20:48:09

MQ消息中间件系统解耦

2022-08-10 06:52:28

RabbitMQ消息中间件

2022-08-08 20:46:26

架构高并发

2017-12-12 15:24:32

Web Server单线程实现

2024-04-24 11:42:21

Redis延迟消息数据库

2014-04-14 15:54:00

print()Web服务器

2022-03-14 10:02:03

散列表链表哈希表

2016-09-28 17:34:27

JavaScriptvueWeb

2022-03-24 14:58:02

Java散列表编程语言

2011-06-01 10:59:59

Oceanbase海量数据库

2022-09-13 08:01:58

短链服务哈希算法字符串

2021-05-20 13:22:31

架构运维技术

2019-08-01 08:36:51

缓存系统并发

2024-05-09 10:26:14

2020-08-17 08:20:16

iOSAOP框架
点赞
收藏

51CTO技术栈公众号