做个网站需要多久,新闻资讯到底是哪个公司的,中国建设银行网站签名通下载安装,女生做运营以后的发展来源 | 阿丸笔记封图| CSDN 下载于视觉中国前言随着业务的发展#xff0c;MySQL数据库中的表会越来越多#xff0c;表中的数据量也会越来越大#xff0c;相应地#xff0c;数据操作的开销也会越来越大#xff1b;另外#xff0c;无论怎样升级硬件资源#xff0c;单台服务… 来源 | 阿丸笔记封图| CSDN 下载于视觉中国前言随着业务的发展MySQL数据库中的表会越来越多表中的数据量也会越来越大相应地数据操作的开销也会越来越大另外无论怎样升级硬件资源单台服务器的资源CPU、磁盘、内存、网络IO、事务数、连接数总是有限的最终数据库所能承载的数据量、数据处理能力都将遭遇瓶颈。分表、分库和读写分离可以有效地减小单台数据库的压力。而数据库中间件也火了很长一段时间基本上每个大厂都会自研一套。本文主要针对业界主流的数据库中间件的实现、功能、成本等方面进行对比总结数据库中间件的实现方式并展望未来的可能发展。实现方式一般来说对于数据库中间件可以在以下六个层次做切入。2.1 代码层在同一个项目中创建多个数据源采用if else的方式直接根据条件在代码中路由。Spring中有动态切换数据源的抽象类具体参见AbstractRoutingDataSource。如果项目不是很庞大使用这种方式能够快速的进行分库。但缺点也是显而易见的这种海量的代码侵入是绝不能被接受的。而且当查询结果返回时需要对跨库、聚合等查询结果进行归并开发工作量非常巨大。这种方式了解一下即可一般不会去使用。2.2 框架层主要是修改或增强现有ORM框架的功能在SQL中增加一些自定义原语或者hint来实现。常见的比如实现一些拦截器比如Mybatis的Interceptor接口增加一些自定义解析来控制数据的流向效果虽然较好但会改变一些现有的编程经验。这种情况适合公司ORM框架统一的情况但在很多情况下不太现实。而且大部分情况下要修改框架源码因此也不推荐。2.3 驱动层无论是从代码层还是框架层做处理都是高侵入、难维护的。因此常见的数据库中间件至少需要从驱动层开始我们可以理解为一个smart-client。什么意思是smart-client呢通常smart-client是在连接池或者driver的基础上进行了一层封装。这个smart-client内部可以与不同的数据库建立连接。服务需要查询的sql就交给smart-client进行解析、优化然后发送给具体的数据库进行操作。例如在读写分离情况下smart-client会选择sql走从库还是主库在分库分表的情况下进行sql解析、sql改写等操作然后路由到不同的分库将得到的结果进行合并返回给应用。我们熟知的TDDL、Sharding-JDBC等都是在此层切入。优点1实现方便业务无入侵。smart-client不需要实现客户端通信协议只需要在数据数据库厂商提供的不同语言的数据库驱动上做封装即可。例如mysql针对java语言提供了mysql-connector-java驱动针对python提供了mysql-connector-python驱动。2天然去中心化。smart-client以sdk的方式被应用引入然后部署到不同的服务节点上不需要有代理层proxy。因此相较于代理方式而言不需要考虑高可用的问题。只要应用的节点没有全部宕机就可以访问数据库。(这里的高可用是相比代理层proxy而言数据库本身的高可用还是需要保证的)缺点1通常仅支持某一种语言。例如tddl、zebra、sharding-jdbc都是使用java语言开发因此对于使用其他语言的用户就无法使用这些中间件。如果其他语言要使用那么就要开发多语言客户端。2版本升级困难。因为应用使用数据源代理就是引入一个jar包的依赖在有多个应用都对某个版本的jar包产生依赖时一旦这个版本有bug所有的应用都需要升级。而数据库代理升级则相对容易因为服务是单独部署的只要升级这个代理服务器所有连接到这个代理的应用自然也就相当于都升级了。3去中心化的缺点比如无法做全局的sql限流2.4 代理层在应用中我们通过一个普通的数据源(c3p0、druid、dbcp等)与代理服务器建立连接所有的sql操作语句都是发送给这个代理由这个代理去操作底层数据库得到结果并返回给应用。在这种方案下分库分表和读写分离的逻辑对开发人员是完全透明的。像MySQL Router、MyCat、ShardingSphereproxy模式等都是在此层切入。优点1多语言支持。也就是说不论你用的php、java或是其他语言都可以支持。以mysql数据库为例如果proxy本身实现了mysql的通信协议那么你可以就将其看成一个mysql 服务器因此不同语言的开发者都可以使用mysql官方提供的对应的驱动来与这个代理服务器建通信。2对业务开发同学透明。由于可以把proxy当成mysql服务器理论上业务同学不需要进行太多代码改造既可以完成接入。缺点1实现复杂。因为proxy需要实现被代理的数据库server端的通信协议实现难度较大。2proxy本身需要保证高可用。由于应用本来是直接访问数据库现在改成了访问proxy意味着proxy必须保证高可用。否则数据库没有宕机proxy挂了导致数据库无法正常访问就尴尬了。3租户隔离。可能有多个应用访问proxy代理的底层数据库必然会对proxy自身的内存、网络、cpu等产生资源竞争proxy需要需要具备隔离的能力。2.5 SidecarSharding-Sidecar是ShardingSphere的第三个产品目前仍然在规划中。定位为Kubernetes或Mesos的云原生数据库代理以DaemonSet的形式代理所有对数据库的访问。通过无中心、零侵入的方案提供与数据库交互的的啮合层即Database Mesh又可称数据网格。Database Mesh的关注重点在于如何将分布式的数据访问应用与数据库有机串联起来它更加关注的是交互是将杂乱无章的应用与数据库之间的交互有效的梳理。使用Database Mesh访问数据库的应用和数据库终将形成一个巨大的网格体系应用和数据库只需在网格体系中对号入座即可它们都是被啮合层所治理的对象。优点分布式云原生的数据库中间件模式集成了jdbc和proxy各自的优点能满足高可用、跨语言、无感知升级等多种优势特性缺点需要整体架构支持云原生体系目前还没正式上线。2.6 存储层这个层次实际上不应该叫数据库中间件了需要更换存储。比如Aurora、polardb、tidb等分布式数据库通过计算节点和存储节点分离计算节点scale up存储节点scale out的理念将公有云的关系数据库产品推向了一个新的高度。这样一来实际上已经不再需要传统的数据库中间件了一切问题天然就不存在了。功能对比从上文可以了解到目前最主流的数据库中间件主要是从驱动层smart-client和代理层proxy切入的。下面我们来了解下业界主流的中间件产品在这两个层次的站队情况与实现的功能对比。其他还有比如Atlas、Kingshard、DBProxy、mysql router、MaxScale、58 Oceanus、ArkProxy、Ctrip DAL、Tsharding、Youtube vitess、网易DDB、Heisenberg、proxysql、Mango、DDAL、Datahekr、MTAtlas、我们可以看到基本各个大厂都撸过一遍自己的中间件产品。不过目前开源而且比较火的已经不多了主要还是以shardingsphere为主。我们从功能维度来对比一下几个产品。展望从上文的分析可以看出尽管目前主流的数据库中间件还是在smart-client和proxy两个层面进行处理的但是已经能看到未来的方向了。云原生的到来数据库中间件也会拥抱变化。一方面是作为sidecar的模式可能会有一个新的阶段比如shardingsphere推出sidecar模式后。而另一方面云数据库通过全新的计算存储分离的架构方式打破传统关系型数据库的性能瓶颈传统数据库中间件将不再需要关注一切都将以数据库基础设施的形式提供给使用者。推荐阅读还不知道 AWS 是什么这 11 个重点带你认识 AWS
数据库连接池的原理没你想得这么复杂
为什么程序员如此“嫌弃”主干开发模式
智能合约编写之 Solidity 的设计模式
2020年5种将死的编程语言
我去同事居然用明文存储密码
真香朕在看了
