| <?xml version="1.0" encoding="utf-8" standalone="yes"?> |
| <rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"> |
| <channel> |
| <title>ShardingSphere - 博客</title> |
| <link>https://shardingsphere.apache.org/blog/cn/</link> |
| <description>Recent content on ShardingSphere - 博客</description> |
| <generator>Hugo -- gohugo.io</generator> |
| <language>en-us</language><atom:link href="https://shardingsphere.apache.org/blog/cn/index.xml" rel="self" type="application/rss+xml" /> |
| <item> |
| <title>ShardingSphere 与 openGauss 的化学反应</title> |
| <link>https://shardingsphere.apache.org/blog/cn/videos/opengauss/</link> |
| <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> |
| |
| <guid>https://shardingsphere.apache.org/blog/cn/videos/opengauss/</guid> |
| <description>5 月 29 日，由 openGauss 社区主办，北京鲲鹏联合创新中心、云和恩墨、深信服、SphereEx 合力承办的“【北京】openGauss Meetup”活动在北京海淀区中关村智能制造创新中心成功举行，此次 Meetup 也是 SphereEx 正式加入 openGauss 社区后的首次联合活动。在 Meetup 现场，SphereEx CEO 张亮从产品形态、部署架构、性能测试、未来规划等方面为大家带来了《ShardingSphere 与 openGauss 的化学反应》主题分享。 |
| </description> |
| </item> |
| |
| <item> |
| <title>揭秘 Sharding-Proxy——面向DBA的数据库中间层</title> |
| <link>https://shardingsphere.apache.org/blog/cn/material/proxy/</link> |
| <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> |
| |
| <guid>https://shardingsphere.apache.org/blog/cn/material/proxy/</guid> |
| <description>讲师介绍 张永伦：京东金融运维部高级软件工程师 |
| 曾在传统行业工作多年，从事基础软件开发工作。后投身互联网，在京东金融开始了爬虫生涯，感叹互联网数据量之大，但心中仍对偏底层的软件感兴趣。今年有幸加入到 Sharding-Sphere，能够做自己感兴趣的事情，希望以后多做些工作，提升自己，回报社区。 |
| 大家好，我今天想跟大家分享的是 Sharding-Sphere 的第二个产品 Sharding-Proxy。 |
| 在上个月亮相的 Sharding-Sphere 3.0.0.M1 中首次发布了 Sharding-Proxy，希望这次分享能够通过几个优化实践，帮助大家管中窥豹，从几个关键细节想象出 Sharding-Proxy 的全貌。至于更详细的 MySQL 协议、IO 模型、Netty 等议题，以后有机会再和大家专题分享。 |
| 一、Sharding-Proxy 简介 1. Sharding-Proxy 概览 Sharding-Proxy 定位为透明化的数据库代理端，提供封装了数据库二进制协议的服务端版本，用于完成对异构语言的支持。目前先提供 MySQL 版本，它可以使用任何兼容 MySQL 协议的访问客户端操作数据（如：MySQLCommandClient、MySQLWorkbench 等），对 DBA 更加友好。 |
| 对应用程序完全透明，可直接当做 MySQL 使用； |
| 适用于任何兼容 MySQL 协议的客户端。 |
| 与其他两个产品（Sharding-JDBC、Sharding-Sidecar）的对比： |
| 它们既可以独立使用，也可以相互配合，以不同的架构模型、不同的切入点，实现相同的功能目标。而其核心功能，如数据分片、读写分离、柔性事务等，都是同一套实现代码。 |
| 举个例子，对于仅使用 Java 为开发技术栈的场景，Sharding-JDBC 对各种 Java 的 ORM 框架支持度非常高，开发人员可以非常便利地将数据分片能力引入到现有的系统中，并将其部署至线上环境运行，而 DBA 就可以通过部署一个 Sharding-Proxy 实例，对数据进行查询和管理。 |
| 2. Sharding-Proxy 架构 整个架构可以分为前端、后端和核心组件三部分来看： |
| 前端（Frontend）负责与客户端进行网络通信，采用的是基于NIO的客户端/服务器框架，在 Windows 和 Mac 操作系统下采用 NIO 模型，Linux 系统自动适配为 Epoll 模型，在通信的过程中完成对 MySQL 协议的编解码；</description> |
| </item> |
| |
| <item> |
| <title>【开源总动员】零基础入门 Apache ShardingSphere 开源之道</title> |
| <link>https://shardingsphere.apache.org/blog/cn/videos/opensource/</link> |
| <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> |
| |
| <guid>https://shardingsphere.apache.org/blog/cn/videos/opensource/</guid> |
| <description>Apache ShardingSphere 是 Apache 基金会目前唯一的数据库中间件项目。它主要用于数据分片、分布式事务和分布式治理等分布式数据库相关场景。本次直播将分享为什么要参与开源；Apache 开源软件基金会、Apache ShardingSphere 核心原理及如何踏上开源之路。 |
| </description> |
| </item> |
| |
| <item> |
| <title>分布式事务在Sharding-Sphere中的实现</title> |
| <link>https://shardingsphere.apache.org/blog/cn/material/realization/</link> |
| <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> |
| |
| <guid>https://shardingsphere.apache.org/blog/cn/material/realization/</guid> |
| <description>讲师简介 赵俊 |
| 京东金融 |
| 高级Java开发工程师 |
| 多年互联网开发经验，热爱开源技术，对分布式存储有浓厚的兴趣。熟悉ElasticSearch、HBase、Presto、Storm等离线和实时数据处理 |
| 目前主要在Sharding-Sphere团队负责分布式事务的开发 |
| 分布式事务的使用场景 ACID 一切从ACID开始说起。ACID是本地事务所具有的四大特征： |
| Atomicity：原子性 |
| 事务作为整体来执行，要么全部执行，要么全不执行。 |
| Consistency：一致性 |
| 事务应确保数据从一个一致的状态转变为另一个一致的状态。 |
| Isolation：隔离性 |
| 多个事务并发执行时，一个事务的执行不应影响其他事务的执行。 |
| Durability：持久性 |
| 已提交的事务修改数据会被持久保持。 |
| 关系型数据库的本地事务完美的提供了对ACID的原生支持。但在分布式的场景下，它却成为系统性能的桎梏。如何让数据库在分布式场景下满足ACID的特性或找寻相应的替代方案，是本文将要阐述的话题。 |
| CAP和Base理论 对于互联网应用而言，随着访问量和数据量的激增，传统的单体架构模式将无法满足业务的高速发展。这时，开发者需要把单体应用拆分为多个独立的小应用，把单个数据库按照分片规则拆分为多个库和多个表。 |
| 数据拆分后，如何在多个数据库节点间保证本地事务的ACID特性则成为一个技术难题，并且由此而衍生出了CAP和BASE经典理论。 |
| CAP理论指出，对于分布式的应用而言，不可能同时满足C（一致性），A（可用性），P（分区容错性），由于网络分区是分布式应用的基本要素，因此开发者需要在C和A上做出平衡。 |
| 由于C和A互斥性，其权衡的结果就是BASE理论。 |
| 对于大部分的分布式应用而言，只要数据在规定的时间内达到最终一致性即可。我们可以把符合传统的ACID叫做刚性事务，把满足BASE理论的最终一致性事务叫做柔性事务。 |
| 一味的追求强一致性，并非最佳方案。对于分布式应用来说，刚柔并济是更加合理的设计方案，即在本地服务中采用强一致事务，在跨系统调用中采用最终一致性。如何权衡系统的性能与一致性，是十分考验架构师与开发者的设计功力的。 |
| 业界方法 具体到分布式事务的实现上，业界主要采用了XA协议的强一致规范以及柔性事务的最终一致规范。 |
| XA XA是X/Open CAE Specification (Distributed Transaction Processing)模型中定义的TM（Transaction Manager）与RM（Resource Manager）之间进行通信的接口。 |
| Java中的javax.transaction.xa.XAResource定义了XA接口，它依赖数据库厂商对jdbc-driver的具体实现。 |
| mysql-connector-java-5.1.30的实现可参考： |
| com.mysql.jdbc.jdbc2.optional.MysqlXAConnection。 |
| 在XA规范中，数据库充当RM角色，应用需要充当TM的角色，即生成全局的txId，调用XAResource接口，把多个本地事务协调为全局统一的分布式事务。 |
| 一阶段提交：弱XA |
| 弱XA通过去掉XA的Prepare阶段，以达到减少资源锁定范围而提升并发性能的效果。典型的实现为在一个业务线程中，遍历所有的数据库连接，依次做commit或者rollback。弱XA同本地事务相比，性能损耗低，但在事务提交的执行过程中，若出现网络故障、数据库宕机等预期之外的异常，将会造成数据不一致，且无法进行回滚。基于弱XA的事务无需额外的实现成本，因此Sharding-Sphere默认支持。 |
| 二阶段提交：2PC |
| 二阶段提交是XA的标准实现。它将分布式事务的提交拆分为2个阶段：prepare和commit/rollback。 |
| 开启XA全局事务后，所有子事务会按照本地默认的隔离级别锁定资源，并记录undo和redo日志，然后由TM发起prepare投票，询问所有的子事务是否可以进行提交：当所有子事务反馈的结果为“yes”时，TM再发起commit；若其中任何一个子事务反馈的结果为“no”，TM则发起rollback；如果在prepare阶段的反馈结果为yes，而commit的过程中出现宕机等异常时，则在节点服务重启后，可根据XA recover再次进行commit补偿，以保证数据的一致性。 |
| 2PC模型中，在prepare阶段需要等待所有参与子事务的反馈，因此可能造成数据库资源锁定时间过长，不适合并发高以及子事务生命周长较长的业务场景。 |
| Sharding-Sphere支持基于XA的强一致性事务解决方案，可以通过SPI注入不同的第三方组件作为事务管理器实现XA协议，如Atomikos和Narayana。 |
| 柔性事务 柔性事务是对XA协议的妥协和补偿，它通过对强一致性要求的降低，已达到降低数据库资源锁定时间的效果。柔性事务的种类很多，可以通过各种不同的策略来权衡使用。 |
| 一阶段提交 + 补偿 ：最大努力送达（BED）</description> |
| </item> |
| |
| <item> |
| <title>ShardingSphere 的 Apache 共建之道</title> |
| <link>https://shardingsphere.apache.org/blog/cn/videos/build/</link> |
| <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> |
| |
| <guid>https://shardingsphere.apache.org/blog/cn/videos/build/</guid> |
| <description>Apache ShardingSphere 项目 VP&ndash;张亮老师带来 ShardingSphere 项目与开源之道的精彩讲解。张亮，京东数科数据研发负责人，Apache ShardingSphere 发起人 &amp; PPMC，JDTX 负责人。ShardingSphere 已经进入 Apache 孵化器，是京东集团首个进入 Apache 基金会的开源项目，也是 Apache 基金会首个分布式数据库中间件。 |
| </description> |
| </item> |
| |
| <item> |
| <title>剖析Sharding-Sphere系列——结果归并 </title> |
| <link>https://shardingsphere.apache.org/blog/cn/material/result/</link> |
| <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> |
| |
| <guid>https://shardingsphere.apache.org/blog/cn/material/result/</guid> |
| <description>这一系列文章是由SS的核心开发成员亲自操刀向大家介绍和剖析SS的核心模块、所使用的前沿技术、有价值的经验总结等。这一系列的文章将带您走进SS的内核世界，获得新知、激发灵感。更希望您关注我们，共同交流切磋，一同前行。 |
| 讲师介绍 张亮，原当当架构部负责人。热爱开源，目前主导两个开源项目Elastic-Job和Sharding-Sphere(Sharding-JDBC)。擅长以java为主分布式架构以及以Kubernetes和Mesos为主的云平台方向，推崇优雅代码，对如何写出具有展现力的代码有较多研究。2018年初加入京东金融，现担任数据研发负责人。目前主要精力投入在将Sharding-Sphere打造为业界一流的金融级数据解决方案之上。 |
| 简介 将从各个数据节点获取的多数据结果集，组合成为一个结果集并正确的返回至请求客户端，称为结果归并。 |
| Sharding-Sphere支持的结果归并从功能上分为遍历、排序、分组和分页4种类型，它们是组合而非互斥的关系。从结构划分，可分为流式归并、内存归并和装饰者归并。流式归并和内存归并是互斥的，装饰者归并可以在流式归并和内存归并之上做进一步的处理。 |
| 由于从数据库中返回的结果集是逐条返回的，并不需要将所有的数据一次性加载至内存中，因此，在进行结果归并时，沿用数据库返回结果集的方式进行归并，能够极大减少内存的消耗，是归并方式的优先选择。 |
| 流式归并是指每一次从结果集中获取到的数据，都能够通过逐条获取的方式返回正确的单条数据，它与数据库原生的返回结果集的方式最为契合。遍历、排序以及流式分组都属于流式归并的一种。 |
| 内存归并则是需要将结果集的所有数据都遍历并存储在内存中，再通过统一的分组、排序以及聚合等计算之后，再将其封装成为逐条访问的数据结果集返回。 |
| 装饰者归并是对所有的结果集归并进行统一的功能增强，目前装饰者归并只有分页归并这一种类型。 |
| 分类 遍历归并 它是最为简单的归并方式。只需将多个数据结果集合并为一个单向链表即可。在遍历完成链表中当前数据结果集之后，将链表元素后移一位，继续遍历下一个数据结果集即可。 |
| 排序归并 由于在SQL中存在ORDER BY语句，因此每个数据结果集自身是有序的，因此只需要将数据结果集当前游标指向的数据值进行排序即可。这相当于对多个有序的数组进行排序，归并排序是最适合此场景的排序算法。 |
| Sharding-Sphere在对排序的查询进行归并时，将每个结果集的当前数据值进行比较（通过实现Java的Comparable接口完成），并将其放入优先级队列。每次获取下一条数据时，只需将队列顶端结果集的游标下移，并根据新游标重新进入优先级排序队列找到自己的位置即可。通过一个例子来说明Sharding-Sphere的排序归并，下图是一个通过分数进行排序的示例图。 |
| 示例中展示了3张表返回的数据结果集，每个数据结果集已经根据分数排序完毕，但是3个数据结果集之间是无序的。将3个数据结果集的当前游标指向的数据值进行排序，并放入优先级队列，t_score_0的第一个数据值最大，t_score_2的第一个数据值次之，t_score_1的第一个数据值最小，因此优先级队列根据t_score_0，t_score_2和t_score_1的方式排序队列。 |
| 下图则展现了进行next调用的时候，排序归并是如何进行的。 |
| 通过图中我们可以看到，当进行第一次next调用时，排在队列首位的t_score_0将会被弹出队列，并且将当前游标指向的数据值（也就是100）返回至查询客户端，并且将游标下移一位之后，重新放入优先级队列。而优先级队列也会根据t_score_0的当前数据结果集指向游标的数据值（这里是90）进行排序，根据当前数值，t_score_0排列在队列的最后一位。之前队列中排名第二的t_score_2的数据结果集则自动排在了队列首位。 |
| 在进行第二次next时，只需要将目前排列在队列首位的t_score_2弹出队列，并且将其数据结果集游标指向的值返回至客户端，并下移游标，继续加入队列排队，以此类推。 |
| 当一个结果集中已经没有数据了，则无需再次加入队列。 |
| 可以看到，对于每个数据结果集中的数据有序，而多数据结果集整体无序的情况下，Sharding-Sphere无需将所有的数据都加在至内存即可排序，它使用的是流式归并的方式，每次next仅获取唯一正确的一条数据，极大的节省了内存的消耗。 |
| 从另一个角度来说，Sharding-Sphere的排序归并，是在维护数据结果集的纵轴和横轴这两个维度的有序性。纵轴是指每个数据结果集本身，它是天然有序的，它通过包含ORDER BY的SQL所获取。横轴是指每个数据结果集当前游标所指向的值，它需要通过优先级队列来维护其正确顺序。每一次数据结果集当前游标的下移，都需要将该数据结果集重新放入优先级队列排序，而只有排列在队列首位的数据结果集才可能发生游标下移的操作。 |
| 分组归并 分组归并的情况最为复杂，它分为流式分组归并和内存分组归并。流式分组归并要求SQL的排序项与分组项的字段以及排序类型（ASC或DESC）必须保持一致，否则只能通过内存归并才能保证其数据的正确性。 |
| 举例说明，假设根据科目分片，表结构中包含考生的姓名（为了简单起见，不考虑重名的情况）和分数。通过SQL获取每位考生的总分，可通过如下SQL： |
| 在分组项与排序项完全一致的情况下，取得的数据是连续的，分组所需的数据全数存在于各个数据结果集的当前游标所指向的数据值，因此可以采用流式归并。如下图所示。 |
| 进行归并时，逻辑与排序归并类似。下图展现了进行next调用的时候，流式分组归并是如何进行的。 |
| 通过图中我们可以看到，当进行第一次next调用时，排在队列首位的t_score_java将会被弹出队列，并且将分组值同为“Jetty”的其他结果集中的数据一同弹出队列。在获取了所有的姓名为“Jetty”的同学的分数之后，进行累加操作，那么，在第一次next调用结束后，取出的结果集是“Jetty”的分数总和。于此同时，所有的数据结果集中的游标都将下移至数据值“Jetty”的下一个不同的数据值，并且根据数据结果集当前游标指向的值进行重排序。因此，包含名字顺着第二位的“John”的相关数据结果集则排在的队列的前列。 |
| 流式分组归并与排序归并的区别仅仅在于两点： |
| 1.它会一次性的将多个数据结果集中的分组项相同的数据全数取出。 |
| 2.它需要根据聚合函数的类型进行聚合计算。 |
| 对于分组项与排序项不一致的情况，由于需要获取分组的相关的数据值并非连续的，因此无法使用流式归并，需要将所有的结果集数据加载至内存中进行分组和聚合。例如，若通过以下SQL获取每位考生的总分并按照分数从高至低排序： |
| 那么各个数据结果集中取出的数据与分数进行排序示例图的上半部分的表结构的原始数据一致，是无法进行流式归并的。 |
| 当SQL中只包含分组语句时，根据不同数据库的实现，其排序的顺序不一定与分组顺序一致。但由于排序语句的缺失，则表示此SQL并不在意排序顺序。因此，Sharding-Sphere通过SQL优化的改写，自动增加与分组项一致的排序项，使其能够从消耗内存的内存分组归并方式转化为流式分组归并方案。 |
| 无论是流式分组归并还是内存分组归并，对聚合函数的处理都是一致的。聚合函数可以归类为比较、累加和求平均值这3种类型。 |
| 比较类型的聚合函数是指MAX和MIN。它们需要对每一个同组的结果集数据进行比较，并且直接返回其最大或最小值即可。 |
| 累加类型的聚合函数是指SUM和COUNT。它们需要将每一个同组的结果集数据进行累加。 |
| 求平均值的聚合函数只有AVG。它必须通过SQL改写的SUM和COUNT进行计算，相关内容已在SQL改写的内容中涵盖，不再赘述。 |
| 分页归并 上文所述的所有归并类型都可能进行分页。分页是追加在其他归并类型之上的装饰器，Sharding-Sphere通过装饰者模式来增加对数据结果集进行分页的能力。分页归并负责将无需获取的数据过滤掉。 |
| Sharding-Sphere的分页功能比较容易让使用者误解，用户通常认为分页归并会占用大量内存。在分布式的场景中，将LIMIT 10000000, 10改写为LIMIT 0, 10000010，才能保证其数据的正确性。用户非常容易产生Sharding-Sphere会将大量无意义的数据加载至内存中，造成内存溢出风险的错觉。其实，通过流式归并的原理可知，会将数据全部加载到内存中的只有内存分组归并这一种情况，而通常来说，进行OLAP的分组SQL，不会产生大量的结果数据，它更多的用于大量的计算，以及少量结果产出的场景。除了内存分组归并这种情况之外，其他情况都通过流式归并获取数据结果集，因此Sharding-Sphere会通过结果集的next方法将无需取出的数据全部跳过，并不会将其存入内存。 |
| 但同时需要注意的是，由于排序的需要，大量的数据仍然需要传输到Sharding-Sphere的内存空间。因此，采用LIMIT这种方式分页，并非最佳实践。 由于LIMIT并不能通过索引查询数据，因此如果可以保证ID的连续性，通过ID进行分页是比较好的解决方案，例如： |
| 或通过记录上次查询结果的最后一条记录的ID进行下一页的查询，例如： |
| 小结 归并引擎的整体结构划分如下图所示。</description> |
| </item> |
| |
| <item> |
| <title>从 New SQL 角度看 Apache ShardingSphere</title> |
| <link>https://shardingsphere.apache.org/blog/cn/videos/new_sql/</link> |
| <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> |
| |
| <guid>https://shardingsphere.apache.org/blog/cn/videos/new_sql/</guid> |
| <description>近些年 New SQL 概念盛行，国内外各大公司对 New SQL 都有着不同的解读。博观而约取之后，本次分享将为大家带来有关 New SQL 理念、国内外产品架构的解读。并以 New SQL 的角度详细分析 Apache ShardingSphere 这一业界盛行的 Apache 开源分布式数据库中间件服务平台的架构、特性、规划及开源社区。 |
| </description> |
| </item> |
| |
| <item> |
| <title>自动化执行引擎</title> |
| <link>https://shardingsphere.apache.org/blog/cn/material/engine/</link> |
| <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> |
| |
| <guid>https://shardingsphere.apache.org/blog/cn/material/engine/</guid> |
| <description>今天「剖析Sharding-Sphere系列文章」为大家带来对Sharding-Sphere自动化执行引擎模块的相关介绍。鉴于老板比较喜欢正经的技术文章，所以妹子我尽量用正经又不失肃穆的叙述风格，为大家带来《Sharding-Sphere自动化执行引擎模块》的分享。 |
| 传说鱼的记忆只有7秒钟。前段时间刚把这个模块的代码抒写整理完，趁着我还没有失忆之前，先为大家叙述一二，愿对各位看官有所帮助。 |
| 「剖析Sharding-Sphere系列文章」是由Sharding-Sphere的核心开发成员亲自操刀向大家介绍和剖析Sharding-Sphere的核心模块、所使用的前沿技术、有价值的经验总结等。这一系列的文章将带您走进Sharding-Sphere的内核世界，获得新知、激发灵感。更希望您关注我们，共同交流切磋，一同前行。 |
| 作者介绍 潘娟，京东金融运维DBA，主要负责京东金融生产数据库运维及数据库平台、中间件开发工作。多次参与京东金融6.18、11.11大促活动的护航工作。曾负责京东金融数据库自动化平台设计与开发项目，现专注于Sharding-Sphere分布式数据库中间件开发。乐于在数据库、自动化、分布式、中间件等相关领域进行学习和探索。 |
| 概念介绍 Q: 什么叫&quot;自动化执行引擎&quot;？ |
| A: 一条SQL的生命周期是：从客户端发起、经过Sharding-Sphere处理、再到底层数据库执行消化。而在Sharding-Sphere里过程则是：SQL解析&ndash;&gt;SQL优化&ndash;&gt;SQL路由&ndash;&gt;SQL改写&ndash;&gt;SQL执行&ndash;&gt;结果归并。自动化执行引擎是为了处理SQL执行问题的，即将路由改写后的真实SQL如何有控制且高效地传送到底层数据库执行。那么直接通过JDBC发送SQL至数据库执行难道行不通吗？还有其他需要考虑吗？答案是：肯定有其他考虑，否则我就不用写这篇文章了。这就体现在它的&quot;自动化&quot;上了。所谓&quot;自动化&quot;，其实是为了平衡数据库连接创建与结果归并模式选择问题，为了平衡资源控制与执行效率问题。 |
| 需求场景 Q: 为何需要自动化执行引擎呢？ |
| A: 在概念介绍部分，我们介绍了主角-自动化执行引擎。也谈到它的自动化是为了平衡数据库连接创建以及结果归并模式选择问题。这是它诞生的宿命，历史的选择。下面将为大家介绍这两个需要平衡的问题： |
| 1.数据库连接创建 |
| 作为一位混娱乐圈的DBA出身的Java coder, 多少还是会从DBA角度考虑问题。比如从资源控制的角度看，业务方访问数据库的连接数量应当有所限制，这能够有效地防止某一业务操作过多地占用资源，从而将数据库连接的资源耗尽，以致于影响其他业务的正常访问。特别是在一个数据库实例中存在较多分表的情况下，一条不包含分片键的逻辑SQL将产生落在同库不同表的大量真实SQL，如果每条真实SQL都占用一个独立的连接，那么一次查询肯定将会占用过多的资源。Sharding-Sphere作为数据库中间层，如果没有控制好数据库连接数量而导致连接暴增、数据库压力过大的话，极有可能被强行背锅。 |
| 2.结果归并模式选择 |
| 但是从执行效率的角度看，为每个分片查询维持一个独立的数据库连接，可以更加有效地利用多线程来提升执行效率。为每个数据库连接开启独立的线程，可以并行化IO所产生的消耗。独立的数据库连接，能够保持查询结果集的引用以及游标位置，在需要获取相应数据时移动游标即可，避免了过早将查询结果数据加载至内存。这就涉及到了结果归并模式的选择问题。通过上一篇文章《剖析Sharding-Sphere系列——结果归并》介绍，我们知道当前有两种结果归并的模式，分别是： |
| 流式归并：以结果集游标下移进行结果归并的方式，称之为流式归并，它无需将结果数据全数加载至内存，可以有效地节省内存资源，进而减少垃圾回收的频次。 |
| 内存归并：以读取内存中加载的结果集进行归并的方式，进行数据对比归并。它需要将结果数据全数加载至内存。 |
| 相信只要是智商在线的朋友，一定会选择流式归并来处理结果集。可是，如果无法保证每个分片查询持有一个独立数据库连接的话，那么就需要在复用该数据库连接、获取下一张分表的查询结果集之前，将当前的查询结果集全数加载至内存。因此，即使可以采用流式归并，在此场景下也不得不退化为内存归并。 |
| 一方面是对数据库连接资源的控制保护，一方面是采用更优的归并模式达到内存资源节省的目的，如何处理好两者之间的关系，是Sharding-Sphere执行引擎需求解决的问题。具体来说，如果一条SQL在经过Sharding-Sphere的分片后，需要操作某数据库实例下的200张表，那么，是选择创建200个连接并行执行，还是选择创建一个连接串行执行呢？效率与资源控制又应该如何抉择呢？ |
| 进化论 针对上述的场景，Sharding-Sphere在3.0.0.M4之前提供了一种解决思路，即提出了连接模式（Connection Mode）的概念，并划分了两种模式：内存限制模式（MEMORY_STRICTLY）和连接限制模式（CONNECTION_STRICTLY）这两种类型。 |
| 内存限制模式。使用此模式的前提是数据库对其一次操作所耗费的连接数量不做限制。如果实际执行的SQL需要对某数据库实例中的200张表做操作，则对每张表创建一个新的数据库连接，并通过多线程的方式并发处理，以达成执行效率最大化。并且在SQL满足条件情况下，优先选择流式归并，以防止出现内存溢出或避免频繁垃圾回收情况。 |
| 连接限制模式。使用此模式的前提是数据库严格控制对其一次操作所耗费的连接数量。如果实际执行的SQL需要对某数据库实例中的200张表做操作，那么只会创建唯一的数据库连接，并对其200张表串行处理。如果分片在不同的数据库，仍然是多线程处理不同库，但每个库的每次操作仍然只创建一个唯一的数据库连接。这样即可以防止对一次请求对数据库连接占用过多所带来的问题。该模式始终选择内存归并。 |
| 内存限制模式适用于OLAP操作，可以通过放宽对数据库连接的限制提升系统吞吐量；连接限制模式适用于OLTP操作，OLTP通常带有分片键，会路由到单一的分片，因此严格控制数据库连接，以保证在线系统数据库资源能够被更多的应用所使用，是明智的选择。 |
| 而Sharding-Sphere最终使用何种模式的决定权就交由用户。Sharding-Sphere提供对连接模式的配置，让开发者依据自己业务的实际场景需求选择使用内存限制模式或连接限制模式。 |
| 可是，将两难的选择的决定权甩锅给用户，使得用户必须要了解这两种模式的利弊，并依据业务场景需求进行选择。这显然增加了用户对Sharding-Sphere的学习和使用的成本，这并不是一种最优的解决方案。 |
| 此外，这种一分为二的处理方案，将两种模式的切换交由静态的初始化配置，缺乏灵活应性。在实际的使用场景中，面对不同SQL以及占位符参数，每次的路由结果是不同的。这就意味着某些操作可能需要使用内存归并，而某些操作则可能选择流式归并更优，它们不应该由用户在Sharding-Sphere启动之前配置好，而更应该根据SQL和占位符参数的场景，来动态的决定连接模式。 |
| 像Sharding-Sphere这样，总是站在用户角度考虑问题并且不断优化精进的七道杠青年是一定要进行相关优化调整的，于是自动化执行引擎就进化出来了。 |
| 为了降低用户的使用成本以及连接模式动态化这两个问题，Sharding-Sphere提炼出自动化执行引擎的思路，在其内部消化了连接模式的概念。用户无需了解所谓的内存限制模式和连接限制模式是什么，而是交由执行引擎根据当前场景自动选择最优的执行方案。 |
| 同时，自动化执行引擎将连接模式的选择粒度细化至每一次SQL的操作。针对每次SQL请求，自动化执行引擎都将根据其路由结果，进行实时的演算和权衡，并自主地采用恰当的连接模式执行，以达到资源控制和效率的最优平衡。针对自动化的执行引擎，用户只需配置maxConnectionSizePerQuery即可，该参数表示一次查询时每个数据库所允许使用的最大连接数，剩余的处理逻辑将由自动化执行引擎为您负责。 |
| 实现解析 整个自动化执行引擎的执行流程如下图所示。 |
| 在路由改写完成后，我们会得到路由结果，这个结果集主要包含了SQL、SQL的参数集、数据库等信息。其数据结构如下图所示： |
| 执行引擎的执行过程分为准备、执行两个阶段。 |
| 准备阶段 顾名思义，此阶段用于准备执行的数据。它分为结果集分组和执行单元创建两个步骤。 |
| a. 结果集分组 |
| 该步骤是实现内化连接模式概念的关键。执行引擎根据maxConnectionSizePerQuery配置项，结合当前路由结果，自动选择恰当的连接模式。具体步骤如下： |
| 将SQL的路由结果按照数据库的名称进行分组。 |
| 通过下图的公式获得每个数据库实例在maxConnectionSizePerQuery的允许范围内，每个数据库连接需要执行的SQL路由结果组，并演算出本次请求最优的连接模式。 |
| 在maxConnectionSizePerQuery允许的范围内，当一个连接需要执行的请求数量大于1时，意味着当前的数据库连接无法持有相应的数据结果集，则必须采用内存归并；反之，当一个连接需要执行的请求数量等于1时，意味着当前的数据库连接可以持有相应的数据结果集，则可以采用流式归并。 |
| 每一次的连接模式的选择，是针对每一个物理数据库的。也就是说，在同一次查询中，如果路由至一个以上的数据库，每个数据库的连接模式不一定一样，它们可能是混合存在的形态。 |
| b. 执行单元创建 |
| 该步骤通过上一步骤获得的路由分组结果创建用于执行的单元。执行单元是指为每个路由分组结果创建相应的数据库连接。 |
| 当数据库被限制了连接资源数量且线上业务出现大量并发操作时，如果不妥善处理并发获取数据库连接的问题，则很有可能会发送死锁。在多个请求相互等待对方释放数据库连接资源时，就会产生饥饿等待，造成交叉死锁。 |
| 举个栗子，假设一次查询需要在某一数据库上获取2个数据库连接，用于路由至一库的2个分表查询。有可能出现查询A已获取到该数据库的1个数据库连接，并等待获取另一个数据库连接；而查询B则也已经获得了该数据库上的1个数据库连接，并同样等待另一个数据库连接的获取。如果数据库连接池的允许最大连接数是2，那么这2个查询请求将永远孤独地等待着彼此，图绘版的解释可能会更便于大家理解： |
| 为了避免死锁的出现，Sharding-Sphere在获取数据库连接时进行了同步处理。它在创建执行单元时，以原子性的方式一次性获取本次SQL请求所需的全部数据库连接，杜绝了每次查询请求获取到部分资源的可能。这种加锁做法确实可以解决死锁问题，只是，同时会带来一定程度并发性能的损失。为了展示我们不一样！有啥不一样呢？</description> |
| </item> |
| |
| <item> |
| <title>开源推动下的 Apache ShardingSphere 架构演进</title> |
| <link>https://shardingsphere.apache.org/blog/cn/videos/evolution/</link> |
| <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> |
| |
| <guid>https://shardingsphere.apache.org/blog/cn/videos/evolution/</guid> |
| <description>本次分享将从 New SQL 切入，重点介绍 ShardingSphere 架构演进和规划，并落到开源与贡献者的关系与发展。从产品生态，开源力量，个人成长发展等角度为大家带来解读和分享。 |
| </description> |
| </item> |
| |
| <item> |
| <title>成为 Apache 官方认可的 Committer 有什么优势</title> |
| <link>https://shardingsphere.apache.org/blog/cn/material/committer/</link> |
| <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> |
| |
| <guid>https://shardingsphere.apache.org/blog/cn/material/committer/</guid> |
| <description>什么是Apache软件基金会？ Apache 软件基金会（Apache Software Foundation），是当今最具影响力的非盈利性开源软件项目组织，正式成立于 1999 年，主要由开发者与用户的团体组成。在 Apache 软件基金会主导下，已有 350 多个顶级开源项目毕业，包括全球最著名的网络服务器软件 Apache HTTP Server。秉持着“开放、创新、社区”的精神，很多 Apache 项目已经建立起强大成功的生态圈，社区充满活力。 |
| 除了许多在信息技术领域十分具有影响力的项目外，Apache 许可证（Apache License），Apache 贡献者协议许可（CLAs）和开放合作的模式（Apache Way）也在业内有着突出的贡献，其影响力远远扩大到 Apache 软件基金会以外。 |
| Apache 软件基金会如今已成为现代开源软件生态系统的基石。 |
| 为什么要成为Apache committer？ 说了这么多，不管大家之前对 Apache 软件基金会了解到了什么程度，都可以看出，这是一个极具影响力的组织，在业内广受认可。 |
| 如果能够成为一名官方承认的 committer，不仅是对自己的极大认可，表明自身有能力参与到 Apache 级的项目开发中，并作出切实的贡献；而且还能够受到业内广泛尊重，无论是对求职还是升职加薪都很有帮助。 |
| 简单来说，不管是和其他小伙伴们炫耀，还是写到简历上都倍儿有面子 |
| 并且，官方认可的 committer 还会获取带 @apache 后缀的邮箱，还能名列 Apache 网站上 |
| （http://people.apache.org/committer-index.html） |
| 在世界上千百万的工程师中，只有极少数的人才能成为 committer 拥有这些特权，是不是很诱人呢？ |
| 想象一下，小伙伴们浏览 Apache 网站时看到了你的名字，或者和面试官发邮件时，他们会不会有种不明觉厉的感觉，形象瞬间就高大上了有木有！ |
| 如何成为官方认可的 committer？ 下面就是本篇文章的重点啦，需要做些什么，才会成为一名官方认可的 committer 呢？ |
| 活跃地参与到 Apache 项目中，比如 Apache ShardingSphere 即可。 |
| 不如从领个任务练练手开始？目前公布出的任务如下，欢迎领取： |
| 实现使用 Inline 表达式对 Sharding-SpringBoot 进行规则配置 |
| https://github.com/sharding-sphere/sharding-sphere/issues/1686 |
| 实现使用 SpringBoot 占位符方式对 Sharding-SpringBoot 进行规则配置</description> |
| </item> |
| |
| <item> |
| <title>刚柔并济的开源分布式事务解决方案</title> |
| <link>https://shardingsphere.apache.org/blog/cn/material/solution/</link> |
| <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> |
| |
| <guid>https://shardingsphere.apache.org/blog/cn/material/solution/</guid> |
| <description>作者 张亮，京东数科数据研发负责人，Apache ShardingSphere发起人 &amp; PPMC |
| 热爱开源，目前主导开源项目ShardingSphere(原名Sharding-JDBC)和Elastic-Job。擅长以java为主分布式架构以及以Kubernetes和Mesos为主的云平台方向，推崇优雅代码，对如何写出具有展现力的代码有较多研究。 |
| 目前主要精力投入在将ShardingSphere打造为业界一流的金融级数据解决方案之上。ShardingSphere已经进入Apache孵化器，是京东集团首个进入Apache基金会的开源项目，也是Apache基金会首个分布式数据库中间件。 |
| 姜宁，华为开源能力中心技术专家，Apache ServiceComb项目负责人。前红帽软件首席软件工程师，在企业级开源中间件开发方面有十余年经验，有丰富的Java开发和使用经验，函数式编程爱好者。从2006年开始一直从事Apache开源中间件项目的开发工作，先后参与Apache CXF，Apache Camel，以及Apache ServiceMix的开发。对微服务架构，WebServices，Enterprise Integration Pattern，SOA， OSGi 均有比较深入的研究。 |
| 博客地址：https://willemjiang.github.io/ |
| 冯征，红帽软件工程师。2009年加入红帽软件公司，主要从事事务管理器方面的工作，做为核心开发人员参与了 Narayana 和 BlackTie 项目，在与多个应用服务器（Wildfly, Karaf, Tomcat）和框架（Common DBCP, Spring Boot）的事务处理集成方面有过贡献。从2017年开始参与了Apache ServiceComb项目，目前是PMC成员之一。对于分布式事务处理以及微服务环境中的事务处理，有过深入的研究。 |
| 导读 相比于数据分片方案的逐渐成熟，集性能、透明化、自动化、强一致、并能适用于各种应用场景于一体的分布式事务解决方案则显得凤毛麟角。基于两（三）阶段提交的分布式事务的性能瓶颈以及柔性事务的业务改造问题，使得分布式事务至今依然是令架构师们头疼的问题。 |
| Apache ShardingSphere（Incubating）不失时机的在2019年初，提供了一个刚柔并济的一体化分布式事务解决方案。如果您的应用系统正在受到这方面的困扰，不妨倒上一杯咖啡，花十分钟阅读此文，说不定会有些收获呢？ |
| 背景 数据库事务需要满足ACID（原子性、一致性、隔离性、持久性）4个特性。 |
| 原子性（Atomicity）指事务作为整体来执行，要么全部执行，要么全不执行。 |
| 一致性（Consistency）指事务应确保数据从一个一致的状态转变为另一个一致的状态。 |
| 隔离性（Isolation）指多个事务并发执行时，一个事务的执行不应影响其他事务的执行。 |
| 持久性（Durability）指已提交的事务修改数据会被持久保存。 |
| 在单一数据节点中，事务仅限于对单一数据库资源的访问控制，称之为本地事务。几乎所有的成熟的关系型数据库都提供了对本地事务的原生支持。 但是在基于微服务的分布式应用环境下，越来越多的应用场景要求对多个服务的访问及其相对应的多个数据库资源能纳入到同一个事务当中，分布式事务应运而生。 |
| 关系型数据库虽然对本地事务提供了完美的ACID原生支持。 但在分布式的场景下，它却成为系统性能的桎梏。如何让数据库在分布式场景下满足ACID的特性或找寻相应的替代方案，是分布式事务的重点工作。 |
| 本地事务 在不开启任何分布式事务管理器的前提下，让每个数据节点各自管理自己的事务。 它们之间没有协调以及通信的能力，也并不互相知晓其他数据节点事务的成功与否。 本地事务在性能方面无任何损耗，但在强一致性以及最终一致性方面则力不从心。 |
| 两阶段提交 XA协议最早的分布式事务模型是由X/Open国际联盟提出的X/Open Distributed Transaction Processing（DTP）模型，简称XA协议。 |
| 基于XA协议实现的分布式事务对业务侵入很小。 它最大的优势就是对使用方透明，用户可以像使用本地事务一样使用基于XA协议的分布式事务。 XA协议能够严格保障事务ACID特性。 |
| 严格保障事务ACID特性是一把双刃剑。 事务执行在过程中需要将所需资源全部锁定，它更加适用于执行时间确定的短事务。 对于长事务来说，整个事务进行期间对数据的独占，将导致对热点数据依赖的业务系统并发性能衰退明显。 因此，在高并发的性能至上场景中，基于XA协议两阶段提交类型的分布式事务并不是最佳选择。</description> |
| </item> |
| |
| <item> |
| <title>海量数据下的 NewSQL 数据库生态构建</title> |
| <link>https://shardingsphere.apache.org/blog/cn/videos/ecosystem/</link> |
| <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> |
| |
| <guid>https://shardingsphere.apache.org/blog/cn/videos/ecosystem/</guid> |
| <description>伴随着互联网的急速发展，互联网数据的规模也在爆炸式增长。在这种场景下，传统的数据库如何进行变革升级，来满足新的互联网的数据需求？如何借助 NewSQL 理念，打造分布式数据库集群的生态，来满足业务方对查询性能、大数据量存储、数据安全、弹性扩展等方面的需求？本次分享将针对这些问题，进行细致剖析，并提供较为完整的 NewSQL 解决方案。 |
| </description> |
| </item> |
| |
| <item> |
| <title>Apache ShardingSphere 5.x 的新功能</title> |
| <link>https://shardingsphere.apache.org/blog/cn/videos/newfeature/</link> |
| <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> |
| |
| <guid>https://shardingsphere.apache.org/blog/cn/videos/newfeature/</guid> |
| <description>Apache ShardingSphere 5.x 的首个版本发布在即。Apache ShardingSphere 从架构设计理念到产品定位都有重大革新。采用了可插拔的方式，使其具备高度灵活、可插拔和可扩展的能力;在产品定位方面，不再以数据分片为内核，而是转向分布式数据库生态的打造。5.x 版本将数据分片、分布式事务、数据库治理等核心功能从项目内核中完全抽离，成为其可插拔生态的一部分。并且通过 SPI 的方式完全开放其生态，将数据迁移、弹性调度、数据加密、影子表等功能完全融入至产品生态中。 |
| </description> |
| </item> |
| |
| <item> |
| <title>Apache ShardingSphere整合Seata AT分布式事务</title> |
| <link>https://shardingsphere.apache.org/blog/cn/material/seata/</link> |
| <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> |
| |
| <guid>https://shardingsphere.apache.org/blog/cn/material/seata/</guid> |
| <description>背景知识 Seata是阿里集团和蚂蚁金服联合打造的分布式事务框架，目前版本包含了AT事务和TCC事务。其中AT事务的目标是在微服务架构下，提供增量的事务ACID语意，让用户像使用本地事务一样，使用分布式事务，核心理念同ShardingSphere一脉相承。 |
| Github: https://github.com/seata/seata |
| Seata AT模型 Seata AT事务模型包含TM(事务管理器)，RM(资源管理器)，TC(事务协调器)。 |
| 其中TC是一个独立的服务需要单独部署，TM和RM以jar包的方式同业务应用部署在一起，它们同TC建立长连接，在整个事务生命周期内，保持RPC通信。 |
| 其中全局事务的发起方作为TM，全局事务的参与者作为RM ; TM负责全局事务的begin和commit/rollback，RM负责分支事务的执行和commit/rollback。 |
| ShardingSphere分布式事务SPI ShardingSphere提供了一套接入分布式事务的SPI，设计的目标是保证数据分片后，事务的ACID语意。分布式事务的实现目前主要包含两阶段的XA和BASE柔性事务。Seata AT事务作为BASE柔性事务的一种实现，可以无缝接入到ShardingSphere生态中。 |
| 两阶段XA事务方面，我们已经整合了Atomikos，Narayana，Bitronix事务管理器，XA事务底层依赖具体的数据库厂商对XA两阶段提交协议的支持，通常XA协议通过在Prepare和Commit阶段进行2PL(2阶段锁)，保证了分布式事务的ACID，通常适用于短事务及非云化环境（云化环境下一次IO操作大概需要20ms，两阶段锁会锁住资源长达40ms，因此事务的TPS会降到25/s左右，非云化环境通常一次IO只需几毫秒，因此锁热点数据的时间相对较低）[1]。 |
| BASE柔性事务方面，目前我们已经完成了对ServiceComb Saga的整合，Saga通过一阶段提交+补偿的方式提高了整体事务的性能，其中补偿的方式同Seata大致相同，即对分片后的物理SQL进行revert来生成补偿的SQL，但Saga模型在理论上不支持隔离级别，适用于对性能要求较高，对一致性要求比较低的业务。Seata AT事务在一阶段提交+补偿的基础上，通过TC的全局锁实现了RC隔离级别的支持，是介于XA和Saga之间的另一种实现。消息柔性事务方面，也欢迎大家参考我们的SPI提供整合的方案。 |
| 整合方案 整合Seata AT事务时，需要把TM，RM，TC的模型融入到ShardingSphere 分布式事务的SPI的生态中。在数据库资源上，Seata通过对接DataSource接口，让JDBC操作可以同TC进行RPC通信。同样，ShardingSphere也是面向DataSource接口对用户配置的物理DataSource进行了聚合，因此把物理DataSource二次包装为Seata的DataSource后，就可以把Seata AT事务融入到ShardingSphere的分片中。 |
| 在Seata模型中，全局事务的上下文存放在线程变量中，通过扩展服务间的transport，可以完成线程变量的传递，分支事务通过线程变量判断是否加入到整个Seata全局事务中。而ShardingSphere的分片执行引擎通常是按多线程执行，因此整合Seata AT事务时，需要扩展主线程和子线程的事务上下文传递，这同服务间的上下文传递思路完全相同。 |
| Quick Start 我们已经实现了base-seata-raw-jdbc-example，大家可以自行进行尝试。 |
| https://github.com/apache/incubator-shardingsphere-example/tree/dev/sharding-jdbc-example/transaction-example/transaction-base-seata-example/transaction-base-seata-raw-jdbc-example |
| 操作手册： |
| 1.按照seata-work-shop中的步骤，下载并启动seata server。 |
| https://github.com/seata/seata-workshop |
| 参考 Step6 和 Step7即可 |
| 2.在每一个分片数据库实例中执行resources/sql/undo_log.sql脚本，创建undo_log表 |
| 3.Run YamlConfigurationTransactionExample.java |
| 待优化项 Seata AT事务在Revert SQL时，需要对ShardingSphere分片后的物理SQL进行二次的解析，这里我们需要设计一个SPI，避免SQL二次解析的性能损耗。 |
| 参考论文 |
| [1]: Transactions for Distributed Actors in the Cloud |
| https://www.microsoft.com/en-us/research/wp-content/uploads/2016/10/EldeebBernstein-TransactionalActors-MSR-TR-1.pdf</description> |
| </item> |
| |
| <item> |
| <title>快讯！Apache ShardingSphere 进入 CNCF 全景图</title> |
| <link>https://shardingsphere.apache.org/blog/cn/material/cncf/</link> |
| <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> |
| |
| <guid>https://shardingsphere.apache.org/blog/cn/material/cncf/</guid> |
| <description>CNCF (Cloud Native Computing Foundation)，是由 Google 牵头创立的云原生计算开源软件基金会。它致力于云原生（Cloud Native）技术的普及和可持续发展。云原生技术是通过一系列的软件、规范和标准帮助企业和组织，在现代的动态环境（如公共云、私有云和混合云）中构建和运行敏捷的、可扩展的应用程序。容器、微服务、微服务治理、声明式 API 等都是代表性的云原生技术。 |
| CNCF Landscape (https://github.com/cncf/landscape) 是 CNCF 中的一个重要项目，它旨在为云原生应用者提供一个资源地图，帮助企业和开发人员快速了解云原生体系的全貌。 |
| CNCF 将云原生的生态圈横向划分为五层，并且针对它们又纵向规划出两部分，作为横向五层的共用层。横向划分的五层分别是：应用定义与开发、编排与治理、运行时、供应保障和云设施。纵向划分的两部分是：观察与分析和平台。将这些功能整合起来即是一个完善的云平台服务产品，全景图如下： |
| &ndash; 以上内容摘自书籍《未来架构:从服务化到云原生》 |
| ShardingSphere 北京时间 2019年6月28日，Apache ShardingSphere 进入 CNCF Landscape。在全景图 App Definition Development-Database 领域占有一席之地，如下图所示。 |
| Apache ShardingSphere 在开源领域及云原生领域会持续拓展，不断精进，构建有机开源生态圈！ |
| 我们也希望有更多开源及云原生社区的爱好者能加入我们，共同前进，促进 Apache ShardingSphere 社区及贡献者们共同成长！ |
| Apache ShardingSphere 自 2016 开源以来，不断精进、不断发展，被越来越多的企业和个人认可：Github 上收获8000+的 stars，近百家公司企业的成功案例。此外，越来越多的企业和个人也加入到Apache ShardingSphere（Incubating）的开源项目中，为它的成长和发展贡献了巨大力量。</description> |
| </item> |
| |
| <item> |
| <title>Apache ShardingSphere 社区的探索与拓展</title> |
| <link>https://shardingsphere.apache.org/blog/cn/material/community/</link> |
| <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> |
| |
| <guid>https://shardingsphere.apache.org/blog/cn/material/community/</guid> |
| <description>Apache ShardingSphere 社区受邀参与了11月9日在清华大学举办的《 Apache Event——走进 Apache 开源软件社区》的分享活动。在活动中 Apache ShardingSphere 社区的PPMC张亮分享了《 Apache ShardingSphere 社区的探索与拓展》这个话题，下面呈现分享的主要内容。 |
| 01 为什么要做开源 做开源对于个人来讲，能获得两方面的收益：更好的职业生涯和享受乐趣。 |
| -1- 更好的职业生涯 |
| 1. 职位需求多。企业对于开源岗位有很强的招聘需求。开源能够给公司带来很多价值，如：通过开源项目搭建云服务平台并提供增值服务、让开源项目本身的质量得以提升、提升公司的是技术影响力等。开源的职位往往与技术和社区本身关联性高、不受地域限制，属于一个比较自由的职位。 |
| 2. 自身技能提升。包括技术能力和软技能的提升。通过参与顶级的开源项目，技术的提升自不必说，其他的软技能也会得到相应的提升，如英语、协作能力、运营推广能力等。如果是打造全新的开源项目，从零到一的开创能力也会得到极大的提升。 |
| 3. 人际关系拓展。开源参与者的职业生涯将不再仅关注薪水、KPI等与工作本身强相关的事情。纯粹的技术交流、各种会议的分享、写作邀请、甚至资本注入等各种与行业相关的连接会被逐渐扩展，参与国际的开源项目还会认识更多的国际友人。正所谓低头做技术，抬头看世界。参与开源，认识更多的人，为今后职业生涯的发展提供更多可能性。 |
| 4. 个人品牌打造。开源的工作，其过程和成果都是公开的，这就意味着参与者的所有努力都可以被任何人在任何时间看得到，是永久留存的记录。而公司内部的私有项目风险比开源项目相对来说要大很多，私有项目的评断标准取决于项目负责人的认可，如果项目责任人不认可，那么参与者的价值就趋近于零。开源项目则不同，正是因为参与者的价值能够在一个公开的平台去展现，价值的评断不取决于一个相对狭小的范围。 |
| -2- 享受乐趣 |
| 1. 成长的乐趣。真正喜欢去做一件事情的人，会在成长中体会到乐趣。软件开发行业是要需要从业者发挥自驱力的行业，遵从内心的喜欢编程，是在这个行业中取得成功的捷径。喜欢编程的人，自然能够体会自身成长所带来的乐趣。 |
| 2. 成就感。行业的认同，会在成长的同时获得成就感。无论是个人自身的成就感，还是项目提升带来的成就感，都是职业生涯中快乐的源泉。当你所做的东西，被同好者广泛认可的时候，成就感会油然而生。 |
| 02 Apache 软件基金会项目简介 Apache 软件基金会是一个非盈利组织。从1999年至今的20年时间里，产出了无数影响软件行业的项目。在几百个 Apache 软件基金会项目中，我们可以浏览一下几个非常著名的项目：Apache Tomcat、Apache Commons、Apache Maven、Apache Hadoop、Apache Kafka、Apache Spark、Apache Zookeeper等等。Apache 软件基金会的项目成为了开发者日常工作的基石。毫不夸张的说，如果以上项目，您一个都没听说过的话，那么可能很难拿到任何一家公司的Java后端或大数据类Offer。 |
| 近年来，来自中国的 Apache 项目也越来越多了，截止到目前为止，已经有19个来自中国的项目进入了 Apache 软件基金会，其中有9个项目已经毕业成为顶级项目，还有10个项目正在孵化中。对于没有在西方社会工作过的人来说，参与一个国际化的开源项目的门槛有点高，因此，来自中国的 Apache 软件基金会项目对于想参与开源的国内同学是一个巨大的福音。这些项目能够提供一个有效的缓冲带，让一些初入社区且找不到门路的同学能够以熟悉的母语快速的进入国际化的开源社区。来自中国的 Apache 软件基金会项目，与来自西方的Apache软件基金会项目在流程、规范、法务等方面并无不同，唯一的区别是能在社区中找到可以说汉语的人，拉进沟通交流的举例，并进一步的了解 Apache 社区的运作模式，为以后参与其他国际化项目打好基础。 |
| 03 Apache ShardingSphere 简介 Apache ShardingSphere 是 19 个来自中国的 Apache 软件基金会项目之一，目前正在孵化器中。Apache ShardingSphere 是一个微内核且可高度扩展的数据库中间件。它的内核微小而稳定，但却提供可无限扩展的平台，因此它非常适合与开放的社区一起成长，并近乎于无限的拓展其功能范围。</description> |
| </item> |
| |
| <item> |
| <title>我们是怎样打造一款分布式数据库的</title> |
| <link>https://shardingsphere.apache.org/blog/cn/material/database/</link> |
| <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> |
| |
| <guid>https://shardingsphere.apache.org/blog/cn/material/database/</guid> |
| <description>作者 | 张亮 |
| 关系型数据库在过去数十年的数据库领域一直占据着绝对主导的地位，它所带来的稳定性、安全性和易用性，成为了构建现代化系统的基石。随着的互联网高速发展，构架于单机系统的数据库已无法满足越来越高的并发请求和越来越大的数据存储需求，因此，分布式数据库被愈加广泛的采用。 |
| 一直以来，数据库领域均由西方的科技公司和社区所主导。而今，越来越多的国产数据库解决方案以分布式为支点，逐渐在此领域有所建树。Apache ShardingSphere 是其中的一个分布式数据库解决方案，也是目前 Apache 软件基金会中唯一的数据库中间件。 1 背景 全面兼容面向传统关系型数据库的 SQL 和事务，并且对分布式的天然友好，是分布式数据库解决方案的设计目标。它的核心功能主要集中在以下几点： |
| 分布式存储: 数据存储不受单机磁盘容量限制，可通过增加数据服务器的数量提升存储能力； |
| 计算存储分离: 计算节点无状态，可通过水平扩展增加算力。存储节点和计算节点能够分层优化； |
| 分布式事务: 高性能、完全支持本地事务 ACID 原义的分布式事务处理引擎； |
| 弹性伸缩：可以随时随地的在不影响现有应用的情况下，动态对数据存储节点扩容和缩容； |
| 强一致多副本：自动将数据以强一致、高性能的方式复制至跨机房的多个副本，以保证数据的绝对安全； |
| HTAP：采用同一套产品混合处理 OLTP 的事务型操作和 OLAP 的分析型操作。 |
| 分布式数据库的实现方案可以划分为进取型和稳定型。进取型实现方案是指开发全新架构的 NewSQL。这类产品以追求更高性能换取稳定性的缺失和运维经验的不足；稳定型的实现方案是指在现有数据库的基础上提供增量能力的中间件。这类产品则以牺牲部分性能以保证数据库的稳定性和运维经验的复用。 |
| 2 架构 Apache ShardingSphere 是一套开源的分布式数据库解决方案组成的生态圈，它由 Sharding-JDBC、Sharding-Proxy 和 Sharding-Sidecar（计划中）这 3 款相互独立的产品组成。它们均提供标准化的数据水平扩展、分布式事务和分布式治理等功能，可适用于如 Java 同构、异构语言、云原生等各种多样化的应用场景。随着 Apache ShardingSphere 在查询优化器和分布式事务引擎的不断探索，它已渐渐地打破了实现方案的产品边界，向集进取型和稳定型于一身的平台级解决方案演进。 |
| Sharding-JDBC |
| 定位为轻量级 Java 框架，在 Java 的 JDBC 层提供的额外服务。它使用客户端直连数据库，以 jar 包形式提供服务，无需额外部署和依赖，可理解为增强版的 JDBC 驱动，完全兼容 JDBC 和各种 ORM 框架。</description> |
| </item> |
| |
| <item> |
| <title>分布式数据库解决方案Apache ShardingSphere毕业成为顶级项目</title> |
| <link>https://shardingsphere.apache.org/blog/cn/material/graduate/</link> |
| <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> |
| |
| <guid>https://shardingsphere.apache.org/blog/cn/material/graduate/</guid> |
| <description>全球最大的开源软件基金会 Apache 软件基金会（以下简称 Apache）于北京时间 2020年4 月 15 日宣布 Apache ShardingSphere毕业成为 Apache 顶级项目。 |
| ShardingSphere于2018年11月10日捐赠给Apache并启动孵化。之后在导师的指导下，由孵化器管理委员会成员进行经营和孵化，在2020年3月28日在Apache孵化器以10 票支持一次性通过毕业提案投票。 |
| 4月15日，Apache董事会通过ShardingSphere毕业决议，结束了为期17个月的孵化，并由Apache 市场总监 Sally Khudairi在Apache软件基金会各渠道官号上发布官方通告。ShardingSphere是2020年度第一个从Apache孵化器毕业的顶级项目。 |
| Apache ShardingSphere 是一款分布式数据库中间件，该项目由当当捐入 Apache，并在京东数科逐渐发展壮大，成为 业界首个Apache分布式数据库中间件项目。 |
| 毕业成为顶级项目见证了过去一年半来自Apache ShardingSphere 社区的努力，自从进入Apache孵化器以来，ShardingSphere已经从一个用于分片的JDBC驱动演变成为一个分布式生态系统。 |
| 感谢我们的导师、贡献者和Apache孵化器的支持。在冠状病毒爆发的这段时间里，社区仍然以多元化的方式积极运作。我们非常高兴的看到，项目由来自世界各地的120多位贡献者参与开发。</description> |
| </item> |
| |
| <item> |
| <title>快讯！分布式调度项目ElasticJob即将重新起航</title> |
| <link>https://shardingsphere.apache.org/blog/cn/material/elasticjob/</link> |
| <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> |
| |
| <guid>https://shardingsphere.apache.org/blog/cn/material/elasticjob/</guid> |
| <description>ElasticJob是一个分布式调度解决方案，提供分布式任务的分片，弹性伸缩，全自动发现，基于时间驱动、数据驱动、常驻任务和临时任务的多任务类型，任务聚合和动态调配资源，故障检测、自动修复，失效转移和重试，完善的运维平台和管理工具，以及对云原生的良好支持等功能特性，可以全面满足企业对于任务管理和批量作业的调度处理能力。 |
| ElasticJob自2014年底开源以来，经历了5年多的发展，以其功能的丰富性，文档的全面性，代码的高质量，框架的易用性，积累了大量的忠实用户和良好的业内口碑（5.8K star），一直也是分布式调度框架领域最受大家欢迎的项目之一。 |
| 近两年来，由于核心开发者全力发展和维护Apache ShardingSphere项目等原因，ElasticJob放缓了发展的脚步。但是随着Apache ShardingSphere项目在分布式领域的不断拓展，以及用户对于多数据集群环境的分布式管理和数据迁移的弹性扩容等功能，需要一个强大的分布式调度组件。由此为契机，Apache ShardingSphere社区已经计划发起提议将ElasticJob作为其子项目进行长期持续的更新和维护。 |
| 我们第一时间将此好消息公开，后续将带来更多关于ElasticJob的相关资讯。 |
| 讨论邮件： https://lists.apache.org/thread.html/rd6171e2065be6bcfbeb7aba7e5c876eeed04db585c6ab78fc03a581c%40%3Cdev.shardingsphere.apache.org%3E |
| 捐赠Proposal： https://cwiki.apache.org/confluence/display/SHARDINGSPHERE/ElasticJob+Donation+Proposal |
| 社区讨论： https://github.com/elasticjob/elastic-job-lite/issues/728 |
| </description> |
| </item> |
| |
| <item> |
| <title>停滞数年后，ElasticJob 携首个 Apache 版本 3.0.0-alpha 回归</title> |
| <link>https://shardingsphere.apache.org/blog/cn/material/alpha/</link> |
| <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> |
| |
| <guid>https://shardingsphere.apache.org/blog/cn/material/alpha/</guid> |
| <description>在成为 Apache ShardingSphere 的子项目的几个月时间里，ElasticJob 社区在修复与合并了535个 issue 和 pull request 之后，发布了加入 Apache 软件基金会后的第一个正式版本：3.0.0-alpha。 |
| 背景 ElasticJob（ https://github.com/apache/shardingsphere-elasticjob ）是面向互联网生态和海量任务的分布式调度解决方案，由两个相互独立的子项目 ElasticJob-Lite 和 ElasticJob-Cloud 组成。它诞生于 2015年，当时业界虽然有 QuartZ 等出类拔萃的定时任务框架，但缺乏分布式方面的探索。分布式调度云平台产品的缺失，使得 ElasticJob 从出现伊始便备受关注。它有效地弥补了作业在分布式领域的短板，并且提供了一站式的自动化运维管控端，各个产品使用统一的作业 API，开发者仅需一次开发，即可随意部署。 |
| ElasticJob 在技术选型时，选择站在了巨人的肩膀上而不是重复制造轮子的理念，将定时任务事实标准的 QuartZ 与 分布式协调的利器 ZooKeeper 完美结合，快速而稳定的搭建了全新概念的分布式调度框架。 |
| ElasticJob调度模型 ElasticJob 的调度模型划分为支持线程级别调度的进程内调度 ElasticJob-Lite，和进程级别调度的ElasticJob-Cloud。 |
| 进程内调度 |
| ElasticJob-Lite 是面向进程内的线程级调度框架。它能够与 Spring 、Dubbo等 Java 框架配合使用，在作业中可自由使用 Spring 注入的 Bean，如数据源连接池、Dubbo 远程服务等，更加方便地贴合业务开发。 |
| ElasticJob-Lite与业务应用部署在一起，其生命周期与业务应用保持一致，是典型的嵌入式轻量级架构。ElasticJob-Lite 非常适合于资源使用稳定、部署架构简单的普通 Java 应用，可以理解为 Java 开发框架。 |
| ElasticJob-Lite 本身是无中心化架构，无需独立的中心化调度节点，分布式下的每个任务节点均是以自调度的方式适时的调度作业。任务之间只需要一个注册中心来对分布式场景下的任务状态进行协调即可，目前支持 ZooKeeper 作为注册中心。 |
| 架构图如下： |
| 通过图中可看出，ElasticJob-Lite 的分布式作业节点通过选举获取主节点，并通过主节点进行分片。分片完毕后，主节点与从节点并无二致，均以自我调度的方式执行任务。 |
| 进程级调度 |
| ElasticJob-Cloud 拥有进程内调度和进程级别调度两种方式。由于 ElasticJob-Cloud 能够对作业服务器的资源进行控制，因此其作业类型可划分为常驻任务和瞬时任务。常驻任务类似于ElasticJob-Lite，是进程内调度；瞬时任务则完全不同，它充分的利用了资源分配的削峰填谷能力，是进程级的调度，每次任务的会启动全新的进程处理。 |
| ElasticJob-Cloud 需要通过 Mesos 对资源进行控制，并且通过部署在 Mesos Master的调度器进行任务和资源的分配。Cloud采用中心化架构，将调度中心的高可用交由 Mesos管理。</description> |
| </item> |
| |
| <item> |
| <title>新版发布｜ShardingSphere 5.0.0-beta 来了！</title> |
| <link>https://shardingsphere.apache.org/blog/cn/material/ss_5.0.0beta/</link> |
| <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> |
| |
| <guid>https://shardingsphere.apache.org/blog/cn/material/ss_5.0.0beta/</guid> |
| <description>Original 潘娟 SphereEx 6/22 |
| Apache ShardingSphere 5.0.0-beta 版在经过长达半年的筹备后，终于将在近期正式 Release! 本文将带领大家一同预览新版本即将带来哪些重大亮点功能。 |
| 作者介绍 潘娟 | Trista |
| SphereEx 联合创始人 |
| SphereEx co-founder, Apache member, Apache ShardingSphere PMC, Apache brpc(Incubating) mentor, 本次 Release manager。 |
| 前京东科技高级 DBA，曾负责京东数科数据库智能平台的设计与研发，现专注于分布式数据库 &amp; 中间件生态及开源领域。被评为《2020 中国开源先锋人物》，多次受邀参加数据库 &amp; 架构领域的相关会议分享。 |
| 作为 Apache 的顶级项目，ShardingSphere 的 Release 要经过社区验证、投票、发布等环节，保证推出的版本符合 License 及 Apache Release 规范，且功能及项目层面尽可能符合预期，这是对项目本身及使用者的保护。当前版本已完成基本构建，预计本周内正式发行。 |
| 本次 Release 将会带来以下重要特性： 1. 亮点功能 全新定义的分布式数据库操作语言—DistSQL SQL 是一种用于存取数据以及查询、更新和管理关系数据库系统的数据库查询和程序设计语言。1986 年 10 月，美国国家标准学会将 SQL 作为关系式数据库管理系统的标准语言。现有通用数据库系统在其实践过程中都对 SQL 规范作了部分改写和扩充，具有更高灵活性和更丰富的功能，使其适用于自身的数据库系统。 |
| DistSQL（Distributed SQL）是 Apache ShardingSphere 提出的，特有的一种内置 SQL 语言，能够提供标准 SQL 之外的增量功能操作能力。DistSQL 让用户可以像操作数据库一样操作 ShardingSphere，使其从面向开发人员的框架和中间件转变为面向运维人员的基础设施产品。</description> |
| </item> |
| |
| <item> |
| <title>为什么要参与到开源社区中？</title> |
| <link>https://shardingsphere.apache.org/blog/cn/material/open_source_community/</link> |
| <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> |
| |
| <guid>https://shardingsphere.apache.org/blog/cn/material/open_source_community/</guid> |
| <description>你无法想象开源项目离你有多近。它早已融入你生活的方方面面，从办公室到家里，从健身房到餐厅等等。 |
| 俗话说：&ldquo;开源项目属于我们，而不是我&rdquo;，这就解释了为什么这些项目很受欢迎，以至于连知名的商业巨头都将开源计划纳入他们的商业计划。但是对于普通人来说，到底是否有必要又是否有可能加入开源社区呢？它的魅力何在？ |
| 在这篇文章中，我将通过介绍优点和缺点来回答这些问题。我们都知道，奖励比惩罚更好，那我们就先从奖励开始说起。 |
| 1. 掌握一项新技能 你是否厌倦了每天疏远和重复的工作？你是否想学习新的、令人兴奋的、有价值的技能？ |
| 在线课程（MOOCs）或书籍绝对是提高你的技能和扩展你的知识的好方法。然而，我想推荐另一种高效，有趣的方法，那就是加入相关的开源社区，在生产环境中解决实际问题的同时学习新技能。这些活跃的开源项目之所以如此受欢迎，是因为它们帮助用户解决实际问题并满足他们的需求。通过参与开源社区，你学习到的是真正能解决现实生产上的实战知识，而不是书本上的条条框框与课本理论。 |
| 让我们以 Apache ShardingSphere 为例。Apache ShardingSphere 受到了全世界编码员和学生的赞赏。以现有的社区数据为参考，即 14K+ 的 GitStars ，近 5K 的 fork ， GitHub 上近 250 个贡献者，以及 160+ 的真实用例场景，基于这些数据，任何人都会得出这个结论。更重要的是，它也是 Google Summer of Code 2021 、 Summer 2021 和 Open source Day 2021 的合作项目。 |
| 它的功能，如分片、数据加密、数据扩展、分布式加载测试的影子数据库等，都是出于解决大数据数据场景、分布式数据库和高并发性的真实行业需求而产生的。换句话说，人们选择它是为了解决他们的生产问题，并有机会将意见和优化再回馈到社区。这种前后呼应的模式使得这个社区变得活跃、多样化并且可以蓬勃发展。 |
| 2. 就业机会 如今，人力资源部门和招聘经理经常对候选人的资料和个人或职业发展项目进行筛选，因为他们认为这是一种实用和有效的方法，可以挑选出最佳候选人。从雇主的角度来看，这些做法是合理的。如果与传统的纸质简历相比，GitHub 可以更详尽地介绍你的资历、经验、技能，甚至个性。如果你参与的开源项目，在生产环境中被广泛使用，或者有同行业开发的解决方案，那么你在就业市场上就会非常具有吸引力，获得更好的机会。 |
| 如果你时常因为内卷或 30 岁求职而焦虑，那现在你将有新的应对之策。于是，当你获得了新发现的市场对你的技能和专业形象的赞赏的时候，你的自信心就会瞬间被提升了。 |
| 我听过很多这样的故事，Apache ShardingSphere 的 contributors 和 committers 收到了 HR 的面试电话，因为考虑到他们在开源社区的持续贡献和互动。此外，SphereEx 正在积极招募对分布式数据库中间件垂直领域的全职开源事业感兴趣的人才，以及 Java 开发人员。请务必在这里查看可用的机会。 |
| 3. 兴趣 &ldquo;Yep, I did it just for fun&rdquo;，这是我从我们的 contributors 和 committers 那里听到的另一个原因。我在开源社区所做的事情与我的工作无关，但这是我的爱好，我想参与到社区中去，与他人交流思想。这就是我在这里的原因，就是这样一个简单而又有说服力的答案。一个简单的事实是，尽管我们以利益驱动的心态来处理我们职业生活中的大部分问题，但我们可能会发现，我们在做这些事情时并没有把我们的 &ldquo;真心和灵魂 &ldquo;放在里面。找到属于你的激情或者副业可以让你重新发现自己，并且把这种积极的能量能带到你喜欢的事情上，这也会为你带来巨大的满足感，从而形成一个自我实现的循环。</description> |
| </item> |
| |
| <item> |
| <title>DistSQL：像数据库一样使用 Apache ShardingSphere</title> |
| <link>https://shardingsphere.apache.org/blog/cn/material/jul_26_an_introduction_to_distsql/</link> |
| <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> |
| |
| <guid>https://shardingsphere.apache.org/blog/cn/material/jul_26_an_introduction_to_distsql/</guid> |
| <description>Apache ShardingSphere 5.0.0-beta 深度解析的第一篇文章和大家一起重温了 ShardingSphere 的内核原理，并详细阐述了此版本在内核层面，特别是 SQL 能力方面的优化和提升。强大稳定的内核是 ShardingSphere 持续发展的基础，与此同时，ShardingSphere 在研发分布式数据库生态特性上也在努力摸索。本次 5.0.0-beta 版本发布的 DistSQL，用于搭配整个 ShardingSphere 分布式数据库体系，在提供更标准化的分布式数据库管理方式的同时，兼具灵活、便捷和优雅的特性。 |
| 本文将带领大家全面认识 DistSQL，并结合实战案例展示如何使用 DistSQL 一键管理 ShardingSphere 分布式数据库服务。 |
| 作者｜孟浩然 |
| SphereEx 高级 Java 工程师 |
| Apache ShardingSphere Committer |
| 曾就职于京东科技，负责数据库产品研发，热爱开源，关注数据库生态，目前专注于 ShardingSphere 数据库中间件开发以及开源社区建设。 |
| 初识 DistSQL 相信大家对 SQL（Structured Query Language）都不陌生，SQL 是一种数据查询和程序设计语言，同时作为关系数据库管理系统的标准语言，用于存取数据以及查询、更新和管理关系数据库系统。 |
| 和标准 SQL 类似，DistSQL（Distributed SQL），即分布式 SQL，是 ShardingSphere 特有的一种内置 SQL 语言，能够提供标准 SQL 之外的增量功能操作能力。借助于 ShardingSphere 强大的 SQL 解析引擎，DistSQL 提供了类似于标准 SQL 的语法结构和语法校验体系，在保证规范化的同时，也让 DistSQL 更加灵活。 |
| ShardingSphere 提出的 Database Plus 理念，旨在打造兼具数据库且贴合实际业务需求的开源分布式数据库体系，而 DistSQL 正是在传统数据库上层构建，提供既贴合标准又拥有 ShardingSphere 功能特色的 SQL 能力，能更好的为传统数据库赋能。</description> |
| </item> |
| |
| <item> |
| <title>元数据在 ShardingSphere 中加载的过程</title> |
| <link>https://shardingsphere.apache.org/blog/cn/material/oct_12_1_shardingspheres_metadata_loading_process/</link> |
| <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> |
| |
| <guid>https://shardingsphere.apache.org/blog/cn/material/oct_12_1_shardingspheres_metadata_loading_process/</guid> |
| <description>一、概述 |
| 元数据是表示数据的数据。从数据库角度而言，则概括为数据库的任何数据都是元数据，因此如列名、数据库名、用户名、表名等以及数据自定义库表存储的关于数据库对象的信息都是元数据。而 ShardingSphere 中的核心功能如数据分片、加解密等都是需要基于数据库的元数据生成路由或者加密解密的列实现，由此可见元数据是 ShardingSphere 系统运行的核心，同样也是每一个数据存储相关中间件或者组件的核心数据。有了元数据的注入，相当于整个系统有了神经中枢，可以结合元数据完成对于库、表、列的个性化操作，如数据分片、数据加密、SQL 改写等。 |
| 而对于 ShardingSphere 元数据的加载过程，首先需要弄清楚在 ShardingSphere 中元数据的类型以及分级。在 ShardingSphere 中元数据主要围绕着 ShardingSphereMetaData 来进行展开，其中较为核心的是 ShardingSphereSchema。该结构是数据库的元数据，同时也为数据源元数据的顶层对象，在 ShardingSphere 中数据库元数据的结构如下图。对于每一层来说，上层数据来源于下层数据的组装，所以下面我们采用从下往上的分层方式进行逐一剖析。 |
| 二、ColumMetaData 和 IndexMetaData |
| ColumMetaData 和 IndexMetaData 是组成 TableMetaData 的基本元素，下面我们分开讲述两种元数据的结构以及加载过程。ColumMetaData 主要结构如下： |
| public final class ColumnMetaData { // 列名 private final String name; // 数据类型 private final int dataType; // 是否主键 private final boolean primaryKey; // 是否自动生成 private final boolean generated; // 是否区分大小写 private final boolean caseSensitive; } 其加载过程主要封装在 org.apache.shardingsphere.infra.metadata.schema.builder.loader.ColumnMetaDataLoader#load 方法中，主要过程是通过数据库链接获取元数据匹配表名加载某个表名下所有的列的元数据。核心代码如下： |
| /** * Load column meta data list.</description> |
| </item> |
| |
| <item> |
| <title>Apache ShardingSphere：由开源驱动的分布式数据库中间件生态</title> |
| <link>https://shardingsphere.apache.org/blog/cn/material/oct_12_2_a_distributed_database_middleware_ecosystem_driven_by_open_source/</link> |
| <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> |
| |
| <guid>https://shardingsphere.apache.org/blog/cn/material/oct_12_2_a_distributed_database_middleware_ecosystem_driven_by_open_source/</guid> |
| <description>2021 年 7 月 21 日 2021 亚马逊云科技中国峰会现场，SphereEx 联合创始人、Apache ShardingSphere PMC 潘娟受邀参与此次峰会，以《Apache ShardingSphere 分布式数据库中间件开源生态构建》为主题，围绕开源理念扩散、社区建设、ShardingSphere 如何践行 Apache Way 等方面展开了介绍，本文总结自潘娟内容分享。 |
| 在数据库之上与业务之下的新生态 一层贴近应用，一层贴近 DataBase。 |
| 不同的行业、不同的用户、不同的定位、不同的需求&hellip;.如今的数据库面临着比过去更加复杂的数据应用场景以及愈发个性化和定制化的数据处理需求。愈发苛刻的生产环境，也在推动着不同的数据库不断将数据读写速度、延时、吞吐量等性能指标发挥到极致。 |
| 久而久之，分工明确的数据应用场景逐渐导致了数据库市场的碎片化，且难以出现一款能够完美适配所有场景的数据库。在不同的业务场景下选择不同的数据库，已经成为一种常见的企业选型方法。 |
| 但同样，这种百花齐放的数据库形态，也会带来『百花齐放』的问题。但从宏观的角度来看，这些问题之间是存在共性的，是可以被抽离出来并形成一套事实标准的。如果能够在这些百花齐放的数据库之上构建能够统一应用管理数据的平台层，就可以在屏蔽底层数据库差异的前提下，按照固定标准来进行开发，这种标准化解决方案将会极大缩减用户管理基础数据设施的压力和学习成本。 |
| Apache ShardingSphere 就是位于这一层，通过复用原有数据库的能力，能够帮助技术团队在此之上实现如分片、加密解密等增量能力的开发，且向下不需考虑底层数据库的配置，向上又能够屏蔽用户感知，从而快速构建起面向业务的数据库直连能力，轻松管理大规模的数据集群。 |
| 如何践行 Apache Way 1.Sharding |
| ShardingSphere 可同时叠加使用多个功能来满足用户的多样化需求。 |
| 随着业务体量的增大，单体数据库难以支撑大体量业务时，就有必要对数据库进行横向扩展，这就必然要面临着分布式管理的问题。ShardingSphere 通过在数据库之上构建一层热插拔功能层，并提供传统数据库的操作模式，屏蔽使用者对底层数据库变化的感知，赋予开发者使用单体数据库的方式来管理大规模数据库集群的能力。其中，ShardingSphere 主要包含以下四种应用场景： |
| Sharding 策略 业务体量增大时，所面临的数据分片压力就会随之增加，所对应的分片策略相应就会被设计的更加复杂。ShardingSphere 能够以灵活、易扩展的方式，以最低成本协助用户在原本水平扩展之外做更多的分片策略，同时也支持自定义扩展的能力。 |
| 读写分离 通常情况下实现主从部署能够有效缓解数据库的压力，但如果某一个集群下的机器或库表出现问题，无法进行正常读写操作，就会对业务造成比较大的影响。为避免业务不可用，通常需要开发者重新写一套高可用的策略来实现读写库表的主从切换。ShardingSphere 可以自动探索所有集群的状态，在第一时间发现请求不可靠、底层数据库发生主从切换等问题，并可以在表层用户没有产生感知的前提下自动恢复主从状态。 |
| Sharding Scaling 随着业务的增长，可能会需要对此前拆分过的数据集群进行再一次拆分。ShardingSphere 配套的 Scaling 组件，只需一条 SQL 命令就可以启动任务，并在后台实时展示运行状态。通过 Scaling 这种『管道』，使旧的数据库生态和新的数据库生态重新连接起来。 |
| 数据加解密 在数据库的应用中，对于关键数据的加解密也是非常重要的一部分。如果原有系统监控能力不达标，部分敏感数据可能是以明文的状态存储的，后期需要对其进行加密处理，这是许多团队普遍存在的问题。ShardingSphere 通过对这部分能力进行标准化并集成在中间件生态上，自动化用户对新、旧业务的数据脱敏以及加解密的过程，整个过程实现了用户层面的无感知。同时支持多种内置的数据加解密/脱敏算法，用户也可根据自身情况来自定义扩展相应的数据算法。 |
| 2.构造数据的接入神经：可插拔的 Database Plus 平台 |
| 面对各种各样的需求以及使用场景，ShardingSphere 为不同领域的开发者提供了面向 Java 的 JDBC、面向异构的代理端以及面向上云的 Sidecar 端这三种接入形式，用户可以按具体需求来做选型，在原有集群之上来做分片、读写分离、数据迁移等相关操作。</description> |
| </item> |
| |
| <item> |
| <title>趣说开源｜学生如何参与开源社区？</title> |
| <link>https://shardingsphere.apache.org/blog/cn/material/oct_12_3_how_can_students_participate_in_open-source_communities/</link> |
| <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> |
| |
| <guid>https://shardingsphere.apache.org/blog/cn/material/oct_12_3_how_can_students_participate_in_open-source_communities/</guid> |
| <description>现在的开发人员普遍都有开源项目或社区的经验。实际上，除了开发人员外，学生应该而且也越来越愿意参与到开源项目中。如果想知道更多关于为什么应该考虑参与开源项目，请参考“为什么应该加入开源社区[1]”。 |
| 可以说，过去的两年里充满了挑战，新冠疫情永远改变了我们，改变了我们贴近和珍视生活的方式，改变了我们的工作方式，改变了我们的社交方式，最终网络研讨会还有在线活动成为新常态。 |
| 学生也深受影响。在线学习意味着学生必须再次适应掌握课程内容的方式，同时也必须适应如何在这前所未有的艰难时期找到第一份职业机会或实习岗位，充分利用在线实习并获得宝贵经验已成为学生度过难关的一种选择。Google[2]，Anitab[3] 和 ISCAS[4]为学生提供多种在线开源项目和编程马拉松，目的是将世界各地的人联系起来。当然，大部分内容都是免费的，有的甚至为学生和导师提供相应的奖学金和学费。 |
| 简而言之，加入开源社区，学生将获益良多： |
| 练习技能 |
| 解锁实习机会，收获更多实习经验 |
| 与世界各地的伙伴和导师建立联系，交流合作 |
| 获得奖学金 |
| ##下一个问题就是如何利用这些具有吸引力的项目加入开源中？ |
| 虽然基本过程大体相同，但不同项目有不同规则，有些规则往往是明确的，即： |
| 选择一个开源项目或与与之相关的合作社区 |
| 提交学生加入申请 |
| 与导师取得联系 |
| 贡献及编程（编程是做出贡献的一种形式，此外还有很多贡献方式） |
| 等待评估 |
| 获得最终结果 |
| 基于以上步骤，我总结自己在 GSoC[2]、OSD[3] 和Summer Code[4] 的指导经验专门为你们提供一些关键技巧。 |
| 选择合适的项目 选择合适的项目我之前提到过，许多组织正在发起开源项目，而这些项目的日程安排不同、任务持续时间不同、要求的资历不同、奖学金条件也不同，因此最好研究不同的项目后，挑一个最适合你的项目。 |
| 提前选择一个特定的项目 如果你想要优先入选，千万不要等到官方截止日期才选择一个开源项目，这些项目的委员会通常会选择优秀的开源社区作为合作伙伴为其提供指导。例如，在成为正式的 GSoC 导师之前，我们的社区已经为申请人创建了很多任务，供公开申请[5]。 |
| 我们鼓励学生在项目开始前就发表见解，给学生和导师充分的时间去互相了解。也许某个学生可能不是特别合适，但他/她的积极主动给导师留下了深刻印象，导师有可能就会选中他/她。 |
| 简明扼要的申请书 项目申请书应该是简明扼要的，而非冗长又不充分的。要做到这一点，建议你参考导师的任务细节（有些导师会详细描述任务，有些则不会），或者直接询问导师的期望和关注点。当涉及到任务或任务目标时，打着一厢情愿的幌子去猜测或行动是准备申请书的方法中最低效的。导师和学生都希望工作能顺利有效地进行，所以不要羞于向导师寻求帮助。 |
| 积极联系导师 如果你的申请被接受了，那么下一阶段就是参与其中或开始 coding，这是你产生价值的重要机会。你可能是编码奇才，但是你会遇到一些不确定的问题，或者不确定导师对你的工作有什么看法。此外，你还要考虑到，有些导师负责两三个学生，生活和工作都很忙。话虽如此，我相信你可以切身感受主动联系导师问问题或定期报告进展是非常有益的。如果你只是等待，等到导师想起你，可能已经太迟了，消极等待是行不通的。 |
| 微妙的问题 虽然有必要与导师保持密切联系，但你不能成个什么都不懂的巨婴。事先考虑一下你的问题，自己进行调查研究，看看你是否能用批判性思维独立解决问题，或者是向人人信任的朋友—— Google 寻求解答。 |
| 如果你做不到的话，导师可能会认为你缺乏分析解决问题的能力，或者更糟的是，认为你不愿意在实践中学习。如果你在研究后仍然感到困惑，那么就准备用专业术语和研究报告向导师咨询。这不仅能确保你得到导师的关注，而且能让导师了解你真的遇到了一些困难，导师就会全心全意的帮助你。我在指导了很多国内外的学生后，可以与大家分享我的以上看法。我真诚地鼓励你们来试试这些有趣而有意义的项目，丰富校园生活，增强技能，扩大朋友圈。最后还有非常重要的一点就是，如果有兴趣加入分布式数据库开源生态系统，我在等你们的加入[6]。 |
| 作者 |
| 潘娟 | Trista |
| SphereEx 联合创始人、Apache Member、Apache ShardingSphere PMC、Apache brpc（Incubating）及 Apache AGE（Incubating）mentor。曾任京东科技 Senior DBA（高级数据库管理员），负责京东数字科技智能数据库平台的设计开发。现专攻分布式数据库中间件生态系统以及开源社区，获得“2020 中国开源先锋奖”，常受邀在数据库架构领域峰会上进行分享。</description> |
| </item> |
| |
| <item> |
| <title>ShardingSphere 知识库更新 | 官方样例集助你快速上手</title> |
| <link>https://shardingsphere.apache.org/blog/cn/material/oct_12_4_updates_and_faq_your_1_minute_quick_start_guide_to_shardingsphere/</link> |
| <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> |
| |
| <guid>https://shardingsphere.apache.org/blog/cn/material/oct_12_4_updates_and_faq_your_1_minute_quick_start_guide_to_shardingsphere/</guid> |
| <description>Apache ShardingSphere 作为 Apache 顶级项目，是数据库领域最受欢迎的开源项目之一。经过 5 年多的发展，ShardingSphere 已获得超 14K Stars 的关注，270+ 贡献者，建立起了活跃的社区生态。 |
| 随着项目的蓬勃发展，版本的不断更迭，Apache ShardingSphere 支持的特性逐渐增多，功能日益强大，配置规则也在不断优化。为了帮助用户更好地理解各项特性和配置规则，方便用户快速测试并运行相关功能组件，找到最佳实现，shardingsphere-example 项目应运而生。 |
| shardingsphere-example 是一个独立的 Maven 项目，位于 Apache ShardingSphere 项目的 examples 目录下。项目地址： |
| https://github.com/apache/shardingsphere/tree/master/examples |
| 江龙滔 |
| SphereEx 中间件研发工程师，Apache ShardingSphere contributor。目前专注于 ShardingSphere 数据库中间件研发及开源社区建设。 |
| 侯阳 |
| SphereEx 中间件研发工程师，目前从事 ShardingSphere 数据库中间件研发，热爱开源，希望同大家一起建设更好的社区。 |
| 模块详解 shardingsphere-example 项目包含多个模块，将为用户带来水平拆分、读写分离、分布式治理、分布式事务、数据加密、强制路由、影子库等功能的使用及配置样例，覆盖 Java API、YAML、Spring Boot、Spring Namespace 等多种业务常用的接入形态。除了 ShardingSphere-JDBC，shardingsphere-example 中还增加了 ShardingSphere-Proxy 和 ShardingSphere-Parser 的使用案例。 |
| 所有涉及到 Apache ShardingSphere 的功能特性、接入场景以及各种灵活的配置方式，都可以在官方的 repo 里找到样例，方便用户查询和参考。下表展示了 shardingsphere-example 的模块分布情况： |
| shardingsphere-example ├── example-core │ ├── config-utility │ ├── example-api │ ├── example-raw-jdbc │ ├── example-spring-jpa │ └── example-spring-mybatis ├── shardingsphere-jdbc-example │ ├── sharding-example │ │ ├── sharding-raw-jdbc-example │ │ ├── sharding-spring-boot-jpa-example │ │ ├── sharding-spring-boot-mybatis-example │ │ ├── sharding-spring-namespace-jpa-example │ │ └── sharding-spring-namespace-mybatis-example │ ├── governance-example │ │ ├── governance-raw-jdbc-example │ │ ├── governance-spring-boot-mybatis-example │ │ └── governance-spring-namespace-mybatis-example │ ├── transaction-example │ │ ├── transaction-2pc-xa-atomikos-raw-jdbc-example │ │ ├── transaction-2pc-xa-bitronix-raw-jdbc-example │ │ ├── transaction-2pc-xa-narayana-raw-jdbc-example │ │ ├── transaction-2pc-xa-spring-boot-example │ │ ├── transaction-2pc-xa-spring-namespace-example │ │ ├── transaction-base-seata-raw-jdbc-example │ │ └── transaction-base-seata-spring-boot-example │ ├── other-feature-example │ │ ├── encrypt-example │ │ │ ├── encrypt-raw-jdbc-example │ │ │ ├── encrypt-spring-boot-mybatis-example │ │ │ └── encrypt-spring-namespace-mybatis-example │ │ ├── hint-example │ │ │ └── hint-raw-jdbc-example │ │ └── shadow-example │ │ │ ├── shadow-raw-jdbc-example │ │ │ ├── shadow-spring-boot-mybatis-example │ │ │ └── shadow-spring-namespace-mybatis-example │ ├── extension-example │ │ └── custom-sharding-algortihm-example ├── shardingsphere-parser-example ├── shardingsphere-proxy-example │ ├── shardingsphere-proxy-boot-mybatis-example │ └── shardingsphere-proxy-hint-example └── src/resources └── manual_schema.</description> |
| </item> |
| |
| <item> |
| <title>易华录 X ShardingSphere｜葫芦 App 后台数据处理的逻辑捷径</title> |
| <link>https://shardingsphere.apache.org/blog/cn/material/oct_12_5_e-hualu_shardingsphere_hulu_story_data_processing_shortcut/</link> |
| <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> |
| |
| <guid>https://shardingsphere.apache.org/blog/cn/material/oct_12_5_e-hualu_shardingsphere_hulu_story_data_processing_shortcut/</guid> |
| <description>“ShardingSphere 大大简化了分库分表的开发和维护工作，对于业务的快速上线起到了非常大的支撑作用，保守估计 ShardingSphere 至少为我们节省了 4 个月的研发成本。” ——史墨轩，易华录·技术总监 今年以来，伴随着易华录旗下面向个人用户的云服务产品**【葫芦 App】**正式上线，后台架构所承受的业务压力也与日俱增。 |
| 为此，葫芦 App 研发团队选择采用 ShardingSphere 分库分表的功能对数据进行了横向的拆分，围绕 ShardingSphere 灵活敏捷的特性，满足了葫芦 App 业务对数据层扩展性的要求，避免团队重复“造轮子”，最大程度简化了随着业务增长而带来的愈发复杂化的分库分表的开发与维护工作。 |
| 从能力扩展到业务上新，葫芦 App 所面临的增长压力 对于数据存算能力的高要求，深深铸在了葫芦 App 技术团队的基因中。 |
| 由于葫芦 App 正处于快速成长期，业务和功能的调整需求相对频繁，这就需要后台技术团队能够根据前端业务变化而快速做出适配调整。用户数量和业务所产生的数据体量都在飞速增长的同时，也为后台底层数据库带来了更大的压力。 |
| 随着 2020 年 5 月 17 日葫芦 App 的正式上线，用户数据和业务体量也呈现出快速增长的态势，后台数据库不可避免地需要进行多次水平拆分。同时随着业务需求的快速变化，新的挑战也不断随之出现： |
| 能力扩展问题 随着用户量的快速增长以及产品形态的演变，用户数据出现了爆发式增长，过去传统架构的存算能力遭到了极为严峻的挑战，因此葫芦App 对于后端数据处理平台的要求是在具备扩展能力的同时，也要保证一定的灵活性。 |
| 效率提升问题 为应对快速多变的业务，葫芦 App 的研发团队需要能够根据业务诉求来进行快速调整，以提升后台架构对业务的适应性，高灵活、易拓展特性的数据架构将能够极大提升团队研发效能。另一方面在大体量数据的影响下，数据库的检索效率难免出现延迟、读写慢等问题，进而会影响到最上层的用户体验。 |
| 业务上线问题 功能上新频繁、上线时间提前等是任何一款新产品在上市初期都会遇到的问题，这对研发团队的研发能力提出了极大挑战。此前葫芦团队本计划通过内部研发力量并结合业务情况打造出自己的 Sharding 方案，不过由于时间关系，从方案设计、研发再到方案落地的自研路线已无法走通，因此敲定 Sharding 方案迫在眉睫。 |
| 系统稳定问题 在引入新技术的同时，系统稳定性也会面临较大的挑战，尤其是面向底层技术的引用，大多具备一定的平台业务侵入性，在引入后大概率会对业务系统的稳定性产生一定影响。葫芦 App 研发团队需要一款对底层数据库侵入性低、适应期短、稳定性高的数据应用产品。 |
| 利用 ShardingSphere 的特性构建灵活高可用的数据架构解决方案 围绕上述的一些诉求，葫芦团队用了 2 周左右时间对 ShardingSphere 及同类解决方案进行了全面评估，综合考虑了如产品功能、成熟度、稳定性、性能等多方面评估指标，最终 ShardingSphere 凭借完善的功能支持程度以及高成熟度，充分满足了葫芦团队的业务诉求。</description> |
| </item> |
| |
| <item> |
| <title>分片利器 AutoTable：为用户带来「管家式」分片配置体验</title> |
| <link>https://shardingsphere.apache.org/blog/cn/material/oct_12_6_autotable_your_butler-like_sharding_configuration_tool/</link> |
| <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> |
| |
| <guid>https://shardingsphere.apache.org/blog/cn/material/oct_12_6_autotable_your_butler-like_sharding_configuration_tool/</guid> |
| <description>在《DistSQL：像数据库一样使用 Apache ShardingSphere》一文中，Committer 孟浩然为大家介绍了 DistSQL 的设计初衷和语法体系，并通过实战操作展示了一条 SQL 创建分布式数据库表的强大能力，展现了 Apache ShardingSphere 在新形态下的交互体验。 |
| 在前文发布后，小助手陆续收到热心读者的私信，询问使用 DistSQL 配置分片规则的细节，以及使用 YAML、Namespace 等形式的配置时，是否可以像 DistSQL 一样快速方便的完成分布式表的配置和创建？本文将为大家解答这些疑问。 |
| 江龙滔 |
| SphereEx 中间件研发工程师，Apache ShardingSphere contributor。目前专注于 ShardingSphere 数据库中间件研发及开源社区建设。 |
| 背景 Sharding是 Apache ShardingSphere 的核心特性，也是 ShardingSphere 最被人们熟知的一项能力。在过去，用户若需要进行分库分表，一种典型的实施流程（不含数据迁移）如下： |
| 图1 Sharding 实施流程示意图 在这一过程中，用户需要准确的理解每一张数据表的分片策略、明确的知晓每张表的实际表名和所在数据库，并根据这些信息来配置分片规则。 |
| 以上述分库分表场景为例，实际的数据表分布情况可能如下： |
| 图2 8 库 * 4 表分布示意图 痛点 在前述的分库分表场景中，作为 Sharding 功能的用户，必须要对数据表的分布情况了然于心，才能写出正确的 actualDataNodes 规则。如上述 t_order 表对应的分片配置如下： |
| tables: t_order: actualDataNodes: ds_${0..7}.t_order_${0..3} databaseStrategy: standard: shardingColumn: order_id shardingAlgorithmName: database_inline tableStrategy: standard: shardingColumn: order_id shardingAlgorithmName: table_inline shardingAlgorithms: database_inline: type: INLINE props: algorithm-expression: ds_${order_id % 8} table_inline: type: INLINE props: algorithm-expression: t_order_${order_id % 4} 尽管 ShardingSphere 的配置规则已经非常的规范和简洁，但仍有用户在使用中遇到各种麻烦：</description> |
| </item> |
| |
| <item> |
| <title>openGauss X ShardingSphere，分布式方案的另一种最佳实践</title> |
| <link>https://shardingsphere.apache.org/blog/cn/material/oct_12_7_opengauss_shardingsphere_one_of_the_top_distribution_solutions/</link> |
| <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> |
| |
| <guid>https://shardingsphere.apache.org/blog/cn/material/oct_12_7_opengauss_shardingsphere_one_of_the_top_distribution_solutions/</guid> |
| <description>Apache ShardingSphere 持续助力于 openGauss 分布式数据库能力的构建。openGauss 数据库自 2020 年 6 月开源以来，受到了业界的广泛关注，现已吸引众多伙伴、开发者参与其中，共建繁荣的数据库生态。面对如今海量数据，超高并发等诸多场景，openGauss 将目光转向于分布式解决方案，专注于解决海量数据存储、超高并发吞吐、大表瓶颈等众多难题，与 ShardingSphere 一起构建全栈开源分布式解决方案，实现 openGauss 的又一大突破。 |
| 分布式解决方案 图1 分布式解决方案整体框图 openGauss 融合了众多开源组件，用以构建集数据水平扩展、分布式事务及治理一体化的全栈开源分布式解决方案，整体框图如图 1 所示。 |
| 其中 ShardingSphere-Proxy 为开源分布式解决方案，具有分库、分表、分布式事务、弹性伸缩、读写分离等众多能力； |
| HAProxy 结合 Patroni 的 REST API，可以始终识别数据库的主节点，保证高可用场景，同时可实现负载均衡； |
| 每个 Patroni 高可用节点支持一主多备，每个节点使用 Paxos 协议保证数据的一致性，各个节点可以部署在相同或不同的区域，用以保证多地多中心的数据安全。 |
| 本分布式方案运用 ShardingSphere-Proxy 强劲的分布式能力，通过 kubernetes 管理集群，prometheus 监控集群状态，从而构建全栈开源的分布式解决方案。 |
| 产品优势 1.极致扩展能力，灵活扩缩容 |
| 计算与存储能力可通过水平拆分实现线性扩展，最高可达数据 6400 分片，性能随扩展准线性增长，可有效解决单表数据量膨胀问题；结合业务流量，灵活平滑进行数据节点的扩缩容，智能读写分离，实现分布式数据库的自动负载均衡。 |
| 2.丰富企业级特性 |
| 支持分布式存储过程、触发器，分布式事务，全密态数据加密，WDR 诊断报告，提供丰富的企业级特性。 |
| 3.一键部署，屏蔽底层依赖 |
| 标准化镜像确保多环境一致性交付，容器化部署，实现物理资源池化，降低对平台的依赖性，简洁高效，实现应用秒级部署。 |
| 4.超高可用，实现异地容灾 |
| 强有力的集群管理、运维能力，支持同城、异地、多地多中心灵活部署，基于 Paxos 协议保证数据的安全及强一致性，提供 RPO=0 的多种容灾能力。 |
| 5.开源开放，构建全栈生态 |
| 开源 openGauss 单机及分布式解决方案，鼓励更多伙伴、开发者共同参与其中，共建数据库的繁荣生态，打造全栈开源生态链。</description> |
| </item> |
| |
| <item> |
| <title>ShardingSphere X Google 编程之夏：同学，开源你怎么看？</title> |
| <link>https://shardingsphere.apache.org/blog/cn/material/oct_12_8_shardingsphere_google_summer_of_code_students_how_was_your_open_source_experience/</link> |
| <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> |
| |
| <guid>https://shardingsphere.apache.org/blog/cn/material/oct_12_8_shardingsphere_google_summer_of_code_students_how_was_your_open_source_experience/</guid> |
| <description>Apache ShardingSphere 社区有幸参与 Google 编程之夏（Google Summer of Code, 以下简称 GSoC)，指导年轻一代参与开源程序代码设计。GSoC 是 Google 公司主办的年度开源程序设计项目，第一届从 2005 年开始，主要目的是鼓励世界各地的学生参与开放源代码的程序设计。而 Apache ShardingSphere 项目也被选中成为 GSoC 一部分，为学生带来开源软件开发的有趣体验。 |
| Thanoshan 和 Liangda两位学生在上一届的 GSoC 中积极与 Apache ShardingSphere 导师工作，接受指导，在 GSoC 结束后依旧在 ShardingSphere 项目中积极贡献。 他们欣然接受了我们的采访，分享自己的 GSoC 项目申请经验，谈自己对 Apache ShardingSphere 项目和开源社区的看法，以及个人的未来计划。 |
| &lt;个人简介&gt; Thanoshan |
| 国家：斯里兰卡 院校：斯里兰卡萨巴拉加穆瓦大学 专业：计算机与信息系统 |
| Liangda |
| 国家：德国 院校：曼海姆大学 专业：商业信息学 |
| Q&amp;A Q1: 你们是如何喜欢上软件开发的呢？ |
| **Thanoshan：**我的专业学位和软件开发有关，不过我个人在上大学之前就对软件开发就非常感兴趣。 |
| **Liangda：**应该是受到我所学专业的影响。高中时，我对商业和计算机科学都非常感兴趣，所以我选择了商业信息学专业，这个专业把这两个领域结合在一起了，上大学后，我开始了自己的编程之旅，接触到了软件开发，学习了 Java，C++，Python，还有软件设计模式等知识。 |
| Q2: 为什么选择申请 GSoC？ |
| **Thanoshan：**在斯里兰卡，我的很多学长学姐都已经参加过了 GSoC，他们建议我去了解一下这个项目机会，积极安利我一定要试试。然后，我搜索了很多这个项目的相关信息，去了解这个项目，并明确如何能够申请这个项目。 |
| **Liangda：**我第一次知道 GSoC 是在去年夏天，我无意间在网络上找到一篇分享 GSoC 经验和申请的博文，那时我就对这个项目非常着迷。不过当时开源对我来说还是十分陌生的概念，我就望而却步，没有信心申请。之后在 2020 年的寒假，我有机会在学校的一个聊天机器人开发项目中担任助研，这个项目使用了 Rasa，Rasa 是一套开源机器学习框架。这也是我第一次深入了解开源框架，接触开源社区。这是一次非常棒的经历，所以我一下子就想到了 GSoC，我对自己说“为什么不试试 GSoC，继续去探索开源呢？”。</description> |
| </item> |
| |
| <item> |
| <title>Apache ShardingSphere 在京东白条场景的落地之旅</title> |
| <link>https://shardingsphere.apache.org/blog/cn/material/oct_12_9_shardingsphere_jd_baitiao_story_of_an_implementation_journey/</link> |
| <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> |
| |
| <guid>https://shardingsphere.apache.org/blog/cn/material/oct_12_9_shardingsphere_jd_baitiao_story_of_an_implementation_journey/</guid> |
| <description>京东白条使用 Apache ShardingSphere 解决了千亿数据存储和扩容的问题，为大促活动奠定了基础。 |
| 2014 年初，“京东白条”作为业内互联网信用支付产品，数据量爆发式的增长，每一次大促备战都是对技术人员的考验，每一次的战略转型驱动着数据架构的成长。 |
| &ndash;张栋芳，京东白条研发负责人 |
| 京东白条数据架构演进史 自 2014 年 2 月京东白条业务上线起，为满足快速发展的业务和激增的海量数据，白条的数据架构经历了数次演进。 |
| 2014～2015 Solr + HBase 的方案解决了核心、非核心业务系统对关键数据库的访问问题，Solr 作为被检索字段的索引，HBase 用作全量的数据存储。 |
| 通过 Solr 集群分担部分读和写的业务，缓解核心库的压力； |
| Solr 扩展体验上欠佳，对业务也存在较大的入侵。 |
| 2015～2016 引入 NoSQL 方案，业务数据以月份进行分表存储在 MongoDB 集群中，阶段性满足了结算处理场景中海量数据导入导出的需求。 |
| 查询热点数据效率高，非结构化的存储方式易于修改表结构； |
| 依然面对着扩展差、对业务入侵强的局面，而且耗内存。 |
| 2016～2017 随着业务快速发展，数据量突破百亿大关，此时 MongoDB 面临着容量和性能的双重考验。京东白条大数据平台通过 DBRep 以 MySQL Slave 的形式采集变动信息并存储到消息中心，最后落盘到 ES 和 HBase 中。</description> |
| </item> |
| |
| <item> |
| <title>ShardingSphere-Proxy：从实际场景出发，快速上手</title> |
| <link>https://shardingsphere.apache.org/blog/cn/material/proxyintroduce/</link> |
| <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> |
| |
| <guid>https://shardingsphere.apache.org/blog/cn/material/proxyintroduce/</guid> |
| <description>本篇文章主要从项目中实际场景出发，讲解分库分表等功能在日常运维中遇到的问题，以及 ShardingSphere-Proxy 对应的解决方案，版本号：v5.1.0。 |
| 如无特别声明，以下示例中的数据库指 MySQL。 |
| 这个项目做什么 ShardingSphere-Proxy，可以让用户像使用原生数据库一样使用 Apache ShardingSphere。 |
| 了解一项技术的开始，一般从官网开始。先来看一看官网对 ShardingSphere-Proxy 的定义是什么样的： |
| 定位为透明化的数据库代理端，提供封装了数据库二进制协议的服务端版本，用于完成对异构语言的支持。 目前提供 MySQL 和 PostgreSQL（兼容 openGauss 等基于 PostgreSQL 的数据库）版本，它可以使用任何兼容 MySQL/PostgreSQL 协议的访问客户端（如：MySQL Command Client, MySQL Workbench, Navicat 等）操作数据，对 DBA 更加友好。 |
| 先明确一个概念，ShardingSphere-Proxy 是一个服务进程。从客户端程序连接来说，它和 MySQL 数据库并没有什么区别。 |
| 为什么要用 Proxy 在做了分库分表或其他规则的情况下，数据会分散到多个数据库实例上，在管理上难免会有一些不便；或者使用非 Java 语言的开发者，需要 ShardingSphere 所提供的能力…… 以上这些情况，正是 ShardingSphere-Proxy 力所能及之处。 |
| 1. Proxy 应用场景 日常工作中，大家使用 ShardingSphere-JDBC 进行分库分表的场景是比较多的。假设你有一张用户表，通过用户 ID 以 Hash 的方式进行了水平分库，那么此时客户端连接数据库的方式是这样： |
| 我们举例工作中真实存在的几个场景： |
| 测试同学想看下用户 ID 123456 的信息在数据库表里情况，需要你提供下用户在哪一张分表； 公司领导需要技术提供一份 2022 年用户的增长总量以及用户信息； 公司举行 8 周年活动，需要技术提供一份注册日期超过 8 周年的活跃老用户名单。 因为数据分库分表后，数据是散落在不同的库表中，对于上述的场景实现并不容易；如果为了实现类似临时需求，每次都需要开发代码，显得有些笨重。这个时候就需要文章主角 ShardingSphere-Proxy 登场了。</description> |
| </item> |
| |
| <item> |
| <title>Apache ShardingSphere 代码格式化实战 —— Spotless</title> |
| <link>https://shardingsphere.apache.org/blog/cn/material/spotless/</link> |
| <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate> |
| |
| <guid>https://shardingsphere.apache.org/blog/cn/material/spotless/</guid> |
| <description>为什么要代码格式化？代码格式化的意义是让代码更加 易读易懂易修改。 |
| ShardingSphere 作为 Apache 顶级开源项目，截止当前已有 380+ 贡献者。因为大部分开发人员的代码风格不一致，在 Github 多人协作的模式下，不易保障项目整体代码格式。 |
| 基于以上诉求，ShardingSphere 采用了 Spotless 充当代码格式统一的角色。 |
| 什么是 Spotless Spotless 是支持多种语言的代码格式化工具，支持 Maven 和 Gradle 以 Plugin 的形式构建。 |
| Spotless 对开发者来说，有 2 种使用方式：检查代码是否存在格式问题，以及格式化代码。 |
| ShardingSphere 采用 Maven 构建项目，以下若无特殊声明，Spotless 使用 Maven 做演示。 |
| 如何使用 下述代码是 Spotless 官方示例。 |
| user@machine repo % mvn spotless:check [ERROR] &gt; The following files had format violations: [ERROR] src\main\java\com\diffplug\gradle\spotless\FormatExtension.java [ERROR] -\t\t····if·(targets.length·==·0)·{ [ERROR] +\t\tif·(targets.length·==·0)·{ [ERROR] Run &#39;mvn spotless:apply&#39; to fix these violations. user@machine repo % mvn spotless:apply [INFO] BUILD SUCCESS user@machine repo % mvn spotless:check [INFO] BUILD SUCCESS 通过 mvn spotless:check 检查项目代码时发现错误，接着使用 mvn spotless:apply 进行代码格式化；再次检查时，格式化错误消失。</description> |
| </item> |
| |
| </channel> |
| </rss> |
