我们有一个用例来caching3亿多条这样的数据，每个数据都有一个唯一的密钥。
我知道这是非正统的，但是，在我们公司已经提出，DNS可以用作小（<512字节）数据段的快速分布式caching。
DNS条目将是{Key}。{散列键模块} .mycompany.local。
即U5333145311.1.mycompany.local
我们会以每秒5000到7500的速度从10到15台服务器发出请求。
我们将通过区域文件更新每个DNS服务器。
因为我是程序员，这对我来说都是新的
谢谢
更新：数据是1到30整数（不是512K抱歉），所以它是非常小的数组。 我的CTO来自networking运营，就像这个解决scheme，因为它是一个已知的成熟的系统，具有内置的容错能力，他可以使用networking操作来pipe理它。 我很谨慎，但很开放。
DNS在某些情况下是有意义的：
广泛分布的数据
例如，DNS黑名单是有效的，因为高速caching基础设施已经存在于用户附近（即他们的ISP），或者对于大用户，他们可以很容易地运行像（rbldnsd）这样的定制软件。 不过重要的是它利用了现有的广泛部署的协议。
小反应（最多约500字节）
人们通过DNS分发的大多数有趣的东西都很less，甚至通常只要logging的存在与否就足够了（例如DNSBL指示IP地址不好，或者表示这个文件的校验和是坏的）。
我写这个： https ： //dgl.cx/wikipedia-dns ，它几乎推动了你可以安全地在DNS中做响应大小的限制。 不是每个人都实现或支持EDNS0，正如其他人所说，一旦你回到TCP无国界消失的好处。
正如其他人所说，这听起来像你会更喜欢memcached之类的东西。 试图限制自己到DNS似乎是愚蠢的，当它是内部使用。 如果您能够控制客户端，则可以轻松地在DNS故障转移和负载平衡方面做出比DNS本身更好的工作。
因为我是怀疑论者的首席技术官，所以我想在讨论中加点颜色。
正如Gary所说，应用程序需要能够发布一个非常大的清单。 清单将被分成几个（30-100）组。 每个密钥的平均大小约为55字节，但可能会大得多。
无论我们select哪种产品都需要支持以下内容：
1）全冗余和负载平衡2）高的交易量（15k-20k读/秒），响应时间<500ms。
好处是：1）分层结构2）logging到期3）自描述拓扑
只有在考虑使用UDP而不是TCP来从内存分布式caching中检索数据之后，才会想到DNS。 自然，DNS是旧的和最大的DNS应用程序之一。
已知DNS支持具有大量logging的区域文件。 例如.com。 是一个区域文件（尽pipe分布在全球许多服务器上）。 支持非常高的stream量也是众所周知的。
我们通过一些初步testing运行了DNS。 我们装载了一个带有10M TXTlogging的单个区域文件，其中包含有代表性的数据量。 从同一局域网上的不同服务器上，我们以multithreading的方式运行30万个查询的testing，每秒获得大约5000个请求。 在testing期间，服务器和客户端几乎没有退缩。 我们要么在testing应用程序本身遇到瓶颈，要么在客户端的networking堆栈中遇到瓶颈。
我对DNS很感兴趣，因为它支持我本来想要的所有东西，而且已经有很多年了。 我喜欢的function是：
Zone Delegation - we can define which server(s) handle particular partitions. For example 1.mycompany.local is handled by servers 10.1.1.1 and 10.1.1.2. Redundancy - DNS was built with resiliency and redundancy in mind. It can also be easily load balanced. Performance - Proven to support high request volumes 尽pipe如此，DNS听起来像是一个奇怪的工具，用作caching。 如果确实通过了select阶段，我们绝对会在内部局域网上使用它，它不会和我们任何其他内部或外部的DNS系统在同一个DNS上。 一方面说明，我们可能希望与第三方合作伙伴共享我们存储的数据。 DNS是一个众所周知的实体，任何人都可以轻松查询接收区域传输。
感谢您持续的反馈。
1 – 可能，但不build议
2 – caching行为奇怪，不安全，不支持任何地方
3 – 不知道
在memcached中基本上有一个现成的解决scheme： http : //www.danga.com/memcached/
毕竟这不是一个坏主意。
如果是关于性能，请确保答案适合一个udp数据包（否则它将回落到较慢的tcp）。 明智地设置TTL值取决于你想更新logging的频率。
有一个（标准）方法来dynamic更新logging，如果你从程序中完成logging，这可能是好的。
如果你的DNS入口是key.modulus，那么数据是什么？ IP地址？ 我错过了什么？
使用memcached。 它是专门为此目的而devise的。 如果你正在caching数据，那么当数据被刷新时你不必担心。 如果服务器消失，客户端将继续使用其他服务器，这只会被视为caching未命中。 有一些客户端在发生故障的节点的情况下会重新刷新。 我想last.fm做了一些工作。
如果你需要可靠的数据，那么你可能想看看像memcachedb，它使用一个berkerleyDB后端，而不是内存，将做两个节点之间的复制。
这是否可行？
是。 我build议你看TXTlogging来保存这些信息
有什么陷阱？
不确定
如何确定DNS服务器的大小
不知道，但据我所知，DNS是一个相当低的要求服务使用UDP来处理请求和答复 – 这样做是由客户端来决定是否得到答案，并重新问是否不成功。
第一个迹象表明你的DNS不工作，将是零星的全企业查询失败。
还要注意的是，几乎每个发出这些请求的计算机系统都会将结果caching30分钟，或者如果结果less于30分钟，则将结果caching到loggingttl值。 所以要小心处理这些值。
我曾经在一个手指服务器上托pipe食堂菜单，这样每个人都可以看到日子菜单
<吸鸡蛋>我还build议你编写特定服务器/组的程序，不要依赖于默认的DNS服务器：O </ suck eggs>
有关访问/更新要求的更多信息将有助于提供更明智的意见。
相对于DNS本身，它主要针对相对静态的数据进行优化，而这些数据很less/很慢地改变。 另外，大多数情况下，它只能从单个服务器/区域的angular度对相对较less的数据进行操作。 它主要是通过中间caching（TTL）以及通过每个组织的服务器遍布世界“数据库”的分布式树来获得可扩展性。 重复的DNS服务器更多的是提高可用性…而不是分配工作量（尽pipe在某些应用中可能是这种情况）。
您的应用似乎推动了DNS的两个方面：
DNS可能会在你的应用程序中工作，但是我清楚地说它不是针对这种情况进行优化的。
虽然DNS对于某些事情来说非常棒，但无论如何分片，对于存储512KByte的值都不是件好事。
如果你有3亿个基准（比如1000个字节），DNS（1280字节的数据包）可能是个好主意。
PowerDNS授权服务器可能是发布这种数据的好方法，例如使用PIPE后端。
但是对于512K字节的数据，DNS根本不适合你的账单。
我从来没有加载testing的DNS到这个程度，但我会非常非常谨慎这种方法。 这当然是非正统的，而且非常疯狂，它可能会工作，但这种方法就像使用锤子来扭转一个螺丝 – 如果你设置正确的话，确保你可以做到这一点，但这是错误的工具。
最糟糕的情况是，你会把公司的DNS带到膝下，有人会向CEO解释他为什么不能收到他的邮件。
我build议传播DNScaching，只是将parsing的地址保存到您的硬盘上。 在linux上有pDNSd和DNSmasq。 两者都很容易安装，build议避免解决您的服务器上的地址。