怎样实现APP开发高安全可用性之主从、分片模式？
一、APP开发经验之高可用集群
MongoDB作为NoSQL的代表之，其自身具备了良好的扩展性能快速搭建个高可用、可扩展的分布式集群，深圳APP开发公司下面介绍搭建MongoDB集群的几种方案。APP开发高安全可用开发之主从。
MongoDB采用双机主从备份，主节点的数据会自动同步到从节点，当主节点宕机后，能切换到从节点继续提供服务，如图8-4所示
APP开发安全高可用经验示意图之8-4MongoDB主从集群架构
当服务器访问量上升后，可能单靠台主节点提供服务会造成比较大的性能瓶颈。在大多数的业务中，数据读写的比例会达到8:2，甚至是9:1，访问的压力集中在读取数据方面，当一个节点无法承受读压力，可以把个节点增加为多个节点来减轻单台服务器的负载。
MongoDB提供了主多从的架构来降低单台节点的负载，由主节点负责写数据，多个从节点负责读数据，数据从主节点复制到多个从节点，如图8-5所示。
APP开发数据库高安全可用集群示意图之8-5MongoDB主从关系集群
但是MongoDB的t从架构有下面3个问题
·当主节点宕机后，不能支持自动切换连接，目前只能手动切换。
·主节点写压力过大的问题没法解决。
·没法支持数据的路由。
现在MongoDB官方已经不推荐使用主从的架构，取代方案是接下来介绍的副本集
APP开发数据库集群高安全可用方法之之副本集。
副本集使用多台机器做同份数据的异步同步，从而使多台服务器拥有同份数据的多个副本。一台服务器作为主节点提供写入服务，多台服务器作为副本节点提供读取服务，实现读写分离和负载均衡。当主节点宕机后，可以在不需要用户干预的情况下把台副本节点或其他节点提升为主节点，继续提供服务。副本集的架构如图8-6所示。
APP开发高可用数据库安全集群经验示意图8-6MongoDB副本集架构图
应用服务器连接到整个服务集，并不关心主服务器是否挂掉。主节点负责整个副本集的读写，副本节点从主节点中同步数据。副本集内的机器通过心跳机制通信，当检测到主节点宕机时，副本集内的服务器从剩余的服务器中选举台新的服务器作为主节点继续提供服务。这一切对于应用服务器来说都是透明的。
MongoDB的副本集是通过oplog实现的，主节点数据的修改操作会被记录到主节点的oplog日志，然后副本节点通过异步方式复制主节点的oplog文件并且将oplog日志应用到副本节点，从而实现了与主节点的数据同步。副本集启动时，副本集内的服务器通过选举机制选举台服务器为主节点，其他服务器为副本节点，选举过程如下
l.获取每台服务器oplog的最后操作时间。在MongoDB中，修改的数据会先放在匈存中段时间再写入硬盘，为了防止未写入硬盘前因为断电等原因造成数据丢失，所以MongoDB会把把相关的数据更新操作写入日士oplog中，以便MongoDB宕机后恢复。
2.如果集群中有超过半的节点宕机（包含半），停止选举。为了避免这个问题，MougoDB官方建议副本集中节点的个数最好为奇数。
3.如果集辞中服务器的oplog的最后操作时间看起来很旧，就停止选举等待管理员操作。
4.如果集群内部没有上面的问题，集群内的机器根据一致性协议，选举oplog的最后操作时间最新的那台服务器为主节点。
选举触发的条件如下
·副本集刚刚初始化的时候。
·由于网络的原因，副本节点和主节点断开通信。
·主节点宕机。
副本集的集群中，有如下4种角色。
·Primary:主节点，负责集群的读写
副本节点，从Priuary的oplog读取操作日志，以便与Primary保持一致，主要是备份。
·Arbiter:仲裁节点，其不负责任何读写，只负责主节点宕机的时候的参与选举。
·Passive Node:除了没有被选举权，其他同Secondary。
MongoDB官方推荐的集群节点是奇数，同时集群中又提供了仲裁节点这个角色，因此为了保证副本集的选举能顺利进行，可以在集群中加入一台仲裁服务器，如图8-7所示。
APP开发数据库高安全可用性架构图之图8-7副本集中加入仲裁节点的架构图
副本集还有一个问题：如果主节点读写压力过大，为了减轻主节点的压力，可以设置读写分离，由主节点负责读写，副本节点负责读，仲裁节点只参与选举，如图8-8所示。
APP开发数据库安全高可用鸡群架购示意图8-8MongoDB读写分离的架构
二、APP开发数据库高安全可用架构经验之分片
随着MougoDB数据量和访问量持续增加，单个集群的性能有可能达到瓶颈，针对这种情况，架构上一般的处理方法是“分而治之”，把集群中大量的数据读写请求分散到多个集群处理，在MySQL中称为数据库分片。
MySQL要实现分库功能，还要依赖Amoeba、Cobar或MyCAT等分布式关系数据库产品，而MongoDB提供了分片这种原生的机制来处理这种“分而治之”的问题。
当一台服务器的承载能力达到瓶颈，无论怎样提升单机硬件配置（例如加CPU、内存，把硬盘换成SSD）都无法解决问题，这时最好的策略就是分片，把集中在台服务器上的压力分散到多台。例如，有性能瓶颈的服务器要处理2TB的数据，而把2TB数据通过合理的分片策略分散到两台服务器上，每台服务器就存储1TB的数据和承担半的访问量了。
为了保证每个分片服务器能均衡地承担访问量，避免有的服务器承担很大的访问量，有的服务器承担很少的访问量，需要在设置分片规则时就仔细考虑。例如，根据文档的id来分片，就能保证分片是比较均衡的。
MongoDB分片的架构图如图8-9所示
APP开发数据库高安全可用经验示意图之8-9MongoDB分H的架构图
在图8-9中，MongoDB通过下面的31'组件实现分片：
．mougos:作为数据库集群请求的入口，由于数据已经分布在shard服务器上，所有请求经过mongos转发到shard服务器上，mongos充当路由的角色。mongos是无状态的，因此可以部署多台mongos做负载均衡，防止因为某台mongos宕机导致整个集群不可用。在某些MougoDB客户端中，连接MongoDB集群时支持同时传入多个mongos ip地址作为参数，在客户端内部实现负载均衡和故障移除。
．coufig server:配置服务器，存储了所有数据库元信息（路由、分片）的配置。mongos服务器自身是没有在硬盘上存储shard服务器和路由的元信息的，只是在内存中存储过，当mougos服务器重启或关机后，这些信息会丢失。因此，为了保证shard服务器和路由的元信息不丢失，信息会存储在coufig server服务器。当mongos第次启动或重启时，会从config server加载配置信息，同时，当配置信息发生变化时，mougos服务器会接收到最新的变化并更新内存中的数据。由于配置服务器中存储昀信息太重要，万一丢失会引起整个集群的崩溃，所以在生产环境中会配置多台coufig server保证高可用。
·shard server:分片服务器，分片后保存数据的服务器。
在分片集群中，某个分片的数据只存储在个服务器，如果这个服务器宕机了，那这部分数据就无法访问。为了保证分片的高可用，分片服务器也能使用副本集的架构，在生产环境中，每个副本集通常是由个主节点(Primary)、一个副本节点(SecondarV)、一个仲裁节点组成(Arbiter)，架构如图8-10所示。
APP开发数据库安全高可用示意图之8-10分片加上副本集的架构。
在UCloud上已经提供了基于MongoDB的分片集群的云数据库服务，UCloud只提供了配置服务器和分片服务器组件，mongos还需要用户在云服务器上自行搭建，APP开发公司希望各位在实际开发中根据情况相应完善具体细节。好了，本文就分享到这里，博纳网络希望本站这类型的文章能对您的开发工作有所帮助，谢谢关注。
当前文章链接：/construction/appkaifa/1714.html
如果您觉得案例还不错请帮忙分享：
[声明]本网转载网络媒体稿件是为了传播更多的信息，此类稿件不代表本网观点，本网不承担此类稿件侵权行为的连带责任。故此，如果您发现本网站的内容侵犯了您的版权，请您的相关内容发至此邮箱【qin@198bona.com 】，我们在确认后，会立即删除，保证您的版权。
