TDDL

为什么要分库分表和读写分离？ 类似淘宝网这样的网站，海量数据的存储和访问成为了系统设计的瓶颈问题，日益增长的业务数据，无疑对数据库造成了相当大的负载，同时对于系统的稳定性和扩展性提出很高的要求。随着时间和业务的发展，数据库中的表会越来越多，表中的数据量也会越来越大，相应地，数据操作的开销也会越来越大；另外，无论怎样升级硬件资源，单台服务器的资源（CPU、磁盘、内存、网络IO、事务数、连接数）总是有限的，最终数据库所能承载的数据量、数据处理能力都将遭遇瓶颈。分表、分库和读写分离可以有效地减小单台数据库的压力。 分库分表的原理和实现 1.什么是分区、分表、分库 分区 就是把一张表的数据分成N个区块，在逻辑上看最终只是一张表，但底层是由N个物理区块组成的，分区实现比较简单，数据库mysql、oracle等很容易就可支持。 分表 就是把一张表按一定的规则分解成N个具有独立存储空间的实体表。系统读写时需要根据定义好的规则得到对应的字表明，然后操作它。 分库 一旦分表，一个库中的表会越来越多 将整个数据库比作图书馆，一张表就是一本书。当要在一本书中查找某项内容时，如果不分章节，查找的效率将会下降。而同理，在数据库中就是分区。 2.什么时候考虑使用分区？ 一张表的查询速度已经慢到影响使用的时候。 sql经过优化 数据量大 表中的数据是分段的 对数据的操作往往只涉及一部分数据，而不是所有的数据

上周六参加了一场由淘宝的架构师，曾宪杰先生主讲的淘宝网架构分享。然后马上就出差了，一直没来得及总结，今晚比较有空，把这次听到的比较有启发的观点记录一下 一、为什么stateless比较有利于实现水平伸缩 关于什么是stateless的扫盲，见这个贴： http://kyfxbl.iteye.com/blog/1831869 一般有一个共识，就是把应用做成无状态的，会比较容易实现水平伸缩。但是以前一直有一个想法，就算应用是有状态的，也可以做成水平伸缩：只需要在负载均衡那里做一个session绑定就可以了，根据某种标识，把请求固定地发送到特定的server上 但是相对于有状态，stateless是更好的，主要有3个原因： 1、负载均衡不需要做session绑定，也就可以用更简单的算法，比如随机、取模等，把请求分配到任意server上，因此相对于session绑定的做法，性能会比较好 2、也是性能的问题，在7层网络模型中，session位于第7层，负载均衡如果是基于session的算法来决定要怎么分发请求，性能的损耗也会比较大 3、如果某一台server down掉了，后续的请求就没法继续往这台server发了，影响可用性 二、为什么淘宝开发session框架 如果将请求所需的信息，都放在cookie里，确实就不需要session框架了，而且也比较容易实现stateless

​ 淘宝根据自身业务需求研发了TDDL（Taobao Distributed Data Layer）框架，主要用于解决分库分表场景下的访问路由（持久层与数据访问层的配合）以及异构数据库之间的数据同步，它是一个基于集中式配置的 JDBC DataSource 实现，具有 分库分表 、 Master/Salve 、 动态数据源配置 等功能。 就目前而言，许多大厂也在出一些更加优秀和社区支持更广泛的DAL层产品，比如Hibernate Shards、Ibatis-Sharding等。TDDL位于数据库和持久层之间，它直接与数据库建立交道，如图所示： ​ 淘宝很早就对数据进行过分库的处理，上层系统连接多个数据库，中间有一个叫做 DBRoute 的路由来对数据进行统一访问。 DBRoute 对数据进行多库的操作、数据的整合，让上层系统像操作一个数据库一样操作多个库。但是随着数据量的增长，对于库表的分法有了更高的要求，例如，你的商品数据到了百亿级别的时候，任何一个库都无法存放了，于是分成2个、4个、8个、16个、32个……直到1024个、2048个。好，分成这么多，数据能够存放了，那怎么查询它？这时候，数据查询的中间件就要能够承担这个重任了，它对上层来说，必须像查询一个数据库一样来查询数据，还要像查询一个数据库一样快（每条查询在几毫秒内完成）， TDDL 就承担了这样一个工作

一、为什么要分库分表 软件时代，传统应用都有这样一个特点：访问量、数据量都比较小，单库单表都完全可以支撑整个业务。随着互联网的发展和用户规模的迅速扩大，对系统的要求也越来越高。因此传统的MySQL单库单表架构的性能问题就暴露出来了。而有下面几个因素会影响数据库性能: 数据量 MySQL单库数据量在5000万以内性能比较好，超过阈值后性能会随着数据量的增大而变弱。MySQL单表的数据量是500w-1000w之间性能比较好，超过1000w性能也会下降。 磁盘 因为单个服务的磁盘空间是有限制的，如果并发压力下，所有的请求都访问同一个节点，肯定会对磁盘IO造成非常大的影响。 数据库连接 数据库连接是非常稀少的资源，如果一个库里既有用户、商品、订单相关的数据，当海量用户同时操作时，数据库连接就很可能成为瓶颈。 为了提升性能，所以我们必须要解决上述几个问题，那就有必要引进分库分表，当然除了分库分表，还有别的解决方案，就是NoSQL和NewSQL，NoSQL主要是MongoDB等，NewSQL则以TiDB为代表。 二、分区分库分表的原理 1、什么是分区、分表、分库 （1）分区 就是把一张表的数据分成N个区块，在逻辑上看最终只是一张表，但底层是由N个物理区块组成的，分区实现比较简单，数据库mysql、oracle等很容易就可支持。 （2）分表

1、TDDL 注意：tddl2.0是2010年的版本，已经没有人维护了。当前版本是5.1.7，网上能够找到的最新版本。项目地址为： https://www.oschina.net/p/tddl5 淘宝根据自己的业务特点开发了TDDL（Taobao Distributed Data Layer 外号:头都大了 ©_Ob）框架，主要解决了分库分表对应用的透明化以及异构数据库之间的数据复制，它是一个基于集中式配置的 jdbc datasource实现，具有主备，读写分离，动态数据库配置等功能。 主要优点： 1.数据库主备和动态切换 2.带权重的读写分离 3.单线程读重试 4.集中式数据源信息管理和动态变更 5.剥离的稳定jboss数据源 6.支持mysql和oracle数据库 7.基于jdbc规范，很容易扩展支持实现jdbc规范的数据源 8.无server,client-jar形式存在，应用直连数据库 9.读写次数,并发度流程控制，动态变更 10.可分析的日志打印,日志流控，动态变更 TDDL必须要依赖diamond配置中心（diamond是淘宝内部使用的一个管理持久配置的系统，目前淘宝内部绝大多数系统的配置，由diamond来进行统一管理，同时diamond也已开源）。 TDDL动态数据源使用示例说明： http://rdc.taobao.com/team/jm/archives

mysql-proxy是官方提供的mysql中间件产品可以实现负载平衡，读写分离，failover等，但其不支持大数据量的分库分表且性能较差。下面介绍几款能代替其的mysql开源中间件产品，Atlas，cobar，tddl，让我们看看它们各自有些什么优点和新特性吧。 Atlas Atlas是由 Qihoo 360, Web平台部基础架构团队开发维护的一个基于MySQL协议的数据中间层项目。它是在mysql-proxy 0.8.2版本的基础上，对其进行了优化，增加了一些新的功能特性。360内部使用Atlas运行的mysql业务，每天承载的读写请求数达几十亿条。 Altas架构： Atlas是一个位于应用程序与MySQL之间，它实现了MySQL的客户端与服务端协议，作为服务端与应用程序通讯，同时作为客户端与MySQL通讯。它对应用程序屏蔽了DB的细节，同时为了降低MySQL负担，它还维护了连接池。 以下是一个可以参考的整体架构，LVS前端做负载均衡，两个Altas做HA,防止单点故障。 Altas的一些新特性： 1.主库宕机不影响读 主库宕机，Atlas自动将宕机的主库摘除，写操作会失败，读操作不受影响。从库宕机，Atlas自动将宕机的从库摘除，对应用没有影响。在mysql官方的proxy中主库宕机，从库亦不可用。 2.通过管理接口，简化管理工作，DB的上下线对应用完全透明

mysql-proxy是官方提供的mysql中间件产品可以实现负载平衡，读写分离，failover等，但其不支持大数据量的分库分表且性能较差。下面介绍几款能代替其的mysql开源中间件产品，Atlas，cobar，tddl，让我们看看它们各自有些什么优点和新特性吧。 Atlas Atlas是由 Qihoo 360, Web平台部基础架构团队开发维护的一个基于MySQL协议的数据中间层项目。它是在mysql-proxy 0.8.2版本的基础上，对其进行了优化，增加了一些新的功能特性。360内部使用Atlas运行的mysql业务，每天承载的读写请求数达几十亿条。 Altas架构： Atlas是一个位于应用程序与MySQL之间，它实现了MySQL的客户端与服务端协议，作为服务端与应用程序通讯，同时作为客户端与MySQL通讯。它对应用程序屏蔽了DB的细节，同时为了降低MySQL负担，它还维护了连接池。 以下是一个可以参考的整体架构，LVS前端做负载均衡，两个Altas做HA,防止单点故障。 Altas的一些新特性： 1.主库宕机不影响读 主库宕机，Atlas自动将宕机的主库摘除，写操作会失败，读操作不受影响。从库宕机，Atlas自动将宕机的从库摘除，对应用没有影响。在mysql官方的proxy中主库宕机，从库亦不可用。 2.通过管理接口，简化管理工作，DB的上下线对应用完全透明

360 Atlas Atlas是由 Qihoo 360, Web平台部基础架构团队开发维护的一个基于MySQL协议的数据中间层项目。它是在mysql-proxy 0.8.2版本的基础上，对其进行了优化，增加了一些新的功能特性。360内部使用Atlas运行的mysql业务，每天承载的读写请求数达几十亿条。 Altas架构： Atlas是一个位于应用程序与MySQL之间，它实现了MySQL的客户端与服务端协议，作为服务端与应用程序通讯，同时作为客户端与MySQL通讯。它对应用程序屏蔽了DB的细节，同时为了降低MySQL负担，它还维护了连接池。 主要功能： 1. 读写分离 2. 从库负载均衡 3. IP过滤 4. SQL语句黑白名单 5. 自动分表 （1）需带有分表字段。 （2）支持SELECT、INSERT、UPDATE、DELETE、REPLACE语句。 （3）支持多个子表查询结果的合并和排序。 6.之前官方主要功能逻辑由使用lua脚本编写，效率低，Atlas用C改写，QPS提高，latency降低。 7.安全方面的提升 （1）通过配置文件中的pwds参数进行连接Atlas的用户的权限控制。 （2）通过client-ips参数对有权限连接Atlas的ip进行过滤。 （3）日志中记录所有通过Altas处理的SQL语句，包括客户端IP、实际执行该语句的DB、执行成功与否、执行所耗费的时间

唯一ID生成 全局唯一ID 《高并发分布式系统中生成全局唯一Id汇总》 Twitter 方案（Snowflake 算法）：41位时间戳+10位机器标识（比如IP，服务器名称等）+12位序列号(本地计数器) Flicker 方案：MySQL自增ID + "REPLACE INTO XXX:SELECT LAST_INSERT_ID();" UUID：缺点，无序，字符串过长，占用空间，影响检索性能。 MongoDB 方案：利用 ObjectId。缺点：不能自增。 《TDDL 在分布式下的SEQUENCE原理》 在数据库中创建 sequence 表，用于记录，当前已被占用的id最大值。 每台客户端主机取一个id区间（比如 1000~2000）缓存在本地，并更新 sequence 表中的id最大值记录。 客户端主机之间取不同的id区间，用完再取，使用乐观锁机制控制并发。 附： * 什么是Snowflake算法 来源： oschina 链接： https://my.oschina.net/u/2339181/blog/1925475