13518219792
淘宝开源的TDDL和cobar的结合，放到了阿里云上就是DRDS，是商品，服务，可以购买使用的。可以在阿里云官网上注册免费试用。
让客户满意是我们工作的目标，不断超越客户的期望值来自于我们对这个行业的热爱。我们立志把好的技术通过有效、简单的方式提供给客户，将通过不懈努力成为客户在信息化领域值得信任、有价值的长期合作伙伴，公司提供的服务项目有：主机域名、雅安服务器托管、营销软件、网站建设、郴州网站维护、网站推广。
=====================================================
随着互联网时代的到来，计算机要管理的数据量呈指数级别地飞速上涨，而我们却完全无法对用户数做出准确预估。我们的系统所需要支持的用户数，很可能在短短的一个月内突然爆发式地增长几千倍，数据也很可能快速地从原来的几百GB飞速上涨到了几百个TB。如果在这爆发的关键时刻，系统不稳定或无法访问，那么对于业务将会是毁灭性的打击。
伴随着这种对于系统性能、成本以及扩展性的新需要，以HBase、MongoDB为代表的NoSQL数据库和以阿里DRDS、VoltDB、ScaleBase为代表的分布式NewSQL数据库如雨后春笋般不断涌现出来。
本文将会介绍阿里DRDS的技术理念、发展历程、技术特性等内容。
DRDS设计理念
从20世纪70年代关系数据库创立开始，其实大家在数据库上的追求就从未发生过变化：更快的存取数据，可以按需扩缩以承载更大的访问量和更大的数据量，开发容易，硬件成本低，我们可以把这叫做数据库领域的圣杯。
为了支撑更大的访问量和数据量，我们必然需要分布式数据库系统，然而分布式系统又必然会面对强一致性所带来的延迟提高的问题，因为网络通信本身比单机内通信代价高很多，这种通信的代价就会直接增加系统单次提交的延迟。延迟提高会导致数据库锁持有时间变长，使得高冲突条件下分布式事务的性能不升反降（这个具体可以了解一下Amdahl定律），甚至性能距离单机数据库都还有明显的差距。
从上面的说明，我们可以发现，问题的关键并不是分布式事务做不出来，而是做出来了却因为性能太差而没有什么卵用。数据库领域的高手们努力了40年，但至今仍然没有人能够很好地解决这个问题，Google Spanner的开发负责人就经常在他的Blog上谈论延迟的问题，相信也是饱受这个问题的困扰。
面对这个难题，传统的关系数据库选择了放弃分布式的方案，因为在20世纪70~80年代，我们的数据库主要被用来处理企业内的各类数据，面对的用户不过几千人，而数据量最多也就是TB级别。用单台机器来处理事务，用个磁盘阵列处理一下磁盘容量不够的问题，基本上就能解决一切问题了。
然而，信息化和互联网的浪潮改变了这一切，我们突然发现，我们服务的对象发生了根本性变化，从原来的几千人，变成了现在的几亿人，数据量也从TB级别到了PB级别甚至更多。存在单点的单机系统无论如何努力，都会面对系统处理能力的天花板。原来的这条路，看起来是走不下去了，我们必须想办法换一条路来走。
可是，分布式数据库所面对的强一致性难题却像一座高山，人们努力了无数个日日夜夜，但能翻越这座山的日子看来仍然遥遥无期。
于是，有一群人认为，强一致性这件事看来不怎么靠谱，那彻底绕开这个问题是不是个更好的选择？他们发现确实有那么一些场景是不需要强一致事务的，甚至连SQL都可以不要，最典型的就是日志流水的记录与分析这类场景。而去掉了事务和SQL，接口简单了，性能就更容易得到提升，扩展性也更容易实现，这就是NoSQL系统的起源。
虽然NoSQL解决了性能和扩展性问题，但这种绕开问题的方法给用户带来了很多困扰，系统的开发成本也大大提升。这时候就有另外一群人，他们觉得用户需要SQL，觉得用户也需要事务，问题的关键在于我们要努力地往圣杯的方向不断前进。在保持系统的扩展性和性能的前提下，付出尽可能小的代价来满足业务对数据库的需要。这就是NewSQL这个理念的由来。
DRDS也是一个NewSQL的系统，它与ScaleBase、VoltDB等系统类似，都希望能够找到一条既能保持系统的高扩展性和高性能，又能尽可能保持传统数据库的ACID事务和SQL特性的分布式数据库系统。
DRDS发展历程
在一开始，TDDL的主要功能就是做数据库切分，一个或一组SQL请求提交到TDDL，TDDL进行规则运算后得知SQL应该被分发到哪个机器，直接将SQL转发到对应机器即可（如图1）。
图1 TDDL数据库切分
开始的时候，这种简单的路由策略能够满足用户的需要，我们开始的那些应用，就是通过这样非常简单的方式完成了他所有的应用请求。我们也认为，这种方案简单可靠，已经足够好用了。
然而，当我们服务的应用从十几个增长到几百个的时候，大量的中小应用加入，大家纷纷表示，原来的方案限制太大，很多应用其实只是希望做个读写分离，希望能有更好的SQL兼容性。
于是，我们做了第一次重大升级，在这次升级里，我们提出了一个重要的概念就是三层架构，Matrix对应数据库切分场景，对SQL有一定限制，Group对应读写分离和高可用场景，对SQL几乎没有限制。如图2所示。
图2 数据库升级为三层架构
这种做法立刻得到了大家的认可，TDDL所提供的读写分离、分库分表等核心功能，也成为了阿里集团内数据库领域的标配组件，在阿里的几乎所有应用上都有应用。最为难得的是，这些功能从上线后，到现在已经经历了多年双11的严酷考验，从未出现过严重故障（p0、p1级别故障属于严重故障）。数据库体系作为整个应用系统的重中之重，能做到这件事，真是非常不容易。
随着核心功能的稳定，自2010年开始，我们集中全部精力开始关注TDDL后端运维系统的完善与改进性工作。在DBA团队的给力配合下，围绕着TDDL，我们成功做到了在线数据动态扩缩、异步索引等关键特征，同时也比较成功地构建了一整套分布式数据库服务管控体系，用户基本上可以完全自助地完成整套数据库环境的搭建与初始化工作。
大概是2012年，我们在阿里云团队的支持下，开始尝试将TDDL这套体系输出到阿里云上，也有了个新的名字：阿里分布式数据库服务（DRDS），希望能够用我们的技术服务好更多的人。
不过当我们满怀自信地把自己的软件拿到云上的时候，却发现我们的软件距离用户的要求差距很大。在内部因为有DBA的同学们帮助进行SQL review，所以SQL的复杂度都是可控的。然而到了云上，看了各种渠道提过来的兼容性需求，我们经常是不自觉地发出这样的感叹：“啊？原来这种语法MySQL也是可以支持的？”
于是，我们又进行了架构升级，这次是以兼容性为核心目标的系统升级工作，希望能够在分布式场景下支持各类复杂的SQL，同时也将阿里这么多年来在分布式事务上的积累都带到了DRDS里面。
这次架构升级，我们的投入史无前例，用了三年多才将整个系统落地完成。我们先在内部以我们自己的业务作为首批用户上线，经过了内部几百个应用的严酷考验以后，我们才敢拿到云上，给到我们的最终用户使用。
目前，我们正在将TDDL中更多的积累输出到云上，同时也努力优化我们的用户界面。PS：其实用户界面优化对我们这种专注于高性能后端技术的团队来说，才是最大的技术挑战，连我也去学了AngularJS，参与了用户UI编。
DRDS主要功能介绍
发展历史看完了，下面就由我来介绍一下目前我们已经输出到云上的主要功能。
【分布式SQL执行引擎】
分布式SQL引擎主要的目的，就是实现与单机数据库SQL引擎的完全兼容。目前我们的SQL引擎能够做到与MySQL的SQL引擎全兼容，包括各类join和各类复杂函数等。他主要包含SQL解析、优化、执行和合并四个流程，如图3中绿色部分。
图3 SQL引擎实现的主要流程
虽然SQL是兼容的，但是分布式SQL执行算法与单机SQL的执行算法却完全不同，原因也很简单，网络通信的延迟比单机内通信的延迟大得多。举个例子说明一下，我们有份文件要从一张纸A上誊写到另外一张纸B上，单机系统就好比两张纸都在同一个办公室里，而分布式数据库则就像是一张纸在北京，一张纸在杭州。
自然地，如果两张纸在同一个办公室，因为传输距离近，逐行誊写的效率是可以接受的。而如果距离是北京到杭州，用逐行誊写的方式，就立刻显得代价太高了，我们总不能看一行，就打个“飞的”去杭州写下来吧。在这种情况下，还是把纸A上的信息拍个照片，【一整批的】带到杭州去处理，明显更简单一些。这就是分布式数据库特别强调吞吐调优的原因，只要是涉及到跨机的所有查询，都必须尽可能的积攒一批后一起发送，以减少系统延迟提高带来的不良影响。
【按需数据库集群平滑扩缩】
DRDS允许应用按需将新的单机存储加入或移出集群，DRDS则能够保证应用在迁移流程中实现不停机扩容缩容。
图4 DRDS按需进行平滑扩缩
在内部的数据库使用实践中，这个功能的一个最重要应用场景就是双11了。在双11之前，我们会将大批的机器加入到我们的数据库集群中，抗过了双11，这批机器就会下线。
当DRDS来到云上，我们发现双11其实不仅仅只影响阿里内部的系统。在下游的各类电商辅助性系统其实也面对巨大压力。在双11前5天，网聚宝的熊总就找到我说，担心撑不过双11的流量，怕系统挂。于是我们就给他介绍了这个自动扩容的功能怎么用，他买了一个月的数据库，挂接在DRDS上。数据库能力立刻翻倍，轻松抗过了双11，也算是我印象比较深刻的一个案例了。
因为我们完全无法预测在什么时间点系统会有爆发性的增长，而如果在这时候系统因为技术原因不能使用，就会给整个业务带来毁灭性的影响，风口一旦错过，就追悔莫及了。我想这就是云计算特别强调可扩展能力的原因吧。
【小表广播】
小表广播也是我们在分布式数据库领域内最常用的工具之一，他的核心目的其实都是一个——尽可能让查询只发生在单机。
让我们用一个例子来说明，小表广播的一般使用场景。
图5 小表广播场景
图5中，如果我想知道买家id等于0的用户在商城里面买了哪些商品，我们一般会先将这两个表join起来，然后再用where平台名=”商城” and buyerID = 0找到符合要求的数据。然而这种join的方式，会导致大量的针对左表的网络I/O。如果要取出的数据量比较大，系统延迟会明显上升。
这时候，为了提升性能，我们就必须要减少跨机join的网络代价。我们比较推荐应用做如下处理，将左表复制到右表的每一个库上。这样，join操作就由分布式join一下变回到本地join，系统的性能就有很大的提升了，如图6所示。
图6
【分布式事务套件】
在阿里巴巴的业务体系中存在非常多需要事务类的场景，下单减库存，账务，都是事务场景最集中的部分。
而我们处理事务的方法却和传统应用处理事务的方案不大一样，我们非常强调事务的最终一致性和异步化。利用这种方式，能够极大地降低分布式系统中锁持有的时间，从而极大地提升系统性能。
图7 DRDS分布式事务解决套件
这种处理机制，是我们分布式事务能够以极低成本大量运行的最核心法门。在DRDS平台内，我们将这些方案产品化，为了DRDS的分布式事务解决套件。
利用他们，能够让你以比较低的成本，实现低延迟，高吞吐的分布式事务场景。
DRDS的未来
阿里分布式数据库服务DRDS上线至今，大家对这款产品的热情超出了我们的预期，短短半年内已经有几千个申请。
尽管还在公测期，但是大家就已经把关系到身家性命的宝贵在线数据业务放到了DRDS上，我能够感受到这份沉甸甸的信赖，也不想辜负这份信赖。
经过阿里内部几千个应用的不断历练，DRDS已经积累出一套强大的分布式SQL执行引擎和和一整套分布式事务套件。
我也相信，这些积累能够让用户在基本保持单机数据库的使用习惯的前提下，享受到分布式数据库高性能可扩展的好处。
在平时的DRDS支持过程中，我面对最多的问题就是，DRDS能不能够在不改变任何原有业务逻辑和代码的前提下，实现可自由伸缩和扩展呢？十分可惜的是，关系数据库发展至今，还没有找到既能保留传统数据库一切特性，又能实现高性能可扩展数据库的方法。
然而，虽不能至，吾心向往之！我们会以“可扩展，高性能”为产品核心，坚定地走在追寻圣杯的路上，并坚信最终我们一定能够找寻到它神圣的所在。
作者简介：王晶昱，花名沈询，阿里巴巴资深技术专家。目前主要负责阿里的分布式数据库DRDS（TDDL）和阿里的分布式消息服务ONS（RocketMQ/Notify）两个系统。
上层的是分布式数据库分表分库中间件，负责和上层应用打交道，对应用可表现为一个独立的数据库，而屏蔽底层复杂的系统细节。分布式数据库中间件除了基本的分表分库功能，还可以丰富一下，比如讲读写分离或者水平扩容功能集成在一起，或者比如读写分离本身也可以作为一个独立的中间件。（Cobar, MyCAT, TDDL, DRDS, DDB）
增量数据订阅和消费，用户对数据库操作，比如DML, DCL, DDL等，这些操作会产生增量数据，下层应用可以通过监测这些增量数据进行相应的处理。典型代表Canal，根据MySQL的binlog实现。也有针对Oracle(redolog)的增量数据订阅与消费的中间件。（Canal, Erosa）
数据库同步中间件涉及数据库之间的同步操作，可以实现跨（同）机房同步以及异地容灾备份、分流等功能。可以涉及多种数据库，处理之后的数据也可以以多种形式存储。（Otter, JingoBus, DRC）
数据库与数据库之间会有数据迁移（同步）的动作，同款数据同步原理比较简单，比如MySQL主备同步，只要在数据库层进行相应的配置既可，但是跨数据库同步就比较复杂了，比如Oracle-MySQL. 数据迁移一般包括三个步骤：全量复制，将原数据库的数据全量迁移到新数据库，在这迁移的过程中也会有新的数据产生；增量同步，对新产生的数据进行同步，并持续一段时间以保证数据同步；原库停写，切换新库。将“跨数据库”这个含义扩大一下——“跨数据源”，比如HDFS, HBase, FTP等都可以相互同步。（yugong, DataX）
互联网公司常用的基本集中在以下几种，每种只举一个比较常见或者应用比较成功的例子吧。
1. In-Memory KV Store : Redis
in memory key-value store，同时提供了更加丰富的数据结构和运算的能力，成功用法是替代memcached，通过checkpoint和commit log提供了快速的宕机恢复，同时支持replication提供读可扩展和高可用。
2. Disk-Based KV Store: Leveldb
真正基于磁盘的key-value storage, 模型单一简单，数据量不受限于内存大小，数据落盘高可靠，Google的几位大神出品的精品，LSM模型天然写优化，顺序写盘的方式对于新硬件ssd再适合不过了，不足是仅提供了一个库，需要自己封装server端。
3. Document Store: Mongodb
分布式nosql，具备了区别mysql的最大亮点：可扩展性。mongodb 最新引人的莫过于提供了sql接口，是目前nosql里最像mysql的，只是没有ACID的特性，发展很快，支持了索引等特性，上手容易，对于数据量远超内存限制的场景来说，还需要慎重。
4. Column Table Store: HBase
这个富二代似乎不用赘述了，最大的优势是开源，对于普通的scan和基于行的get等基本查询，性能完全不是问题，只是只提供裸的api,易用性上是短板，可扩展性方面是最强的，其次坐上了Hadoop的快车，社区发展很快，各种基于其上的开源产品不少，来解决诸如join、聚集运算等复杂查询。
NoSQL，指的是非关系型的数据库。NoSQL有时也称作Not Only SQL的缩写，是对不同于传统的关系型数据库的数据库管理系统的统称。
NoSQL用于超大规模数据的存储。（例如谷歌或Facebook每天为他们的用户收集万亿比特的数据）。这些类型的数据存储不需要固定的模式，无需多余操作就可以横向扩展。
NoSQL的优点/缺点
优点:
- 高可扩展性
- 分布式计算
- 低成本
- 架构的灵活性，半结构化数据
- 没有复杂的关系
缺点:
- 没有标准化
- 有限的查询功能（到目前为止）
- 最终一致是不直观的程序 （BY三人行慕课）
阿里云致力于以在线公共服务的方式，提供安全、可靠的计算和数据处理能力，让计算和人工智能成为普惠科技。
阿里云服务着制造、金融、政务、交通、医疗、电信、能源等众多领域的领军企业，包括中国联通、12306、中石化、中石油、飞利浦、华大基因等大型企业客户，以及微博、知乎、锤子科技等明星互联网公司。在天猫双11全球狂欢节、12306春运购票等极富挑战的应用场景中，阿里云保持着良好的运行纪录。
阿里云在全球各地部署高效节能的绿色数据中心，利用清洁计算为万物互联的新世界提供源源不断的能源动力，目前开服的区域包括中国（华北、华东、华南、香港）、新加坡、美国（美东、美西）、欧洲、中东、澳大利亚、日本。
扩展资料：
阿里云主要产品：
1、弹性计算：
云服务器ECS：可弹性扩展、安全、稳定、易用的计算服务
块存储：可弹性扩展、高性能、高可靠的块级随机存储
专有网络VPC：帮您轻松构建逻辑隔离的专有网络
负载均衡：对多台云服务器进行流量分发的负载均衡服务
弹性伸缩：自动调整弹性计算资源的管理服务
资源编排：批量创建、管理、配置云计算资源
容器服务：应用全生命周期管理的Docker服务
高性能计算HPC：加速深度学习、渲染和科学计算的GPU物理机
批量计算：简单易用的大规模并行批处理计算服务
E-MapReduce：基于Hadoop/Spark的大数据处理分析服务
2、数据库：
云数据库RDS：完全兼容MySQL，SQLServer，PostgreSQL
云数据库MongoDB版：三节点副本集保证高可用
云数据库Redis版：兼容开源Redis协议的Key-Value类型
云数据库Memcache版：在线缓存服务，为热点数据的访问提供高速响应
PB级云数据库PetaData：支持PB级海量数据存储的分布式关系型数据库
云数据库HybridDB：基于GreenplumDatabase的MPP数据仓库
云数据库OceanBase：金融级高可靠、高性能、分布式自研数据库
数据传输：比GoldenGate更易用，阿里异地多活基础架构
数据管理：比phpMyadmin更强大，比Navicat更易用
3、存储：
对象存储OSS：海量、安全和高可靠的云存储服务
文件存储：无限扩展、多共享、标准文件协议的文件存储服务
归档存储：海量数据的长期归档、备份服务
块存储：可弹性扩展、高性能、高可靠的块级随机存储
表格存储：高并发、低延时、无限容量的Nosql数据存储服务
4、网络：
CDN：跨运营商、跨地域全网覆盖的网络加速服务
专有网络VPC：帮您轻松构建逻辑隔离的专有网络
高速通道：高速稳定的VPC互联和专线接入服务
NAT网关：支持NAT转发、共享带宽的VPC网关
2018年6月20日，阿里云宣布联合三大运营商全面对外提供IPv6服务。
5、大数据：
MaxCompute：原名ODPS，是一种快速、完全托管的TB/PB级数据仓库解决方案。
QuickBI：高效数据分析与展现平台，通过对数据源的连接，和数据集的创建，对数据进行即席的分析与查询。并通过电子表格或仪表板功能，以拖拽的方式进行数据的可视化呈现。
大数据开发套件：提供可视化开发界面、离线任务调度运维、快速数据集成、多人协同工作等功能，拥有强大的OpenAPI为数据应用开发者提供良好的再创作生态
DataV数据可视化：专精于业务数据与地理信息融合的大数据可视化，通过图形界面轻松搭建专业的可视化应用，满足您日常业务监控、调度、会展演示等多场景使用需求
关系网络分析：基于关系网络的大数据可视化分析平台，针对数据情报侦察场景赋能，如打击虚假交易，审理保险骗赔，案件还原研判等
推荐引擎：推荐服务框架，用于实时预测用户对物品偏好，支持A/BTest效果对比
公众趋势分析：利用语义分析、情感算法和机器学习，分析公众对品牌形象、热点事件和公共政策的认知趋势
企业图谱：提供企业多维度信息查询，方便企业构建基于企业画像及企业关系网络的风险控制、市场监测等企业级服务
数据集成：稳定高效、弹性伸缩的数据同步平台，为阿里云各个云产品提供离线(批量)数据进出通道
分析型数据库：在毫秒级针对千亿级数据进行即时的多维分析透视和业务探索
流计算：流式大数据分析平台，提供给用户在云上进行流式数据实时化分析工具
6、人工智能：
机器学习：基于阿里云分布式计算引擎的一款机器学习算法平台，用户通过拖拉拽的方式可视化的操作组件来进行试验，平台提供了丰富的组件，包括数据预处理、特征工程、算法组件、预测与评估
语音识别与合成：基于语音识别、语音合成、自然语言理解等技术，为企业在多种实际应用场景下，赋予产品“能听、会说、懂你”式的智能人机交互体验
人脸识别：提供图像和视频帧中人脸分析的在线服务，包括人脸检测、人脸特征提取、人脸年龄估计和性别识别、人脸关键点定位等独立服务模块
印刷文字识别：将图片中的文字识别出来，包括身份证文字识别、门店招牌识别、行驶证识别、驾驶证识别、名片识别等证件类文字识别场景
7、云安全：
服务器安全（安骑士）：由轻量级Agent和云端组成，集检测、修复、防御为一体，提供网站后门查杀、通用Web软件0day漏洞修复、安全基线巡检、主机访问控制等功能，保障服务器安全
DDoS高防IP：云盾DDoS高防IP是针对互联网服务器（包括非阿里云主机）在遭受大流量的DDoS攻击后导致服务不可用的情况下，推出的付费增值服务，用户可以通过配置高防IP，将攻击流量引流到高防IP，确保源站的稳定可靠
Web应用防火墙：网站必备的一款安全防护产品。通过分析网站的访问请求、过滤异常攻击，保护网站业务可用及资产数据安全
加密服务：满足云上数据加密，密钥管理、加解密运算需求的数据安全解决方案
CA证书服务：云上签发Symantec、CFCA、GeoTrustSSL数字证书，部署简单，轻松实现全站HTTPS化，防监听、防劫持，呈现给用户可信的网站访问
数据风控：凝聚阿里多年业务风控经验，专业、实时对抗垃圾注册、刷库撞库、活动作弊、论坛灌水等严重威胁互联网业务安全的风险
绿网：智能识别文本、图片、视频等多媒体的内容违规风险，如涉黄，暴恐，涉政等，省去90%人力成本
安全管家：基于阿里云多年安全实践经验为云上用户提供的全方位安全技术和咨询服务，为云上用户建立和持续优化云安全防御体系，保障用户业务安全
云盾混合云：在用户自有IDC、专有云、公共云、混合云等多种业务环境为用户建设涵盖网络安全、应用安全、主机安全、安全态势感知的全方位互联网安全攻防体系
态势感知：安全大数据分析平台，通过机器学习和结合全网威胁情报，发现传统防御软件无法覆盖的网络威胁，溯源攻击手段、并且提供可行动的解决方案
先知：全球顶尖白帽子和安全公司帮你找漏洞，最私密的安全众测平台。全面体检，提早发现业务漏洞及风险，按效果付费
移动安全：为移动APP提供安全漏洞、恶意代码、仿冒应用等检测服务，并可对应用进行安全增强，提高反破解和反逆向能力。
8、互联网中间件：
企业级分布式应用服务EDAS：以应用为中心的中间件PaaS平台、
消息队列MQ：ApacheRocketMQ商业版企业级异步通信中间件
分布式关系型数据库服务DRDS：水平拆分/读写分离的在线分布式数据库服务
云服务总线CSB：企业级互联网能力开放平台
业务实施监控服务ARMS：端到端一体化实时监控解决方案产品
9、分析：
E-MapReduce：基于Hadoop/Spark的大数据处理分析服务
云数据库HybirdDB：基于GreenplumDatabase的MPP数据仓库
高性能计算HPC：加速深度学习、渲染和科学计算的GPU物理机
大数据计算服务MaxCompute：TB/PB级数据仓库解决方案
分析型数据库：海量数据实时高并发在线分析
开放搜索：结构化数据搜索托管服务
QuickBI：通过对数据源的连接，对数据进行即席分析和可视化呈现。
参考资料：
百度百科-阿里云
