【ReactJs+springBoot项目——租房】第15章：MongoDB集群之复制集群 +MongoDB集群之分片集群+ 日志规范 +异常规范+其它规范

【ReactJs+springBoot项目——租房】第15章：MongoDB集群之复制集群 +MongoDB集群之分片集群+ 日志规范 +异常规范+其它规范

MongoDB集群之复制集群MongoDB集群之分片集群日志规范异常规范其它规范

1、MongoDB集群之复制集

1.1、简介 一组Mongodb复制集，就是一组mongod进程，这些进程维护同一个数据集合。复制集提供了数据冗余和高等级的可靠性，这是生产部署的基础。 目的 保证数据在生产部署时的冗余和可靠性，通过在不同的机器上保存副本来保证数据的不会因为单点损坏而丢 失。能够随时应对数据丢失、机器损坏带来的风险。 还能提高读取能力，用户的读取服务器和写入服务器在不同的地方，而且，由不同的服务器为不同的用户提供 服务，提高整个系统的负载。 机制 一组复制集就是一组mongod实例掌管同一个数据集，实例可以在不同的机器上面。实例中包含一个主导 （Primary），接受客户端所有的写入操作，其他都是副本实例（Secondary），从主服务器上获得数据并保持 同步。 主服务器很重要，包含了所有的改变操作（写）的日志。但是副本服务器集群包含有所有的主服务器数据，因 此当主服务器挂掉了，就会在副本服务器上重新选取一个成为主服务器。 每个复制集还有一个仲裁者（Arbiter），仲裁者不存储数据，只是负责通过心跳包来确认集群中集合的数量， 并在主服务器选举的时候作为仲裁决定结果。 1.2、架构 基本的架构由3台服务器组成，一个三成员的复制集，由三个有数据，或者两个有数据，一个作为仲裁者。 1.2.1、三个存储数据的复制集 一个主，两个从库组成，主库宕机时，这两个从库都可以被选为主库。

当主库宕机后,两个从库都会进行竞选，其中一个变为主库，当原主库恢复后，作为从库加入当前的复制集群即可。

1.2.2、存在arbiter节点的复制集

一个主库，一个从库，可以在选举中成为主库，一个arbiter节点，在选举中，只进行投票，不能成为主库。

说明：由于arbiter节点没有复制数据，因此这个架构中仅提供一个完整的数据副本。arbiter节点只需要更少的资源，代价是更有限的冗余和容错。

当主库宕机时，将会选择从库成为主，主库修复后，将其加入到现有的复制集群中即可。

1.3、Primary选举

复制集通过replSetInitiate命令（或mongo shell的rs.initiate()）进行初始化，初始化后各个成员间开始发送心跳消息，并发起Priamry选举操作，获得『大多数』成员投票支持的节点，会成为Primary，其余节点成为Secondary。『大多数』的定义

假设复制集内投票成员数量为N，则大多数为 N/2 + 1，当复制集内存活成员数量不足大多数时，整个复制集将无法选举出Primary，复制集将无法提供写服务，处于只读状态。

1.4、成员说明

1.5、搭建复制集

测试复制集群：

1.6、故障转移

测试一：从节点宕机

集群依然可以正常使用，可以读写操作。测试二：主节点宕机

选举出新的主节点继续提供服务测试三：停止集群中的2个节点

当前集群无法选举出Priamry，无法提供写操作，只能进行读操作

1.7、增加arbiter节点

当集群中的节点数为偶数时，如一主一从情况下，任意一节点宕机都无法选举出Priamry，无法提供写操作，加入

arbiter节点后即可解决该问题。

通过测试，添加arbiter节点后，如果集群节点数不满足N/2+1时，arbiter节点可作为“凑数”节点，可以选出主节点， 继续提供服务。

2、MongoDB集群之分片集群

分片（sharding）是MongoDB用来将大型集合分割到不同服务器（或者说一个集群）上所采用的方法。尽管分片起源于关系型数据库分区，但MongoDB分片完全又是另一回事。

和MySQL分区方案相比，MongoDB的最大区别在于它几乎能自动完成所有事情，只要告诉MongoDB要分配数据， 它就能自动维护数据在不同服务器之间的均衡。

2.1、简介

高数据量和吞吐量的数据库应用会对单机的性能造成较大压力,大的查询量会将单机的CPU耗尽,大的数据量对单机的存储压力较大,最终会耗尽系统的内存而将压力转移到磁盘IO上。

为了解决这些问题,有两个基本的方法: 垂直扩展和水平扩展。垂直扩展：增加更多的CPU和存储资源来扩展容量。

水平扩展：将数据集分布在多个服务器上。水平扩展即分片。

分片为应对高吞吐量与大数据量提供了方法。使用分片减少了每个分片需要处理的请求数，因此，通过水平扩展，集 群可以提高自己的存储容量和吞吐量。举例来说，当插入一条数据时，应用只需要访问存储这条数据的分片.

使用分片减少了每个分片存储的数据。例如，如果数据库1tb的数据集，并有4个分片，然后每个分片可能仅持有256 GB的数据。如果有40个分片，那么每个切分可能只有25GB的数据。

2.2、优势

对集群进行抽象，让集群“不可见”

MongoDB自带了一个叫做mongos的专有路由进程。mongos就是掌握统一路口的路由器，其会将客户端 发来的请求准确无误的路由到集群中的一个或者一组服务器上，同时会把接收到的响应拼装起来发回到客 户端。保证集群总是可读写

MongoDB通过多种途径来确保集群的可用性和可靠性。

将MongoDB的分片和复制功能结合使用，在确保数据分片到多台服务器的同时，也确保了每分数据都有相应的备份，这样就可以确保有服务器换掉时，其他的从库可以立即接替坏掉的部分继续工作。

使集群易于扩展

当系统需要更多的空间和资源的时候，MongoDB使我们可以按需方便的扩充系统容量。

2.3、架构

Mongos本身并不持久化数据，Sharded cluster所有的元数据都会存储到Config Server，而用户的数据会分散存储到各个shard。Mongos启动后，会从配置服务器加载元数据，开始提供服务，将用户的请求正确路由到对应的分 片。当数据写入时，MongoDB Cluster根据分片键设计写入数据。当外部语句发起数据查询时，MongoDB根据数据分布自动路由至指定节点返回数据。

2.4、集群中数据分布

在一个shard server内部，MongoDB会把数据分为chunks，每个chunk代表这个shard server内部一部分数据。chunk的产生，会有以下两个用途：

Splitting：当一个chunk的大小超过配置中的chunk size时，MongoDB的后台进程会把这个chunk切分成更小的chunk，从而避免chunk过大的情况

Balancing：在MongoDB中，balancer是一个后台进程，负责chunk的迁移，从而均衡各个shard server的负载，系统初始1个chunk，chunk size默认值64M,生产库上选择适合业务的chunk size是最好的。mongoDB会自动拆分和迁移chunks。

2.4.1、chunk分裂及迁移

随着数据的增长，其中的数据大小超过了配置的chunk size，默认是64M，则这个chunk就会分裂成两个。数据的增长会让chunk分裂得越来越多。

这时候，各个shard 上的chunk数量就会不平衡。mongos中的一个组件balancer 就会执行自动平衡。把chunk从

chunk数量最多的shard节点挪动到数量最少的节点。

2.4.2、chunksize chunk的分裂和迁移非常消耗IO资源；chunk分裂的时机：在插入和更新，读数据不会分裂。 小的chunksize：数据均衡是迁移速度快，数据分布更均匀。数据分裂频繁，路由节点消耗更多资源。大的chunksize：数据分裂少。数据块移动集中消耗IO资源。 适合业务的chunksize是最好的。 chunkSize 对分裂及迁移的影响 MongoDB 默认的 chunkSize 为64MB，如无特殊需求，建议保持默认值；chunkSize 会直接影响到 chunk 分裂、迁移的行为。 chunkSize 越小，chunk 分裂及迁移越多，数据分布越均衡；反之，chunkSize 越大，chunk 分裂及迁移会更少，但可能导致数据分布不均。 chunk 自动分裂只会在数据写入时触发，所以如果将 chunkSize 改小，系统需要一定的时间来将 chunk 分裂到指定的大小。 chunk 只会分裂，不会合并，所以即使将 chunkSize 改大，现有的 chunk 数量不会减少，但 chunk 大小会随着写入不断增长，直到达到目标大小。 2.5、搭建集群

3、日志规范

日志对项目而言，其重要性不言而喻，如果没有日志，生成环境的问题就无法定位，面对多种日志框架，如：

JDK14、simple、Log4j、Logback等，视乎我们有开始纠结了，到底使用哪个呢？

3.1、阿里巴巴开发手册

首先从《阿里巴巴Java开发手册》说起，在手册中提到：

为什么是强制？为什么要求必须使用SLF4J？SLF4J的作用到底是什么？ 3.2、了解SLF4J Java简易日志门面（Simple Logging Facade for Java，缩写SLF4J），是一套包装Logging 框架的界面程式，以外观模式实现。可以在软件部署的时候决定要使用的 Logging 框架，目前主要支援的有Java Logging API、Log4j及logback等框架。以MIT 授权方式发布。 SLF4J 的作者就是 Log4j和Logback 的作者 Ceki Gülcü，他宣称 SLF4J 比 Log4j 更有效率，而且比 Apache Commons Logging ( JCL) 简单、稳定。 其实，SLF4J其实只是一个门面服务而已，他并不是真正的日志框架，真正的日志的输出相关的实现还是要依赖 Log4j、logback等日志框架的。 官网：3.3、SLF4J的使用 3.3.1、创建工程

导入slf4j依赖：

3.3.2、编写日志代码

3.3.3、与JDK14整合 导入依赖：

运行上面的代码进行测试：

3.3.4、与Simple整合

导入依赖：（将slf4j-jdk14依赖注释掉）

运行上面的代码进行测试：

3.3.5、与Log4j整合

log4j还需要配置log4j.properties文件：

运行上面的代码进行测试：

3.3.6、与Logback整合

导入依赖：

运行效果如下：

3.3.7、小结 可以看到，无论和什么日志框架整合，我们编写的代码都不需要修改，只需要变更依赖即可，这就是slf4j框架的意义 所在。 3.4、手册中的其它规范

4、异常规范

4.1、异常概念 异常是发生在程序执行过程中阻碍程序正常执行的错误事件，当一个程序出现错误时，可能的情况有如下3种： 语法错误 代码的格式错了，某个字母输错了 运行时错误 空指针异常，数组越界，除数为零等 逻辑错误 运行结果与预想的结果不一样，这是一种很难调试的错误 Java中的异常处理机制主要处理运行时错误。异常分类：

在 Java 应用程序中，异常处理机制为：抛出异常，捕捉异常。抛出异常 当一个方法出现错误引发异常时，方法创建异常对象并交付运行时系统，异常对象中包含了异常类型和异 常出现时的程序状态等异常信息。运行时系统负责寻找处置异常的代码并执行。 捕获异常 在方法抛出异常之后，运行时系统将转为寻找合适的异常处理器（exception handler），进行处理。 4.2、异常规范

5、其它规范

阿里巴巴写的Java开发代码规范质量还是很高的，建议学员们进行查看学习。推荐： 编程规范s

MySQL数据库规范单元测试

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。