详解MongoDB的主从配置 (详解modbus)

大型网站为了软解大量的并发访问，除了在网站实现分布式负载均衡，远远不够。到了数据业务层、数据访问层，如果还是传统的数据结构，或者只是单单靠一台 服务器 扛，如此多的数据库连接操作，数据库必然会崩溃，数据丢失的话，后果更是不堪设想。这时候，我们会考虑如何减少数据库的联接，一方面采用优秀的代码框架，进行代码的优化，采用优秀的数据缓存技术如：memcached,如果资金丰厚的话，必然会想到假设服务器群，来分担主数据库的压力，本篇文章重点为大家讲解一下MongoDB的主从配置。

如何正确的使用MongoDB并优化其性能

e799bee5baa6e79fa5ee4b893e5b19e136数据库性能对软件整体性能的影响是不言而喻的，那么，当我们使用MongoDB时改如何提高数据库性能呢？1.范式化与反范式化在项目设计阶段，明确集合的用途是对性能调优非常重要的一步。 从性能优化的角度来看，集合的设计我们需要考虑的是集合中数据的常用操作，例如我们需要设计一个日志（log）集合，日志的查看频率不高，但写入频率却很高，那么我们就可以得到这个集合中常用的操作是更新（增删改）。 如果我们要保存的是城市列表呢？显而易见，这个集合是一个查看频率很高，但写入频率很低的集合，那么常用的操作就是查询。 对于频繁更新和频繁查询的集合，我们最需要关注的重点是他们的范式化程度，在上篇范式化与反范式化的介绍中我们了解到，范式化与反范式化的合理运用对于性能的提高至关重要。 然而这种设计的使用非常灵活，假设现在我们需要存储一篇图书及其作者，在MongoDB中的关联就可以体现为以下几种形式：1.完全分离（范式化设计）示例1：View Code{ _id : ObjectId(5124b5dc7dca), title : 如何使用MongoDB, author : [ ObjectId(144b5dc7dca),ObjectId(144b5dc7dca),ObjectId(144b5dc7dca), ] }我们将作者(comment) 的id数组作为一个字段添加到了图书中去。 这样的设计方式是在非关系型数据库中常用的，也就是我们所说的范式化设计。 在MongoDB中我们将与主键没有直接关系的图书单独提取到另一个集合，用存储主键的方式进行关联查询。 当我们要查询文章和评论时需要先查询到所需的文章，再从文章中获取评论id，最后用获得的完整的文章及其评论。 在这种情况下查询性能显然是不理想的。 但当某位作者的信息需要修改时，范式化的维护优势就凸显出来了，我们无需考虑此作者关联的图书，直接进行修改此作者的字段即可。 2.完全内嵌（反范式化设计）示例2：View Code{ _id : ObjectId(5124b5dc7dca), title : 如何使用MongoDB, author : [{ name : 丁磊 age : 40,　nationality : china,},{ name : 马云 age : 49, nationality : china,},{ name : 张召忠 age : 59, nationality : china,},]} 在这个示例中我们将作者的字段完全嵌入到了图书中去，在查询的时候直接查询图书即可获得所对应作者的全部信息，但因一个作者可能有多本著作，当修改某位作者的信息时时，我们需要遍历所有图书以找到该作者，将其修改。 3.部分内嵌（折中方案）示例3：View Code{ _id : ObjectId(5124b5dc7dca), title : 如何使用MongoDB, author : [ {　_id : ObjectId(144b5dc7dca), name : 丁磊},{ _id : ObjectId(144b5dc7dca), name : 马云},{ _id : ObjectId(144b5dc7dca), name : 张召忠},]}这次我们将作者字段中的最常用的一部分提取出来。 当我们只需要获得图书和作者名时，无需再次进入作者集合进行查询，仅在图书集合查询即可获得。 这种方式是一种相对折中的方式，既保证了查询效率，也保证的更新效率。 但这样的方式显然要比前两种较难以掌握，难点在于需要与实际业务进行结合来寻找合适的提取字段。 如同示例3所述，名字显然不是一个经常修改的字段，这样的字段如果提取出来是没问题的，但如果提取出来的字段是一个经常修改的字段（比如age）的话，我们依旧在更新这个字段时需要大范围的寻找并依此进行更新。 在上面三个示例中，第一个示例的更新效率是最高的，但查询效率是最低的，而第二个示例的查询效率最高，但更新效率最低。 所以在实际的工作中我们需要根据自己实际的需要来设计表中的字段，以获得最高的效率。

mongodb分片后怎么取数据

分片是MongoDB提供的一种机制，其可以将大型的集合分割保存到不同的服务器上。 与其他的分区方案相比，MongoDB几乎能自动为我们完成所有事情。 只要我们进行简单的配置，并告诉MongoDB要分配的数据，它就可以自动维护数据在不同服务器之间的平衡。 同时根据需要增减服务器，MongoDB也会自动移动平移已有数据。 分片机制提供了如下三种优势1. 对集群进行抽象，让集群“不可见”。 MongoDB自带了一个叫做mongos的专有路由进程。 mongos就是掌握统一路口的路由器，其会将客户端发来的请求准确无误的路由到集群中的一个或者一组服务器上，同时会把接收到的响应拼装起来发回到客户端。 2.保证集群总是可读写。 MongoDB通过多种途径来确保集群的可用性和可靠性。 将MongoDB的分片和复制功能结合使用，在确保数据分片到多台服务器的同时，也确保了每分数据都有相应的备份，这样就可以确保有服务器换掉时，其他的副本可以立即接替坏掉的部分继续工作。 3.使集群易于扩展。 当系统需要更多的空间和资源的时候，MongoDB使我们可以按需方便的扩充系统容量。 实现数据分割分片(shard)是集群中存储集合数据子集的一台或者多台服务器。 在生产环境中一个分片通常是一个副本集(replica set)。 片键(key)，MongoDB以其作为依据来确定需要在不同分片服务器之间移动的数据。 例如我们可以选择用户名(username)字段作为分片键，现有一用户名区间[“p”,”z”],那么wufengtinghai是属于这一区间的，那么数据最终会保存到与此区间对应的分片服务器上。 分配数据到分片服务器分配数据到分片服务器可以使用不同的方式，了解不同的方式可以加深我们对MongoDB使用方式的理解。 一分片一区间分配数据到分片最简单的方式莫过于一个区间一个分片。 假设我们有四个分片存储用户的相关信息，则我们可能会得到如下的分片和区间的对应关系。 这种分片方式非常简单易懂，但是在一个大型繁忙的系统中却会带来许多的不便。 假如大量的用户使用首字母在【“a”,”f”)中的名字来注册，这将会导致分片1比较大，因此需要将其一部分文档移动到分片2上，我们可以调整分片1对应区间【”a”,”c”),使分片2的区间变成【”c”,”n”)。 如果移动数据后，分片2因此过载怎么办？假设分片1和分片2各有500G数据，而分片3和分片4各自有300G数据。 那么按照这个方案，最终需要一连串的复制，总共算下来需要移动400G数据，考虑到需要在集群的服务器之间移动这些数据，可见移动数据量之大。 如果需要新加分片服务器进行水平扩展呢？假设此时每个分片上都有了500G数据，那么我们现在需要将分片4上的400G数据移动到分片5，将分片3的300G数据移动到分片4，将分片2的200G数据移动到分片3，将分片1的100G数据移动到分片2，整整移动了1T的数据！随着分片数量和数据量的增长，这种噩梦将会持续下去，因此MongoDB不会采用这种方式。 一分片多区间如果我们采用一分片多区间的方式，我们可以将分片1上的数据划分为两个区间，【”a”,”d”)包含400G数据，【”d”,”f”)包含100G数据，同样我们也可以对分片2做类似的处理，得到区间【”f”,”j”)和【“j”,”n”)。 现在我们只需要将分片1上的【”d”,”f”)数据移动到分片4，将分片2的【“j”,”n”)的数据移动到分片3。 这样我们仅仅只需要移动200G数据。 如果要添加新分片，可以从每个分片顶端取100G数据并将其移动到新的分片上，这样仅仅只需要移动400G数据即可。 MongoDB就是利用这种方式，当一个分片的数据越来越大时，其会自动分割片键区间，并将分片的数据进行分割并移动到其他分片。

在node.js领域中哪一个框架用来架构API比较好

程序 or 框架？程序是已经成型的应用，你需要的是为它搭建环境、添加配置，然后就可以运行起来；框架则是应用的骨架，你需要为它添加数据模型、业务逻辑，它才能成为应用，开始提供服务。 事实上，对于Web开发来说，程序和框架的区别正越来越模糊，比如几乎妇孺皆知的Wordpress，它是一个博客程序，但它丰富的插件以及高度的 自定义能够支持很大程度上的二次开发，在这点上它比起一些PHP框架也并不逊色。 我个人认为，如果重心在于提供服务而不是掌握技术，有WordPress 这样的程序是没有必要使用框架的。 可惜的是，由于Nodejs还很年轻，目前还没有WordPress这样的程序，因此目前在开发里，如果想做出自己想要的作品，框架是必然的选择。 如果是某些特定类型的应用，可以尝试一些开源的程序，比如要用Nodejs做博客，有Hexo、Ghost等。 回到顶部 Web框架有哪些？里的Web框架分为API框架和Web应用框架。 前者能够开发出RESTful的API，后者也能开发出RESTful API，但还包括模板、渲染等为前端所准备的功能。 API框架的使用场景是为跨平台应用提供统一的数据模型，而渲染由前端/客户端自行解决。 目前比较知名的API框架有restify（文档、Github、NPM）（官网、Github、NPM）LoopBack（官网、Github、NPM）Frisby（官网、Github、NPM）（官网、Github、NPM）Web应用框架顾名思义，就是为了打造Web应用所开发的框架。 这里有两种风格的Web应用框架。 一个是Sinatra风格，另一个是Rails风格。 Sinatra和Rails都是Ruby语言的Web框架，后者的影响力更大也更为知名。 这里简单的解释一下两种风格是什么意思。 Sinatra风格是指高度可配置，注重开发的自由度。 代表性的Nodejs Web框架有：Express（官网、Github、NPM）TJ大神开发，官方推荐 hapi（官网、Github、NPM）（官网、Github、NPM）flaliron（官网、Github、NPM）（官网、Github、NPM）locomotive（官网、Github、NPM）Rails风格则是指不重复自己和约定优于配置，以及严格遵循MVC结构开发。 代表性的框架有（官网、Github、NPM）geddy（官网、Github、NPM）CompoundJS（官网、Github、NPM） 原railswayjs这两种风格无所谓谁优谁劣，全凭使用者的偏好。 而在这两种Web框架之外，还有更大型的框架，即全栈框架，其中的代表是MEAN。 回到顶部MEAN？MEAN指MongoDB+Express++，这一组合包括运行环境、数据库、Web框架和前端引擎。 被称为 全栈框架（Full-stack framework）。 这其中除了之外，每一个都是可替换的，目标是创建从前端到后端，全部使用javascript的Web应用。 由于这一框架的完善性，有人将其称为LAMP的接班人。 LAMP即PHP的典型运行环境，Linux+Apache+MySql+PHP，被大量的用于各种虚拟主机上。 MEAN看似庞大，但事实上要构建完整的现代化Web应用，特别是SPA（单页面应用），这几个组件都是难以缺少的，并且，其中每一项几乎都是目前 情况下的最佳选择，因此用于学习和重头开始打造新的Web应用是非常合适的。 但由于实际业务的独特性，很可能要替换其中的组件，比如用Mysql来替换 MongoDB，因此，学习其中的原理和架构，打造自己的类MEAN框架也是一种选择。 作为个人和小团队来说，全栈框架MEAN基本上足够了，但目前大多数全栈框架还包含一项特性，那就是实时，拥有实时功能的框架我们又称为实时框架。 回到顶部实时框架好吗？实时框架（Real-time framework）指包含了webSocket的双向通信功能，能够在服务器和客户端做到实时通信的框架。 服务端和客户端自由通信的需求一直都在，但由于HTTP协议本身的局限性，因此催生了Comet等变通的方法，但即使这样也离实时相距甚远。 而当 兴起后，另一个HTML5技术webSocket也渐渐成熟，人们突然发现，实时通信一下子变得触手可及，于是webSocket技术在 中得到大量的应用，其中最为知名的模块就是，而各种全栈框架也纷纷加入实时特性来应对更广阔的开发需求。 目前有代表性的实时框架有：Meteor（官网、Github、NPM）（官网、Github、NPM）Derby（官网、Github、NPM）SocketStream（官网、Github、NPM）不过说实话，目前能看到的实时通信的应用场景其实不多，其中大多集中于聊天室、to-do、实时图表、在线游戏等领域。 其他领域使用实时特性不但没必要，而且是对服务器资源的浪费。 因此目前是否要采用实时框架，要看具体的项目而定。 以上基本就是 Web框架的现状了，相信看到这里，对于选择何种框架读者已经心里有数了吧。 最后再介绍一个容易搞混的概念，和解释一下我的选择。 回到顶部YEOMAN？第一次见到这个词，我还以为它和MEAN有什么联系。 事实上，它们是截然不同的两个东西。 YEOMAN由YO（脚手架）、grunt（构建工具）、bower（包管理器），它代表的是一种工作流，与框架开发的思维方式完全不同。 具体的介绍可见这里。 YEOMAN能够和框架达到类似的目的，都是为构建一个Web应用做好准备，但是要不要采用YEOMAN，则是见仁见智。 我个人的看法是，学习 YEOMAN本身就需要不少时间，并且有一定的学习门槛。 至少在目前，使用框架开发还是相对经济的，而如果以后YEOMAN这种模式推广开来，再来学习也 不迟，更何况有一定的项目经验之后再来学习YEOMAN要轻松很多。 事实上，我还是很认可YEOMAN这种Generator+package Manager的模式的，这是因为本身崇尚微模块的 概念，即无论是多么小的功能，都将它们模块化，甚至大的模块也要拆分成小的模块，然后通过搭积木的方式来构建应用。 这样能够彻底的解耦，对于不容易调试的 Javascript来说，也有助于定位和修复应用中的问题。 Generator就是这种理念催生下的产物，通过选择不同的配置和选项，将积木搭起来。 不 过对于这种模式目前大家也还处于实验当中，不急于进行实际应用。 回到顶部为什么我选择了Hackathon Starter？在我的个人项目中，使用的是Hackathon Starter，一个 Web应用脚手架。 我使用它的原因是，要求高度可配置，同时又讨厌写一些配置的代码，因此它对于我来说是很好的选择。 一些全栈框架对我来说，封装过多，将原生的 /Express API隐藏掉了，要使用还需要一定的学习成本。 而Express这样的框架又太过简洁，在实际的项目中使用还需要大量的插件和配置，而这些在 Hackathon Starter中都已经帮我们做好了，同时还有一些示例代码以供学习，对于新人来说非常友好，可以避免过多的挫折感。