Apache ShardingSphere (Incubating)是一套开源的分布式数据库中间件解决方案组成的生态圈，它由Sharding-JDBC、Sharding-Proxy和Sharding-Sidecar（规划中）这3款相互独立的产品组成。他们均提供标准化的数据分片、分布式事务、数据库治理和管控界面（规划中）功能，可适用于如Java同构、异构语言、容器、云原生等各种多样化的应用场景。

自2018年11月进入Apache基金会孵化器以来，Apache ShardingSphere(Incubating)不仅在核心功能上不断完善和巩固，而且加大了社区建设、对外合作等工作的投入，聆听社区的声音，不断深化国际化发展路线。

• API调整

1. 调整数据库治理模块的注册中心存储结构。

2. 调整Sharding-JDBC的配置相关API。

• 新功能

1. 支持XA强一致事务。

2. 路由至单一数据节点的SQL 全兼容（目前仅MySQL）。

3. 支持DISTINCT语句。

4. 支持广播表。

5. 解决使用默认分布式自增主键在TPS不高的情况下可能导致数据倾斜的问题。

本次发布的3.1.0版本将前不久发布的3.1.0.M1版本的核心功能打磨优化，并对其出现的问题进行调整修复。此外，在大规模应用实战中我们还发现3.1.0版本存在的一个较大的Bug。

P.S. 为了不影响大家正常使用，我们将根据实际反馈考虑发布3.1.0.1的Hot Fix版本，还是直接在4.x的版本中修复。

3.1.0Bug详解

Bug现象:

当在使用iBATIS+HikariCP的工程中使用Sharding-JDBC时，会导致该工程在30分钟之后抛出异常:

com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: No operations allowed after connection closed.

原因分析:

Sharding-JDBC在初始化时会通过数据库连接池的某个Connection缓存了一份DatabaseMetaData的引用。HikariCP的maxLifetime的默认值是1800000 (30 minutes)，所以30分钟后该Connection会被HikariCP清除。由于iBATIS在每次查询前都会查看DatabaseMetaData，此时再通过该Connection获取DatabaseMetaData引用时就会抛出如上异常。

该Bug仅在使用iBatis时才会出现，并不会影响原生JDBC、MyBatis、JPA以及Hibernate等其他ORM框架。而iBatis已经于2010年停止更新，因此影响并不广泛。

关联issue:

https://github.com/sharding-sphere/sharding-sphere/issues/1712

尽管3.1.0远未达到完美的境界，但它毕竟在长达3年的孵化中，经历了35个版本后而诞生，意义重大。非常感谢开源爱好者们3年来的关注和陪伴。尽管分布式事务刚刚起步、SQL 兼容的开发仍在路上，但鉴于ShardingSphere目前已经进入Apache基金会孵化器的现状，因此在这个时间节点，我们不得不为ShardingSphere的3.X版本画上"休止符"，但若3.X版本中仍存在较大问题，我们依然会立即进行修复，并有可能推出3.1.0.X版。于此同时，ShardingSphere也将正式开启新篇章，同步进行4.X版本的开发，以尽快发布Apache Release作为目前的工作重点，欢迎广大开源爱好者共同参与社区建设。

1. Sharding-JDBC获取方式

<groupId>io.shardingsphere</groupId>

<artifactId>sharding-jdbc-core</artifactId>
<version>3.1.0</version>

2. Sharding-Proxy获取方式

docker pull shardingsphere/sharding-proxy