首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

MySQL 的知识点与Java开发 集群高可用架构?

用,缓存,数据库,搜索,消息队列等,每个模块都需要做到高可用,才能保证整个系统的高可用。对于数据库服务而言,高可用可能更复杂,对用户的服务可用,不仅仅是能访问,还需要有正确性保证,因此数据库的高可用方案是一直以来的讨论热点。

那我先说说MySQL的知识。我并不期望成为一个专家级的 ,但是,在我使用 MySQL 能知道常用的知识点。

MySQL常用知识:

一,事务机制

关系性数据库需要遵循ACID规则,具体内容如下:

事务的特性

原子性:事务是最小的执行单位,不允许分割。事务的原子性确保动作要么全部完成,要么完全不起作用;

一致性:执行事务前后,数据保持一致;

隔离性:并发访问数据库时,一个用户的事物不被其他事物所干扰,各并发事务之间数据库是独立的;

持久性:一个事务被提交之后。它对数据库中数据的改变是持久的,即使数据库 发生故障也不应该对其有任何影响。

为了达到上述事务特性,数据库定义了几种不同的事务隔离级别:

1,READ_UNCOMMITTED(未授权读取):最低的隔离级别,允许读取尚未提交的数据变更,可能会导致脏读、幻读或不可重复读。

2,READ_COMMITTED(授权读取):允许读取并发事务已经提交的数据,可以阻止脏读,但是幻读或不可重复读仍有可能发生。

3,REPEATABLE_READ(可重复读):对同一字段的多次读取结果都是一致的,除非数据是被本身事务自己所修改,可以阻止脏读和不可重复读,但幻读仍有可能发生。

4,SERIALIZABLE(串行):最高的隔离级别,完全服从ACID的隔离级别。所有的事务依次逐个执行,这样事务之间就完全不可能产生干扰,也就是说,该级别可以防止脏读、不可重复读以及幻读。但是这将严重影响程序的性能。通常情况下也不会用到该级别。

这里需要注意的是:Mysql 默认采用的 REPEATABLE_READ隔离级别 Oracle 默认采用的 READ_COMMITTED隔离级别.

事务隔离机制的实现基于锁机制和并发调度。其中并发调度使用的是MVVC(多版本并发控制),通过保存修改的旧版本信息来支持并发一致性读和回滚等特性。

二,字符集及校对规则

字符集指的是一种从二进制编码到某类字符符号的映射。校对规则则是指某种字符集下的排序规则。Mysql中每一种字符集都会对应一系列的校对规则。

Mysql采用的是类似继承的方式指定字符集的默认值,每个数据库以及每张数据表都有自己的默认值,他们逐层继承。比如:某个库中所有表的默认字符集将是该数据库所指定的字符集(这些表在没有指定字符集的情况下,才会采用默认字符集) PS:整理自《Java工程师修炼之道》。

三,索引相关的内容

Mysql索引使用的数据结构主要有BTree索引和哈希索引。对于哈希索引来说,底层的数据结构就是哈希表,因此在绝大多数需求为单条记录查询的时候,可以选择哈希索引,查询性能最快;其余大部分场景,建议选择BTree索引。

Mysql的BTree索引使用的是B数中的B+Tree,但对于主要的两种存储引擎的实现方式是不同的。

四,存储引擎

MySQL常见的两种存储引擎:MyISAM与InnoDB。

五,查询缓存的使用

my.cnf加入以下配置,重启Mysql开启查询缓存:

query_cache_type=1

query_cache_size=600000

Mysql执行以下命令也可以开启查询缓存:

setglobalquery_cache_type=1;

setglobalquery_cache_size=600000;

如上,开启查询缓存后在同样的查询条件以及数据情况下,会直接在缓存中返回结果。这里的查询条件包括查询本身、当前要查询的数据库、客户端协议版本号等一些可能影响结果的信息。因此任何两个查询在任何字符上的不同都会导致缓存不命中。此外,如果查询中包含任何用户自定义函数、存储函数、用户变量、临时表、Mysql库中的系统表,其查询结果也不会被缓存。

缓存建立之后,Mysql的查询缓存系统会跟踪查询中涉及的每张表,如果这些表(数据或结构)发生变化,那么和这张表相关的所有缓存数据都将失效。

缓存虽然能够提升数据库的查询性能,但是缓存同时也带来了额外的开销,每次查询后都要做一次缓存操作,失效后还要销毁。因此,开启缓存查询要谨慎,尤其对于写密集的应用来说更是如此。如果开启,要注意合理控制缓存空间大小,一般来说其大小设置为几十MB比较合适。此外,还可以通过sql_cache和sql_no_cache来控制某个查询语句是否需要缓存:

selectsql_no_cachecount(*)fromusr;

MySQL 集群高可用架构 Jia-qun-( 860-170-416 )-跟各位大神一起沟通交流学习!

一,MySQL+MHA 架构

MHA 目前在 Mysql 高可用方案中应该也是比较成熟和常见的方案,它由日本人开发出来,在 mysql 故障切换过程中,MHA 能做到快速自动切换操作,而且还能最大限度保持数据的一致性。

此架构特点:

1、安装布署简单,不影响现有架构。

2、自动监控和故障转移。

3、保障数据一致性。

4、故障切换方式可使用手动或自动多向选择。

5、适应范围大(适用任何存储引擎)。

二,MySQL 主从架构

此种架构,一般初创企业比较常用,也便于后面步步的扩展。

此架构特点:

1、成本低,布署快速、方便。

2、读写分离。

3、还能通过及时增加从库来减少读库压力。

4、主库单点故障。

5、数据一致性问题(同步延迟造成)。

三,MySQL+MMM 架构

MMM 即 Master-Master Replication Manager for MySQL(mysql 主主复制管理器),是关于 mysql 主主复制配置的监控、故障转移和管理的一套可伸缩的脚本套件(在任何时候只有一个节点可以被写入),这个套件也能基于标准的主从配置的任意数量的从服务器进行读负载均衡,所以你可以用它来在一组居于复制的服务器启动虚拟 ip,除此之外,它还有实现数据备份、节点之间重新同步功能的脚本。

MySQL 本身没有提供 replication failover 的解决方案,通过 MMM 方案能实现服务器的故障转移,从而实现 mysql 的高可用。

此方案特点:

1、安全、稳定性较高,可扩展性好

2、 对服务器数量要求至少三台及以上

3、 对双主(主从复制性要求较高)

4、 同样可实现读写分离

四,MySQL+DRDB 架构

通过 DRBD 基于 block 块的复制模式,快速进行双主故障切换,很大程度上解决主库单点故障问题。

此架构特点:

1、高可用软件可使用 Heartbeat, 全面负责 VIP、数据与 DRBD 服务的管理。

2、主故障后可自动快速切换,并且从库仍然能通过 VIP 与新主库进行数据。同步。

3、从库也支持读写分离,可使用中间件或程序实现。

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20190110A0OCFJ00?refer=cp_1026
  • 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码

添加站长 进交流群

领取专属 10元无门槛券

私享最新 技术干货

扫码加入开发者社群
领券