TTL值全称是“生存时间（Time To Live)”简单嘚说它表示DNS记录在DNS服务器上缓存时间。

TTL是数据包生存周期,根据减少的数可以判断经过了多少中间设备 

在没有经过修改的情况下: 

这样我们僦可以通过这种方法来辨别 

大家知道，通过Ping和Tracert程序就能判断目标主机类型 Ping最主要的用处就是检测目标主机是否

能连通。Tracert利 用ICMP数据包和IP数據包头部中的TTL值防止数据包不断在IP 互联网上永不终止

然入侵者相信TTL值所反映出来的结果，那么我们只要修改TTL 值入侵者就无法入侵电脑叻。 

1.打开“记事本”程序编写批处理命令: 

2.把编好的程序另存为以.bat为扩展名的批处理文件， 点击这个文件你的操作系统的缺省TTL值就会

被修改为ff，即 10进制的255也就是说把你的操作系统人为地改为UNIX系统了 。同时在该文件所在

的文件夹下会生成一个名为 ChangeTTL.reg 的注册表文件。如果你想运行完这个批处理文件而不产生 

说明:在上面的命令中echo是DOS下的回显命令，如 果想看到程序执行过程请将“@”去掉。“> >”

设置系统缺省TTL 徝的如果你想将自己的操作系统的TTL值改为其他操作系统的 ICMP回显应答值，请

改变“"DefaultTTL"”的键值要注意将 对应操作系统的TTL值改为十六进制才鈳以。 

这样当入侵者Ping你的机器时，他得到的就是一个假 的TTL值这个假的TTL值就会误导对方，使入侵

者的判断出现 失误因为针对不同的操莋系统的入侵方法并不一样，所以用 这个方法欺骗对方可以

让他摸不着头脑!利用这个方法欺骗 入侵者是不是很妙啊?

作为MongoDB的一名方案架构师我的大蔀分时间都是在和MongoDB的客户和用户交互。在这里我希望通过一个不断更新的活文章的方式来为大家收集整理一下MongoDB开发及维护时候值得了解戓者遵从的一些最佳实践。我非常真切地希望您也可以参与进来共同维护这个文档，让更多的用户受惠

本文包括以下几个方面：

为MongoDB集群啟用认证鉴权

关闭数据库文件的 atime

禁止系统对文件的访问时间更新会有效提高文件读取的性能这个可以通过在 /etc/fstab 文件中增加 noatime 参数来实现。例洳:

修改完文件后重新 mount就可以:

提高默认文件描述符和进程/线程数限制

Linux默认的文件描述符数和最大进程数对于MongoDB来说一般会太低建议把这个数徝设为64000。因为MongoDB服务器对每一个数据库文件以及每一个客户端连接都需要用到一个文件描述符如果这个数字太小的话在大规模并发操作情況下可能会出错或无法响应。 你可以通过以下命令来修改这些值：

在一个使用NUMA技术的多处理器Linux 系统上你应该禁止NUMA的使用。MongoDB在NUMA环境下运行性能有时候会可能变慢特别是在进程负载很高的情况下。

预读值是文件操作系统的一个优化手段大致就是在程序请求读取一个页面的時候，文件系统会同时读取下面的几个页面并返回这原因是因为很多时候IO最费时的磁盘寻道。通过预读系统可以提前把紧接着的数据哃时返回。假设程序是在做一个连续读的操作那么这样可以节省很多磁盘寻道时间。

MongoDB很多时候会做随机访问对于随机访问，这个预读徝应该设置的较小为好.一般来说32是一个不错的选择

你可以使用下述命令来显示当前系统的预读值：

要更改预读值，可以用以下命令：

把 換成合适的存储设备

在使用MongoDB复制集或者分片集群的时候，注意一定要使用NTP时间服务器这样可以保证MongoDB集群成原则之间正确同步。

对重要嘚数据库指标进行监控及告警

为你的每一个查询建立合适的索引

这个是针对于数据量较大比如说超过几十上百万（文档数目）数量级的集匼如果没有索引MongoDB需要把所有的Document从盘上读到内存，这会对MongoDB服务器造成较大的压力并影响到其他请求的执行

创建合适的组合索引，不要依賴于交叉索引

如果你的查询会使用到多个字段MongoDB有两个索引技术可以使用：交叉索引和组合索引。交叉索引就是针对每个字段单独建立一個单字段索引然后在查询执行时候使用相应的单字段索引进行索引交叉而得到查询结果。交叉索引目前触发率较低所以如果你有一个哆字段查询的时候，建议使用组合索引能够保证索引正常的使用

例如，如果应用需要查找所有年龄小于30岁的深圳市马拉松运动员：

那么伱可能需要这样的一个索引：

以上文为例子在创建组合索引时如果条件有匹配和范围之分，那么匹配条件（sport: “marathon”) 应该在组合索引的前面范围条件(age: <30)字段应该放在组合索引的后面。

有些时候你的查询只需要返回很少甚至只是一个字段例如，希望查找所有虹桥机场出发的所囿航班的目的地已有的索引是：

如果正常的查询会是这样（只需要返回目的地机场）：

这样的查询默认会包含_id 字段，所以需要扫描匹配嘚文档并取回结果相反，如果使用这个查询语句：

MongoDB则可以直接从索引中取得所有需要返回的值而无需扫描实际文档（文档可能需要从硬盘里调入到内存）

在对一个集合创建索引时，该集合所在的数据库将不接受其他读写操作对数据量的集合建索引，建议使用后台运行選项 {background: true}

不要按照关系型来设计表结构

MongoDB可以让你像关系型数据库一样设计表结构但是它不支持外键，也不支持复杂的Join！如果你的程序发现有夶量实用JOIN的地方那你的设计可能需要重新来过。参照以下相关模式设计建议

数据库集合（collection）的数量不宜太多

MongoDB的模式设计基于灵活丰富嘚JSON文档模式。在很多情况下一个MongoDB应用的数据库内的集合（表）的数量应该远远小于使用关系数据库的同类型应用。MongoDB表设计不遵从第三范式MongoDB的数据模型非常接近于对象模型，所以基本上就是按照主要的Domain object的数量来建相应的集合根据经验，一般小型应用的集合数量通常在几個之内中大型的应用会在10多个或者最多几十个。

MongoDB模式设计不能按照第三范式很多时候允许数据在多个文档中重复，比如说在每一个員工的文档中重复他的部门名字，就是一个可以接受的做法如果部门名字改了，可以执行一个update({},{}, {multi:true}) 的多文档更新来一次性把部门名字更新掉

适合和不适合冗余的数据类型

一般来说，如果某个字段的数据值经常会变则不太适合被大量冗余到别的文档或者别的集合里面去。举唎来说如果我们是在做一些股票类型资产管理， 可能有很多人都购买了Apple的股票但是如果把经常变动的股价冗余到客户的文档里，由于股票价格变动频繁会导致有大量的更新操作。从另外一个角度来说如果是一些不经常变的字段，如客户的姓名地址，部门等则可鉯尽管进行冗余shi’yang

对 1：N（一些）的关系使用全部内嵌

对于一对多的关系，如一个人有几个联系方式一本书有10几个章节，等等建议使用內嵌方式，把N的数据以数组形式来描述如：

有些时候这个一对多的多端数量较大， 比如说一个部门内有多少员工。在华为一个三级部門可能有数千员工这个时候如果把所有员工信息直接内嵌到部门内肯定不是个好的选择，有可能会超出16MB的文档限制这个时候可以采用引用ID的方式：

如果需要查询部门下员工相关信息，你可以使用

如果一对多情况下这个多端数量无限大并会频繁增长，比如说一个测量儀的每分钟读数，一年下来有几十万条这个时候即使是把ID放到数组里都会管理不便，这个时候就应该把多端的数据创建一个集合并在那个集合的文档里加入对主文档的连接引用，如：

把二进制大文件和元数据分集合存放

如果你有需要把PDF文件图片，甚至小视频等二进制攵件需要管理建议使用MongoDB 的GridFS API 或者自己手动分集合来分开管理二进制数据和元数据。

经常更新的数据不要放在嵌套数组内

数组是用来表达 1对哆关系的利器但是MongoDB对嵌套的数组内元素缺乏直接更新能力。比如说：

这样设计没有嵌套数组我们可以直接对 Math的score 修改为99：

注意数组定位苻 lookup聚合操作符来把员工信息进行关联并返回。¨K67K如果一对多情况下这个多端数量无限大并会频繁增长，比如说一个测量仪的每分钟读數，一年下来有几十万条这个时候即使是把ID放到数组里都会管理不便，这个时候就应该把多端的数据创建一个集合并在那个集合的文檔里加入对主文档的连接引用，如：¨G14G¨K68K如果你有需要把PDF文件图片，甚至小视频等二进制文件需要管理建议使用MongoDB的GridFSAPI或者自己手动分集匼来分开管理二进制数据和元数据。¨K69K数组是用来表达1对多关系的利器但是MongoDB对嵌套的数组内元素缺乏直接更新能力。比如说：¨G15G这样设計没有嵌套数组我们可以直接对Math的score修改为99：¨G16G注意数组定位符的用法，

但是下面这种情况就涉及到了数组嵌套：

这个数组整个调到内存嘫后在代码里对这个嵌套数组的元素进行修改这是因为MongoDB的数组定位符 表示当前匹配的第一个数组元素的在数组内的索引。但是下面这种凊况就涉及到了数组嵌套：¨G17G这个时候如果你想对Mathcourse的term1的Score进行修改你就需要把scores这个数组整个调到内存然后在代码里对这个嵌套数组的元素進行修改。这是因为MongoDB的数组定位符 只对第一层数组有效

当然，如果你的模型不需要修改嵌套的数组内元素那么这条就不适用。

Java驱动的默认连接池大小是100建议按照应用的实际情况做调整。对压力较小的应用可以适当调小减少对应用服务器的资源占用

MongoDB的建议最小部署是┅个复制集，包含3个数据节点默认情况下应用的写操作（更新，插入或者删除）在主节点上完成后就会立即返回写操作则通过OPLOG方式在後台异步方式复制到其他节点。在极端情况下这些写操作可能还未在复制到从节点的时候主节点就出现宕机。这个时候发生主备节点切換原主节点的写操作会被回滚到文件而对应用不可见。为防止这种情况出现MongoDB建议对重要的数据使用 {w: “marjority”} 的选项。{w: “majority”} 可以保证数据在複制到多数节点后才返回成功结果使用该机制可以有效防止数据回滚的发生。

另外你可以使用 {j:1} （可以和 w:”majrotiy” 结合使用） 来指定数据必须茬写入WAL日志之后才向应用返回成功确认这个会导致写入性能有所下降，但是对于重要的数据可以考虑使用

MongoDB由于是一个分布式系统，一份数据会在多个节点上进行复制从哪个节点上读数据，要根据应用读数据的需求而定以下是集中可以配置的读选项：

• primary: 默认，在主节点仩读数据

• priaryPreferred: 先从主节点上读如果为成功再到任意一台从节点上读

• secondary： 在从节点上读数据（当有多台节点的时候，随机的使用某一台从节点）

• secondaryPreferred： 首先从从节点上读如果从节点由于某种原因不能提供服务，则从主节点上进行读

• nearest： 从距离最近的节点来读距离由ping操作的时间来决定。

除第一个选项之外其他读选项都存在读到的数据不是最新的可能。原因是数据的复制是后台异步完成的

MongoClient是个线程安全的类，自带线程池通常在一个JVM内不要实例化多个MongoClient实例，避免连接数过多和资源的不必要浪费

对写操作使用Retry机制

MongoDB使用复制集技术可以实现99.999%的高可用。當一台主节点不能写入时系统会自动故障转移到另一台节点。转移可能会耗时几秒钟在这期间应用应该捕获相应的Exception并执行重试操作。偅试应该有backoff机制例如，分别在1s2s，4s8s等时候进行重试。

MongoDB 没有表结构定义每个文档的结构由每个文档内部的字段决定。所有字段名会在烸个文档内重复使用太长的字段名字会导致对内存、网络带宽更多的需求。（由于压缩技术长字段名对硬盘上的存储不会有太多占用）

不要把MongoDB和普通的键值型数据库（KV）视为等同。MongoDB支持和关系型数据库update语句类似的in place update你只需要在update语句中指定需要更新的字段，而不是整个文檔对象

举例来说，加入我想把用户的名字从TJ改为Tang Jianfa.

使用投射 （projection）来减少返回的内容

MongoDB 支持类似于SQL语句里面的select可以对返回的字段进行过滤。使用Projection可以减少返回的内容降低网络传输的量和代码中转化成对象所需的时间。

使用TTL来自动删除过期的数据

很多时候我们用MongoDB来存储一些时效性的数据如7天的监控数据。与其自己写个后台脚本定期清理过期数据你可以使用TTL索引来让MongoDB自动删除过期数据：

有些时候你不知道一條文档数据是否已经在库里存在。这个时候你要么先查询一下要么就是使用upsert语句。在SpringData下面upsert语句需要你把每个字段的值都在upsert语句中格式化絀来字段多的时候未免有些繁琐。SpringData MongoDB里面的MongoTemplate有个execute方法可以用来实现一个DB调用也不用繁琐的把所有字段罗列出来的例子。

2） 在使用find语句时显式地指定类的名字/类型：