你好，我是EverDB！
初次见面，先自我介绍一下，我的正式名称是“安沃分布式数据库系统”，不过，朋友们更喜欢称呼我“EverDB”。我是G行分布式家族中的一员，承担着分布式架构下实现数据库高可用、可扩展的重任。
我的诞生
我的诞生正逢其时。在这个金融科技创新的时代，对数据库大并发、高频次的访问和可扩展性需求与日俱增，集中式数据库架构的限制和制约逐渐显现。为满足业务发展需求，G行科技人根据金融业务特点和分布式数据库产品特性采取了双轨并行的策略，在引入了分布式数据库产品的同时，和合作伙伴一起,共同打造自主知识产权的分布式数据库方案，于是我诞生了。
技术架构
当前，主流的分布式数据库技术方案有两种：
一种以中间层为核心，基于开源数据库自动化分库分表的架构。开源数据库比如MySQL,PostgreSQL,都经过了长时间的生产上的磨砺，产品功能相对稳定。而中间层则是需要自主打磨的部分，实现分库分表对应用透明化。国内在这个领域也有比较著名的产品，比如阿里的Cobar、TDDL，后来社区基于Cobar改进的MyCAT，360开源的Atlas，还有我的兄弟—万里开源的GreatDB。
另一种是关系模型和NoSQL设计相融合的NewSQL技术方案，采用sql above nosql的设计思想，保留了关系型数据库的SQL特性、事务特性，同时借鉴了NoSQL数据库强扩展性的设计理念，但这种技术方案发展时间相对较短，处在不断演进过程中。国内也有相应的数据库产品，比如PingCAP开源的TiDB，蚂蚁金服的商业数据库OceanBase。
两种架构各有优势，在G行都有广泛的应用空间。从架构上说，我属于第一种技术方案。但是，我不重复别人，也不想重复自己！
上面是我的完整技术架构，由多个技术组件构成的分布式阵容，可谓进可攻退可守。
EDB-Grid：是我最核心的组件，具有全局调度能力，负责全局事务管理、分布式执行计划的生成与调度、集群扩缩容、数据节点的故障自动切换等。
数据节点：是我的数据存储层，基于MySQL社区版本，支持MySQL主从架构和MGR架构，主要负责数据的存储、本地事务管理、本地结果集计算等。
配置节点：基于Zookeeper实现，负责我在运行态的元数据存储、同步、与配置管理。
EDB-Control：是仪表盘，也是运维管理控制台，负责我的全生命周期管理。
EDB-Bridge：数据同步工具，负责将我的数据增量同步给其他异构数据库。
逃离库：基于传统集中式数据库（目前是MySQL）的异构热备，通过EDB-Bridge组件从我这里实时同步增量数据，用于增强新技术引入过程中的风险抵御能力。当我在运行时不幸遭遇“黑天鹅事件”时，可通过逃离库提供核心业务能力，这是运行的安全带。
没错，我是通过多组件共同协作来实现整个分布式数据库调度、存储、计算、管理、数据迁移等能力！
技术特性
为了满足业务需求和集群的安全可靠性要求，我练就了一身武艺，是时候展示一下了。
1.数据分片
Sharding（分片）是我练就的核心武功，这里的Sharding主要指表的横向拆分。根据业务表的特点不同，可分为全局表、普通表、分片表。
全局表像是“数据字典”，就是系统中所有的表都可能依赖的表，特点是数据量较小、变更频率低、且可能跟其他表产生关联查询的表；
普通表是数据量相对不大、变更频率不高、且不会和分片表产生关联查询的表；
分片表是数据量较大或交易访问频率较高的表，需要通过数据Sharding来分散数据部署或交易访问量的表。
全局表会在集群内进行广播，使联表查询尽量在单个节点完成，通过避免跨节点join来提升SQL执行效率和数据库性能。
分片表主要支持hash、mod、list、range四种分片算法，为有效的打散数据分布，hash和mod是较为常用的分片算法，当然你也可以自定义分片算法。EDB-Grid通过对分片键应用分片算法，将数据分散部署到集群中不同的节点上，而对于应用来说这种分布式部署是透明的，就像使用单机数据库一样。
在分布式数据库应用中，分片键的选择至关重要。那么怎么选择分片键呢？当然是应该选择离散型较好的字段作为分片键，且不同的分片表尽量选择相同的分片键，是不是有些熟悉的味道？同样的优化原则，通过避免分片表跨节点join来提升SQL执行效率和数据库性能。
2.SQL执行优化
那么，你可能会问：“当接收到应用发来的一条SQL语句后，EverDB要怎样处理呢？”OK，接下来我简单介绍一下SQL语句的处理流程和遵循的优化原则。
当接收到应用的SQL后，我会先进行SQL语法解析，然后生成分布式执行计划，在这个过程中我会遵循一些优化原则，比如查询计算下推、跨节点并行计算、通过必要的SQL改写提升执行效率等，最后根据执行计划对并行计算的结果进行归并，并将归并结果返回给应用端。
举个例子，如下图所示，这是个排序分页SQL，通过优化原则将SQL进行必要的改写，然后将改写后的SQL并行下发到相关的数据节点执行，最后将数据节点返回的结果集归并再limit，得到最终结果集返回给应用。
3.通信协议
用什么客户端与我通信?忘记告诉你了，我能够完美兼容MySQL通信协议，并能兼容绝大部分常用的MySQL语法和功能，所以你只需要使用MySQL客户端，像使用单机MySQL一样和我对话就OK啦！
4.分布式事务
如你所知，事务是关系型数据库一个非常重要的特性，也是金融大部分业务场景必要的功能需求，支持事务需要实现事务的ACID四个特性，即原子性、一致性、隔离性、持久性。
在分布式数据库中，当一个事务中的SQL出现跨节点操作，又需要保证ACID特性时，就被称为分布式事务。由于涉及多节点操作，分布式事务的实现难度远大于单机事务。当然我是支持分布式事务的，简单来说是基于XA事务协议，采用两阶段提交（2PC）的方法实现的，具体实现细节这里就不详细阐述了。
分布式事务可以最大程度的保证数据库操作的原子性，但由于事务提交时需要协调多个数据节点，这里会存在一个“木桶效应”，事务执行的时间会取决于执行效率最低的数据节点，当事务执行时间较长时，会增加事务间锁冲突或者死锁的概率。因此对于事务的使用，建议遵循“能不用事务就不用事务，能用小事务的不用大事务”原则。
5.数据库安全
亦如你所知，数据是银行业务经营的核心资产，也是企业的核心竞争力。敏感数据信息泄露会直接影响客户的利益，损害银行的信誉，降低银行的行业竞争力。因此企业级数据安全建设是重要且必要的。
而我在数据库安全方面也是有一定修炼的，主要体现在访问安全、安全审计、数据安全三个方面：通过支持账户密码访问，设置黑白名单，数据库表授权，访问时段、流控、危险操作防御，登陆失败防护增强，通信ssl加密来实现访问的安全性；可以针对操作类型、操作对象、操作用户来进行安全审计；通过支持数据加密，数据多副本多机房部署来增强数据安全性。
6.全组件高可用
对于高可用性问题，如果设计不好，那么DBA可能就要受累了，想必会伤痕累累吧，当然对客户体验和银行的声誉也是有损的。所以我也充分考虑了这一点，通过双机房部署、全组件冗余设计，故障自动感知、自动切换来实现整个集群的高可用性。
配置组件的高可用采用了Zookeeper原生高可用方案；EDB-Grid调度组件基本属于无状态组件，通过F5或LVS等实现负载均衡、故障感知、和故障转移；数据节点通过MySQL增强半同步复制技术实现数据多副本，使用类raft协议实现主节点的故障检测、leader选举、和自动故障切换；而EDB-Control组件则通过keepalived保证其高可用性。
那么除此之外，我还支持读写分离，正在修炼数据的动态扩展，同时在安全可控方面，我和国产ARM平台的适配也在紧锣密鼓的进行中。
在EverDB领域内，有几个重要概念应该了解一下，这样我们才有共同语言，是不是？
DataServer
DataServer与数据节点上的MySQLServer一一对应，无论是主库（Master）还是从库（Slave），都是一个EverDB的DataServer，在EverDB的Grid层中记录了这些Server的地址、端口。DataServer是Grid调度、切换的物理对象。
DataSource
DataSource是EverDB中的一个逻辑概念，将一个MySQL主从复制（或MGR）集群在Grid层对应为一个DataSource，对应用来说，隐藏了数据节点的复杂的高可用配置。
PartitionScheme
PartitionScheme是EverDB实现分布式横向扩展、负载均衡的核心。它定义了分片策略，由多个DataSource组成。EDB-Grid通过分片策略在分片键上的应用，自动将分片表的数据分散部署到不同的DataSource。这样，分片配置对应用变得简单、透明。
DataSpace
DataSpace定义EverDB中表与数据库（Schema）、DataSource、PartitionScheme之间的映射规则，表示数据对象和数据存储位置的对应关系。不分片的表，可以通过名称与一个DataSource匹配映射；而分片表，则通过名称与PartitionScheme匹配映射。
总结一下一张表在EverDB中的奇妙旅程：首先，表通过DataSpace中定义的名称匹配规则，映射到一个PartitionScheme或者一个DataSource。如果映射到了PartitionScheme,那么就根据PartitionScheme定义的分片规则，打散到不同的DataSource。然后，根据DataSource的定义，表存储到特定的MySQL高可用集群。通过上面4个层次的组合关系，从逻辑概念一层层落到了物理节点上，怎么样，是不是有点意思？
我的理想
志当存高远，理想还是要有的，万一实现了呢？
我还很年轻，需要修炼的能力还有很多，包括功能的丰富性、性能提升、安全加固、服务稳定性等方面。所以我的理想是能够成为一个简单、健壮、灵活部署、智能化运维的分布式数据库。
如果问我征途在哪里？我期待着在云端飞扬奔腾！
图文作者：李超、李萧萧、王莉莉、陈硕、郑皓广（左起）
