本篇教程探讨了大数据技术 分布式数据库，希望阅读本篇文章以后大家有所收获，帮助大家对大数据技术的理解更加深入。

<

1、先抛出两个问题
问题一、当mysql单表数据量爆炸时，你怎么办？ 问题二、当你的数据库无法承受高强度io时你怎么办？

2、 基本概念
2.1 谈数据库分片需要首先确定以下概念
? 1) 单库,就是一个库 
? 2) 分片(sharding)，分片解决扩展性问题，属于水平拆分，引入分片，就引入了数据路由和分区键的概念。分表解决的是数据量过大的问题，分库解决的是数据库性能瓶颈的问题。 
? 3) 分组(group)，分组解决可用性问题，分组通常通过主从复制(replication)的方式实现。(各种可用级别方案单独介绍) 
? 4) 互联网公司数据库实际软件架构是(大数据量下)：又分片，又分组（如下图）


3、 分片
3.1 水平拆分，垂直拆分都是什么？


分区表？1)若不走分区键很容易出现全表锁，并发上来后简直是灾难。2)自己分库分表，自己掌控业务场景、访问模式，可控。mysql分区表官方介绍是针对myisam做的优化，你知道他怎么玩的？分半天还是一个ibdata是不是很尴尬


3.2 为什么分表?
? 关系型数据库在大于一定数据量的情况下检索性能会急剧下降。在面对互联网海量数据情况时，所有数据都存于一张表，显然会轻易超过数据库表可承受的数据量阀值。这个单表可承受的数据量阀值，需根据数据库和并发量的差异，通过实际测试获得。

水平拆分如果能预估规模，越早做成本越低。


2.3 为什么分库?
? 单纯的分表虽然可以解决数据量过大导致检索变慢的问题，但无法解决过多并发请求访问同一个库，导致数据库响应变慢的问题。所以通常水平拆分都至少要采用分库的方式，用于一并解决大数据量和高并发的问题。这也是部分开源的分片数据库中间件只支持分库的原因。
3.4 分布式事务？
? 但分表也有不可替代的适用场景。最常见的分表需求是事务问题。同在一个库则不需考虑分布式事务，善于使用同库不同表可有效避免分布式事务带来的麻烦。目前强一致性的分布式事务由于性能问题，导致使用起来并不一定比不分库分表快。目前采用最终一致性的柔性事务居多。分表的另一个存在的理由是，过多的数据库实例不利于运维管理。

mysql本身？ 消息补偿？ 2PC?


3.5 小结
? 综上所述，最佳实践是合理地配合使用分库+分表。
3.6 如何自己实现分库分表？
? 1) dao层，首先通过分区键算出库名表名(如shardKey%shardNum 算出来表index如y，然后y/(shardNum/sourceNum)=x,y是表下标，x是库下标)。 ? 2) 把source从spring容器中拿出来，把表名当参数传进去，拼成分片后的sql。 ? 3) 思路大概是(select … from order where … -> 先拿到db_x的source 然后 select … from order_y where …)

你想这么干？你已经成功了。当然淘宝和当当的架构师也是这么干的。


3.7 SO，不需要我们亲自动手，其实你需要做的只是按照实际需求挑选而已。

3.8 重点介绍两个产品，先不说具体配置，只说思想
? 1) sharding-jdbc（所处位置，通用数据访问层，部署在客户端的jar包，用于将用户的SQL路由到指定的数据库中）

盗一波图



? 2) jproxy

jproxy是什么？


? jproxy提供MariaDB, MySQL等数据库的统一接入访问，拥有流量过载保护，数据自动拆分，可配置路由规则，数据无缝迁移等功能。 ? 应用场景：数据需要分库分表，自动扩容的应用。


为什么分片都是2的n次方？a % (2^n) 等价于 a & (2^n - 1) 其中一个原因就是位运算
扩容？ 虚拟桶。 极限就是一片一库。


演变过程 cobar->mycat->jproxy

mycat是什么?


? 简单的说，就是：一个彻底开源的，面向企业应用开发的“大数据库集群”。支持事务、ACID、可以替代Mysql的加强版数据库，一个的数据库中间件产品。 - 其优势具有： 1) 基于阿里开源的Cobar产品而研发，Cobar的稳定性、可靠性、优秀的架构和性能 2) 拥有众多成熟的使用案例 3) 强大的团队(其参与者都是5年以上资深软件工程师、架构师、DBA等) 4) 开源，创新，持续更新

盗一波图




4、 分组
4.1 为什么分组？
? 分组解决可用性问题

mysql的ha 网洛上的都是vip漂移实现的
盗一波图


 

方案一：MYSQL主从复制（单活）  
方案二：双主（单活），failover比单主简单  
方案三：双主配SAN存储（单活）  
方案四：DRBD 双主配DRBD （单活） 
方案五：NDB CLUSTER 
共享存储? 不需要复制了 更高的一致性
真正的高并发场景，什么架构都抗不住，老老实实用缓存。
需要大量读的场景尽量做到最终一致性。


4.2 同步，异步，半同步
1) 异步复制 (mysql默认)

Master将事件写入binlog，但并不知道Slave是否或何时已经接收且已处理。当Slave准备好才会向Master请求binlog。缺点：不能保证一些事件都能够被所有的Slave所接收。


2) 同步复制

Master提交事务，直到事务在所有的Slave都已提交，此时才会返回客户端，事务执行完毕。缺点：完成一个事务可能会有很大的延迟。


3) 半同步复制

半同步复制工作的机制处于同步和异步之间，Master的事务提交阻塞，只要一个Slave已收到该事务的事件且已记录。它不会等待所有的Slave都告知已收到，且它只是接收，并不用等其完全执行且提交。


半同步复制的步骤： i.当Slave主机连接到Master时，能够查看其是否处于半同步复制的机制。
ii.当Master上开启半同步复制的功能时，至少应该有一个Slave开启其功能。此时，一个线程在Master上提交事务将受到阻塞，直到得知一个已开启半同步复制功能的Slave已收到此事务的所有事件，或等待超时。
iii.当一个事务的事件都已写入其relay-log中且已刷新到磁盘上，Slave才会告知已收到。
iv.如果等待超时，也就是Master没被告知已收到，此时Master会自动转换为异步复制的机制。当至少一个半同步的Slave赶上了，Master与其Slave自动转换为半同步复制的机制。
v.半同步复制的功能要在Master，Slave都开启，半同步复制才会起作用；否则，只开启一边，它依然为异步复制。
4.3 ha方案
4.3.1 MHA
4.3.2 MMM

5、 应用案例
5.1 记录一次mongo迁移mysql的过程(分库分表使用jproxy)
mongo怎么了？跟分片无关的部分简单说。
? mongo很好，只是业界并没有成熟的MongoDB运维经验，jd too。 像高并发的系统 订单和库存 商品 还是拿nosql把，高并发的写,也不会打挂他,比如hbase，顶多GC频繁点，但是也是可用的。 一致性完全可以CAS搞定，而不是mysql的排他锁。

迁移数据库的一个方案 1) 中心化(统一入口) 2) 双写(先同步写mysql如果发生异常改异步，尽量避免服务不可用) 3) 倒库(jproxy支持通过游标形式全量遍历库-逐个表操作，可以利用其异步同步数据) 4) 数据校验 5) 切库提供服务



去mongo+优化方案(此处引入了分片的概念)

压测与性能

去mongo任务线


类型任务备注影线系统风险




design
海关迁移方案设计评审
…
…
无



design
分库分表技术选型
jproxy
…
无



apply
申请迁移相关应用(辅助系统)
跑批任务
…
无



apply
申请mysql集群
dbs系统
…
无



apply
申请jproxy集群
直接找接口人
…
无



apply
申请es集群
esm杰斯
…
无



coding
trace表服务中心化
soa
center
高



coding
涉及trace业务逻辑梳理，全部切换中心接口
接口完全适配
platform
低



verify
回归测试，并线上走单验证一段时间
先预发后正式
…
高



coding
实现mysql版本共2个表sql映射文件
基于自主研发的generator
center
低



verify
mysql版本sql映射文件单元测试
基于自主研发的generator
center
低



coding
trace表实现基于jproxy的分库分表
128个库(主) 1主3从
center
中



coding
es分别按照商家id分片，保税区id分片，异步写，读开放jsf
2套集群4套索引
es
中



coding
中心接口加入代理层，可利用开关切换读mongo/mysql/es
…
center
高



coding
异步补偿mongo,mysql,es功能开发
基于jmq
platform
中



coding
代理层实现mongo和mysql版本互为主被双写(mongo主)，异步写es
双11后mysql主
center
高



verify
线上开双写(包括es)
两套es集群
…
中



coding
倒库功能开发，数据校验功能开发
reactor
config
高



verify
倒库，并进行数据校验
校验规则(特殊字段不校验)
…
高



verify
对中心接口进行压测
线上，压测环境隔离(jsf别名)
…
高



coding
优化配置(mysql调整最大连接数,es使用filterCache)
…
…
高



verify
对中心接口进行压测
…
…
高



verify
升级后架构正式上线
…
…
无



verify
监控切换mysql之后的接口性能
…
…
无



verify
监控切换mysql之后对相关依赖系统的影响
…
…
无



todo
停mongo写
…
…
无



todo
继续迁移海关mongo中其他表(以上均为trace表)
…
…
无



todo
彻底下线mongo数据库服务器，只保留mysql服务器
…
…
无






5.2 记录一次异构具有复杂分片规则数据库的过程
5.2.1 难点
? 交易库存复杂的分片规则，数据量大，更新频繁，一致性保证。

回到本源，缓存+队列

   

本文由职坐标整理发布，学习更多的大数据技术相关知识，请关注职坐标大技术云计算大技术技术频道！