如何利用Linux构建免费的缓存DNS服务器

通常需要安装服务软件bind，Centos下：yum -y install bind 命令安装。

然后修改主配置文件：

cp /etc/namedconf /etc/namedconfbak

vi /etc/namedconf

//-------------------------内容为：-------------------------

options {

listen-on port 53 { any; }; // 监听在主机的53端口上。any代表监听所有的主机

directory "/var/named"; // 如果此档案底下有规范到正反解的zone file 档名时，该档名预设应该放置在哪个目录底下

// 下面三项是服务的相关统计信息

dump-file "/var/named/data/cache_dumpdb";

statistics-file "/var/named/data/named_statstxt";

memstatistics-file "/var/named/data/named_mem_statstxt";

allow-query { any; }; // 谁可以对我的DNS服务器提出查询请求。any代表任何人

recursion yes;

dnssec-enable yes;

dnssec-validation yes;

dnssec-lookaside auto;

forwarders { // 指定上层DNS服务器

119292929; //这里使用OneDNS主服务器

};

bindkeys-file "/etc/namediscdlvkey";

managed-keys-directory "/var/named/dynamic";

};

logging {

channel default_debug {

file "data/namedrun";

severity dynamic;

};

};

zone "" IN {

type hint;

file "namedca";

};

include "/etc/namedrfc1912zones"; //这里是自定义解析区域；

include "/etc/namedrootkey";

//---------------------结束---------------------------------

下面进行自定义解析：

vi /etc/namedrfc1912zones

//-----------自定义解析开始：-------------------------------

zone "yumaozdycom" IN { // 定义要解析主域名

type master;

file "xxxcomzone"; // 具体相关解析的配置文件保存在 /var/named/xxxcomzone 文件中

};

//-----------自定义解析结束：-------------------------------

编辑自定义xxxcomzone文件：

vi /var/named/yumaozdycomzone

//-----------自定义开始：-----------------------------

$TTL 86400

@ IN SOA nsyumaozdycom root (

1 ; serial

1D ; refresh

1H ; retry

1W ; expire

0 ) ; minimum

@ IN NS nsxxxcom

ns IN A 19216812

www IN A 19216813

bbs IN A 19216814

ttt IN A 19216815

//-----------自定义结束：------------------------------

以上，ns服务器ip即本机，www服务器ip即xxxcom主机……

　　根据一些专家的调查分析，发现企业在使用数据库的时候，90%以上主要用来查询。有些企业这个比例甚至更高。也就说，用户对数据库的操作，其实更新操作占的比例很少。大部分的操走都只是查询操作。

　　如一些论坛，大部分用户只会看贴，而不会发帖。这就是一个典型的查询操作比例大大超过更新操作比例的例子。针对这种情况，其查询操作往往是其数据库性能的瓶颈。如何有效提高查询的性能，这就使各个数据库专家在考虑的问题。在SQL Server数据库中，已经有了一个现成的解决方案。数据库管理员可以利用缓存服务器来提高数据库的性能。笔者这里就以SQLServer2008为例，谈谈如何利用缓存服务器来实现负载均衡，来提高数据库的查询效率。

　　一、 数据查询与数据更新分开走。

　　如上图所示，如果用户要查看某个帖子，其就会打开某个连接。此时WEB应用服务器就会从后台数据库中查询相关的记录。这里需要注意的是，由于其只是查看帖子，而不涉及到更新的操作，为此WEB应用服务器就只从缓存服务器中读取数据。这个缓存服务器中的记录跟数据库服务器的内容是同步的。WEB应用服务器在从数据库缓存服务器读取数据之前，还会先判断一下哪台数据库服务器比较空。会优先连接到比较空闲的数据缓存服务器中，然后从这台服务器中读取数据。所以，当访问这个论坛的用户比较多时，这个数据缓存服务器能够实现负载均衡的需要。

　　如果用户看了某个帖子，现在需要发表一个评论，此时后台数据库会怎么操作呢注意，当WEB应用服务器发送了一个 Update更新操作的时候，其应用服务器会自动连接到数据库服务器，而不会再连接到数据库缓存服务器。而是直接向数据库服务器发送更新操走的语句。当数据库服务器更新了相关的内容之后，会与数据库缓存服务器实现数据的同步。从上图中可以看出，整个数据查询与数据更新WEB应用服务器是分两条路走。其实这就好像是公路上分道行驶，机动车走机动车道;非机动车走非机动车道。

　　　　如此的话，就不会因为非机动车比较慢，而影响到机动车的速度。在这个方案中，将数据库的更新操作与查询操作分开来走，也是类似的道理。在查询时，数据流是单向流动的，所以能够在很大程度上提高查询的效率。从而让数据负载均衡的效果更加明显。总之，当某个应用程序查询操作大大超过更新操作时，通过在多个数据库间缓存只读数据，并在数据库间均匀连接客户端以分发负载，则就可以向外扩展工作负荷的读取分区，即实现负载均衡的目的。

　　二、 采用这个方案需要注意的地方。

　　在部署这个解决方案时，仍然有些数据库管理员需要关注的内容。如以下这些内容，数据库管理员需要根据企业的实际情况来进行调整，以提高这个方案的价值。

　　首先需要考虑数据缓存服务器与数据库服务器之间同步的频率问题。这个同步操作是一把双刃剑。若同步的频率太高，会影响数据库服务器与缓存服务器的性能;若同步频率比较低的话，则数据库缓存服务器中的数据得不到及时的更新。

　　如此的话，用户查询时可能在短时间内无法获取最新的数据。所以，一般来说，系统滞后的时间应该尽量的短，即数据库服务器的更新内容必须尽快与数据库缓存服务器进行同步。

　　理想的状态时，在更新数据库服务器的同时更新数据库缓存服务器。但是，这么做是以牺牲数据库与数据库缓存服务器的性能为代价的。为此数据库管理员在实施这个解决方案时，往往不会这么做。而是设置在一段时间之后同步。如可以设置为10秒、60秒、300秒或者更长的时间后进行同步。

　　具体这个同步的时间间隔多少为好，没有一个统一的标准。这需要数据库管理员根据企业对数据同步的要求不同而定。一般来说，数据库管理员在满足用户需要的前期下，可以将这个时间设置的相对长一点。这可以避免因为过多的同步操作而降低了这个方案的价值。其实，对于大部分用户来说，60秒左右的时间差异还是可以接受的。如在论坛中，一个人发帖后，在一分钟之后看到一般不会有什么问题。对于人的感觉来说，这个一分钟时间不长。但是对于数据库服务器来说，这一分钟可以做很多事情。所以，适当延长这个同步时间，却可以在很大程度上提高数据库服务器性能。这个时间的代价，有时候还是值得的。

　　其次，在数据库服务器与数据库缓存服务器之间，应该建立比较直接的、快速的网络连接。当用户比较多时，数据库服务器与数据库缓存服务器之间若发生同步操作，则会造成很多的网络流量。有时候同步操作发生时，影响这个工作的效率可能并不是数据库服务器或者数据库缓存服务器本身，而是他们之间的网络连接。

　　由于其可用的带宽跟不少数据库服务器系统的吞吐量，从而影响到了同步操作的效率。为此，在数据库服务器与数据库缓存服务器之间的网路连接，应该尽量的直接。如最好不要在中间夹着其他的不必要的网络设备;也最好不要在他们之间配备防火墙等安全策略。这些安全策略与网络设备都会在很大程度上影响到这个同步操作的效率。

　　另外，最好也不要有其他的应用服务来争抢带宽。所以简单的说，如果可能的话，在数据库服务器上部署多张网卡，直接与数据库源服务器实现双机互联，而那传输同步操作需要的数据，这是一个很不错的手段。由于其数据传输更直接、而且其他设备或者应用服务也会来争夺其带宽，同时又可以克服他们的非法攻击。为此，只要他们之间多距离比较短的话，采用这种方案可能效果会比较好，可以在最大程度内缩短这个同步操作所需要的时间，从而让其他用户尽早看到更新的数据。

　　第三为同步选择合适的复制方案。

　　那么该如何实现数据库服务器与缓存服务器之间的同步呢在SQLServer数据库中，有三个方案可供数据库管理员选择。这三个方案分别为快照复制、合并复制与事务复制。这三个复制模型各有各的特点。不过从最终效果来看，其都可以实现数据库服务器与数据库缓存服务器之间的同步。不过由于其内部的实现机制不同，为此其虽然结果相同，但是从性能等方面考虑，还是有差异的。

　　各种复制模型的原理与特点属于基本知识的范畴，笔者在这里就不做过多阐述了。笔者认为，在利用这个数据库缓存服务器来实现负载均衡的方案中，最好采用事务复制的同步方案。因为相比其他方案来说，事务日志能够满足事务的一致性、数据库服务器系统比较大的吞吐量、同步时尽量少的开销、以及系统比较短的滞后时间等等需求。

　　另外在有些企业中采用这个方案的话，还要考虑到表与记录的过滤需求。而通过事务复制的话，就可以实现对列和行的过滤。而其他复制模型的话，只能够部分满足这些需求。

　　　　所以，笔者认为，在选择数据同步方案时，可能选择事务复制来实现同步，更加的合适。不过最终是否真是如此，还是要求数据库管理员根据企业的实际需要，然后分别采用几个复制模型来进行测试，才能够得出真正合理的结果。

　　转载，仅供参考。

缓存指的是将需要频繁访问的网络内容存放在离用户最近、访问速度更快的系统中，以提高内容访问速度的一种技术。缓存服务器就是存放频繁访问内容的服务器。

帧缓冲存储器(Frame Buffer)：简称帧缓存或显存，它是屏幕所显示画面的一个直接映象，又称为位映射图(Bit Map)或光栅。帧缓存的每一存储单元对应屏幕上的一个像素，整个帧缓存对应一帧图像。

可刻录CD或DVD驱动器一般具有2MB-4MB以上的大容量缓冲器，用于防止缓存欠载（buffer underrun）错误，同时可以使刻录工作平稳、恒定的写入。一般来说，驱动器越快，就有更多的缓冲存储器，以处理更高的传输速率。

扩展资料

缓存工作原理

1、读取顺序

CPU要读取一个数据时，首先从Cache中查找，如果找到就立即读取并送给CPU处理；如果没有找到，就用相对慢的速度从内存中读取并送给CPU处理，同时把这个数据所在的数据块调入Cache中，可以使得以后对整块数据的读取都从Cache中进行，不必再调用内存。

正是这样的读取机制使CPU读取Cache的命中率非常高（大多数CPU可达90%左右），也就是说CPU下一次要读取的数据90%都在Cache中，只有大约10%需要从内存读取。

这大大节省了CPU直接读取内存的时间，也使CPU读取数据时基本无需等待。总的来说，CPU读取数据的顺序是先Cache后内存。

2、缓存分类

Intel从Pentium开始将Cache分开，通常分为一级高速缓存L1和二级高速缓存L2。在以往的观念中，L1 Cache是集成在CPU中的，被称为片内Cache。在L1中还分数据Cache（D-Cache）和指令Cache（I-Cache）。

它们分别用来存放数据和执行这些数据的指令，而且两个Cache可以同时被CPU访问，减少了争用Cache所造成的冲突，提高了处理器效能。

3、读取命中率

CPU在Cache中找到有用的数据被称为命中，当Cache中没有CPU所需的数据时（这时称为未命中），CPU才访问内存。从理论上讲，在一颗拥有2级Cache的CPU中，读取L1 Cache的命中率为80%。

也就是说CPU从L1 Cache中找到的有用数据占数据总量的80%，剩下的20%从L2 Cache读取。由于不能准确预测将要执行的数据，读取L2的命中率也在80%左右（从L2读到有用的数据占总数据的16%）。那么还有的数据就不得不从内存调用，但这已经是一个相当小的比例了。

在一些高端领域的CPU（像Intel的Itanium）中，我们常听到L3 Cache，它是为读取L2 Cache后未命中的数据设计的—种Cache，在拥有L3 Cache的CPU中，只有约5%的数据需要从内存中调用，这进一步提高了CPU的效率。

参考资料来源  -缓存

Web缓存提供了比将访问对象放在Internet Web服务器上更好的方法，它将需要频繁访问的Web页面和对象保存在离用户更近的系统中。当再次访问这些对象的时候加快了速度。

服务器开发的数据逻辑是指服务器端程序对数据进行处理和管理的过程。在服务器端，数据逻辑主要包括以下几个方面