分库分表

在大型互联网应用中，随着用户数的增加，为了提高应用的性能，我们经常需要对数据库进行分库分表操作。在单表时代，我们可以完全依赖于数据库的自增ID来唯一标识一个用户或数据对象。但是当我们对数据库进行了分库分表后，就不能依赖于每个表的自增ID来全局唯一标识这些数据了。因此，我们需要提供一个全局唯一的ID号生成策略来支持分库分表的环境。下面来介绍两种非常优秀的解决方案： ###1. 数据库自增ID——来自Flicker的解决方案 因为MySQL本身支持auto_increment操作，很自然地，我们会想到借助这个特性来实现这个功能。Flicker在解决全局ID生成方案里就采用了MySQL自增长ID的机制（auto_increment + replace into + MyISAM）。一个生成64位ID方案具体就是这样的： 先创建单独的数据库(eg:ticket)，然后创建一个表： CREATE TABLE Tickets64 ( id bigint(20) unsigned NOT NULL auto_increment, stub char(1) NOT NULL default '', PRIMARY KEY (id), UNIQUE KEY stub (stub) ) ENGINE=MyISAM 当我们插入记录后，执行 SELECT * from Tickets64

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 随 着乐视硬件抢购的不断升级，乐视集团支付面临的请求压力百倍乃至千倍的暴增。作为商品购买的最后一环，保证用户快速稳定地完成支付尤为重要。所以在 2015年11月，我们对整个支付系统进行了全面的架构升级，使之具备了每秒稳定处理10万订单的能力。为乐视生态各种形式的抢购秒杀活动提供了强有力的 支撑。 一. 分库分表 在 redis，memcached等缓存系统盛行的互联网时代，构建一个支撑每秒十万只读的系统并不复杂，无非是通过一致性哈希扩展缓存节点，水平扩展 web服务器等。支付系统要处理每秒十万笔订单，需要的是每秒数十万的数据库更新操作（insert加update），这在任何一个独立数据库上都是不可 能完成的任务，所以我们首先要做的是对订单表（简称order）进行分库与分表。 在进行数据库操作时，一般都会有用户ID（简称uid）字段，所以我们选择以uid进行分库分表。 分库策略我们选择了“二叉树分库” ， 所谓“二叉树分库”指的是：我们在进行数据库扩容时，都是以2的倍数进行扩容。比如：1台扩容到2台，2台扩容到4台，4台扩容到8台，以此类推。 这种分库方式的好处是，我们在进行扩容时，只需DBA进行表级的数据同步，而不需要自己写脚本进行行级数据同步。 光是有分库是不够的，经过持续压力测试我们发现，在同一数据库中

前段时间，Oracle官方发布了MySQL 5.7的GA版本。新版本中实现了真正意义的并行复制（基于Group Commit的Group Replication），而不再是基于schema的并行复制。这一特性极大的改善了特定场景下的主从复制延迟过高的状况。随着MySQL成熟度的提升，越来越多的用户选择使用MySQL存放自家的数据，其中不乏使用MySQL来存放大量数据的。 在过去的半年多时间里，听云业务量呈爆发式增长，后端的数据量由去年第一季度的几TB增长到几十TB，业务量翻了十几倍。后端应用及数据库面临的一个突出的问题就是频繁的进行扩容来应对前端流量的增长。数据库层面我们使用MySQL来分布式存储业务数据，数据库集群的架构也比较简单，我们使用开源中间件Amoeba来实现数据的拆分和读写分离。Amoeba后端有几百个数据库的节点组，每个节点组中都包含一对主从实例。master实例负责接受write请求，slave负责接受query请求。如下图： 正确的拆分姿势 随着可选择的开源中间件越来越多，好多数据量并不是很大的使用者都会过早的考虑水平拆分数据库。但其实过早的水平拆分未见得是一件有意义的事情。主要原因有两个：一个方面是水平拆分会对现网的业务造成冲击，如果系统在设计之初就没有考虑过后续要进行拆分的话，这个冲击就会被放大。比如业务中有大量的多表join的查询

一、引言 　　随着互联网应用的广泛普及，海量数据的存储和访问成为了系统设计的瓶颈问题。对于一个大型的互联网应用，每天几十亿的PV无疑对数据库造成了相当高的负载。对于系统的稳定性和扩展性造成了极大的问题。通过数据切分来提高网站性能，横向扩展数据层已经成为架构研发人员首选的方式。水平切分数据库，可以降低单台机器的负载，同时最大限度的降低了了宕机造成的损失。通过负载均衡策略，有效的降低了单台机器的访问负载，降低了宕机的可能性；通过集群方案，解决了数据库宕机带来的单点数据库不能访问的问题；通过读写分离策略更是最大限度了提高了应用中读取（Read）数据的速度和并发量。目前国内的大型互联网应用中，大量的采用了这样的数据切分方案，Taobao,Alibaba,Tencent，它们大都实现了自己的分布式数据访问层（DDAL）。以实现方式和实现的层次来划分，大概分为两个层次（ Java 应用为例）：JDBC层的封装，ORM框架层的实现。就JDBC层的直接封装而言，现在国内发展较好的一个项目是被称作“变形虫”(Amoeba)的项目，由阿里集团的研究院开发，现在仍然处于测试阶段（beta版），其运行效率和生产时效性有待考究。就ORM框架层的实现而言，比如Taobao的基于ibatis和Spring的的分布式数据访问层，已有多年的应用，运行效率和生产实效性得到了开发人员和用户的肯定