大话架构师之分布式存储--mysql

此博文只说明一下数据存储的总体思路，具体配置这里肯定说不完，所以不说细节；

当今的大数据时代，数据给我们的感觉就是大、快、精确，要做到这样的效果，那么数据在一台机器上、一个数据库、一块硬盘上已经完全不可能了。同其他服务一样，存储服务同样需要采用分布式存储方案进行处理。

分布式存储的数据大体可以分为三类，非结构化数据、结构化数据、半结构化数据。

分布式存储可以分为，分布式文件系统，分布式键值系统，分布式表格系统，分布式数据库

这里先主要写分布式数据库的架构和调整；

分布式数据库一般是从单机关系数据库扩展而来的，分布式数据库分为关系型和非关系型，

如果系统的数据是一步一步慢慢增长那么数据库的优化是有一个过程的：

从刚开始的单机一个数据库到支撑大数据量的集群；

》》防止磁盘损坏：数据库备份到另一台机器;

》》单点问题：主备；

》》延时：HA实现了瞬时切换

》》访问速度慢，连接不够用：分库、分表

》》访问量数据量进一步变大：主从、集群

前面简单的部分就不在这里说了，随便找个帖子看一下就可以搞了。

从分库分表开始时写一下思路

分库分表：

 分库，数据结构根据业务设计的独立一些，把不同的业务数据放到不同的是数据库中，这一步需要配合代码层的业务逻辑，减少不同业务之间的联合查询之类的操作；

 分表：当一张表中的数据很大超过千万或者更多，那么需要考虑把数据放到多个表中，策略可以按id  取模的简单方式分配，在插入数据的时候，有状态产生的矛盾需要解决，不然id会有重复的，可以用uuid()，如果是基本数据类型，可以考虑nosql 转存，也可以通过nosql 取统一的id,

主从集群：

思路分两个方向，一个是主从，主更新数据，从查询数据；这样数据访问量就一个支持很大了，就访问量的抗压能力是够用了，另一方面，为了防止单点问题，需要增加主主互备份

 MYSQL常见的应用架构分享(这部分copy的其他技术人员的blog)

1、主从复制解决方案

这是MySQL自身提供的一种高可用解决方案，数据同步方法采用的是MySQL replication技术。MySQL replication就是从服务器到主服务器拉取二进制日志文件，然后再将日志文件解析成相应的SQL在从服务器上重新执行一遍主服务器的操作，通过这种方式保证数据的一致性。

为了达到更高的可用性，在实际的应用环境中，一般都是采用MySQL replication技术配合高可用集群软件keepalived来实现自动failover，这种方式可以实现95.000%的SLA。

2、MMM/MHA高可用解决方案

MMM提供了MySQL主主复制配置的监控、故障转移和管理的一套可伸缩的脚本套件。在MMM高可用方案中，典型的应用是双主多从架构，通过MySQL replication技术可以实现两个服务器互为主从，且在任何时候只有一个节点可以被写入，避免了多点写入的数据冲突。同时，当可写的主节点故障时，MMM套件可以立刻监控到，然后将服务自动切换到另一个主节点，继续提供服务，从而实现MySQL的高可用。

3、Heartbeat/SAN高可用解决方案

在这个方案中，处理failover的方式是高可用集群软件Heartbeat，它监控和管理各个节点间连接的网络，并监控集群服务，当节点出现故障或者服务不可用时，自动在其他节点启动集群服务。在数据共享方面，通过SAN（Storage Area Network）存储来共享数据，这种方案可以实现99.990%的SLA。

4、Heartbeat/DRBD高可用解决方案

此方案处理failover的方式上依旧采用Heartbeat，不同的是，在数据共享方面，采用了基于块级别的数据同步软件DRBD来实现。

DRBD是一个用软件实现的、无共享的、服务器之间镜像块设备内容的存储复制解决方案。和SAN网络不同，它并不共享存储，而是通过服务器之间的网络复制数据。

 

DRDB的安装配置与使用

MYSQL经典应用架构

 

其中：

         Dbm157是mysql主，dbm158是mysql主的备机，dbs159/160/161是mysql从。

MySQL写操作一般采用基于heartbeat+DRBD+MySQL搭建高可用集群的方案。通过heartbeat实现对mysql主进行状态监测，而DRBD实现dbm157数据同步到dbm158。

读操作普遍采用基于LVS+Keepalived搭建高可用高扩展集群的方案。前端AS应用通过提高的读VIP连接LVS，LVS有keepliaved做成高可用模式，实现互备。

         最后，mysql主的从节点dbs159/160/161通过mysql主从复制功能同步mysql主的数据，通过lvs功能提供给前端AS应用进行读操作，并实现负载均衡

Mysql 可用的分库分表中间件

目前比较好用的有mycat、  sharding-jdbc(sjdbc)、还有花钱的DRBS,对于搞技术的花钱的忽略

mycat:

它是一个开源的分布式数据库系统，是一个实现了MySQL协议的服务器，前端用户可以把它看作是一个数据库代理，用MySQL客户端工具和命令行访问，而其后端可以用MySQL原生协议与多个MySQL服务器通信，也可以用JDBC协议与大多数主流数据库服务器通信，其核心功能是分表分库，即将一个大表水平分割为N个小表，存储在后端MySQL服务器里或者其他数据库里。

MyCat发展到目前的版本，已经不是一个单纯的MySQL代理了，它的后端可以支持MySQL、SQL Server、Oracle、DB2、PostgreSQL等主流数据库，也支持MongoDB这种新型NoSQL方式的存储，未来还会支持更多类型的存储。而在最终用户看来，无论是那种存储方式，在MyCat里，都是一个传统的数据库表，支持标准的SQL语句进行数据的操作，这样一来，对前端业务系统来说，可以大幅降低开发难度，提升开发速度

mycat 详细博文

sjdbc:

Sharding-JDBC简介

Sharding-JDBC是当当应用框架ddframe中，从关系型数据库模块dd-rdb中分离出来的数据库水平分片框架，实现透明化数据库分库分表访问。Sharding-JDBC是继dubbox和elastic-job之后，ddframe系列开源的第3个项目。

Sharding-JDBC直接封装JDBC API，可以理解为增强版的JDBC驱动，旧代码迁移成本几乎为零：

• 可适用于任何基于Java的ORM框架，如JPA、Hibernate、Mybatis、Spring JDBC Template或直接使用JDBC。

• 可基于任何第三方的数据库连接池，如DBCP、C3P0、 BoneCP、Druid等。

• 理论上可支持任意实现JDBC规范的数据库。虽然目前仅支持MySQL，但已有支持Oracle、SQLServer等数据库的计划。

Sharding-JDBC定位为轻量Java框架，使用客户端直连数据库，以jar包形式提供服务，无proxy代理层，无需额外部署，无其他依赖，DBA也无需改变原有的运维方式。

Sharding-JDBC分片策略灵活，可支持等号、between、in等多维度分片，也可支持多分片键。

SQL解析功能完善，支持聚合、分组、排序、limit、or等查询，并支持Binding Table以及笛卡尔积表查询。

sjdbc 详细博文

转载于:https://blog.51cto.com/chaojiit/1785188