Sharding-JDBC：分布式微服务数据库访问框架的设计与实现
内容来源：2017年12月23日，当当架构部总监张亮在“2017源创会年终盛典 ”进行《分布式微服务数据库访问框架Sharding-JDBC的设计与实现》演讲分享。IT 大咖说作为独家视频合作方，经主办方和讲者审阅授权发布。
阅读字数：1602 | 6分钟阅读
摘要
当当架构部总监分享分布式微服务数据库访问框架Sharding-JDBC的设计与实现。
https://v.qq.com/txp/iframe/player.html?vid=t05435kyx3q&width=500&height=375&auto=0
我们在互联网领域数据库面临的问题主要有高可用、存储稳定性要求高、并发访问频繁和数据海量。
现在各种数据库的方案对比主要分成三个流派，一种是常见的RDBMS，也就是所谓的关系型数据库。它对于SQL的支持是原生的，而且大部分开发团队对SQL是最熟悉的，它的查存也足够灵活，包括它的语法大家也非常熟悉。
第二个就是NoSQL，它其实是SQL一个有益的补充。在这种情况下它对SQL是不支持的，但是支持其它。
第三种是NewSQL，这个是目前比较火的一种新型数据库。它对SQL的支持并不完善，不能百分百地支持所有的SQL。
对于事务来说，RDBMS用了我们最擅长的ACID，通过ACID能有效地控制单机的事务。
对于分布式事务的场景，使用的是XA的方式。这种方式虽然可用，但性能是不能被我们所接受的。
在NoSQL方面它用的是BASE，是一个基本可用的柔性事务相关的方案，这种方式不是强一致性的，它会追求最终一致性。也就是说对于强一致性相关事务要求还是有问题的。
NewSQL用的是google当时发布的一篇论文，基于F1的方式去做的。
从存储引擎上看，最成熟的方式是原生的存储引擎。
NoSQL其实已经非常成熟了，但它还是一个待验证的状态，因为它是完全重写的存储引擎。
数据分片这方面是传统关系型数据库最麻烦的地方，因为它的数据分片只能有限地支持。但是NoSQL和NewSQL是一个面向分布式的解决方案，所以这个方面它们支持的比较好。
动态扩容这部分关系型数据库完全不支持，NoSQL可以有限地支持，NewSQL支持得比较好。
开发友好，面向SQL。存储引擎稳定，单节点事务引擎成熟。未达阀值的单机性能高。
单节点并发访问频率受限，单节点数据承载量受限，分布式事务性能难以接受，分布式扩展困难。
当当数据库中间层的关注重点主要在于分片，分片包含了分库分表、读写分离和分布式主键这三点。
事务目前并没有做到特别完善和成熟，只支持弱XA和柔性事务。弱XA就是如果网络节点不发生问题，这个事务可以正常提交回滚。但是一旦在多个数据库之间网络闪断，这时事务的一致性可能会受到破坏。它会用柔性事务的方案来做补偿，到达最终事务的一致性。
还有治理的功能，包括配置动态化和数据源自动切换。
分片类型有垂直分片和水平分片两种。垂直分片根据业务进行拆分，而水平拆分是利用把数据完全打散的方式去做，和业务完全没有关系。
水平分片策略分为很多种，例如有哈希取模分片、范围分片、标签分片、时间分片和复合分片。
实现方案分为分透明化和透明化。非透明化的实现方案一般是由业务开发自发地修改业务的SQL，并指定几个数据源。
透明化就是完全屏蔽分片的细则，始终像使用一个数据库一样去使用。
Proxy单独建一个中间的路由转发器，通过它去做分片和路由。
ORM是一个对象和关系映射的框架，在框架里去做分片。
JDBC是java对数据库访问的一个核心协议。
开源的分布式数据库中间件，它无需额外部署和依赖，旧代码迁移成本几乎为零。
面向开发的微服务与于原生的基础类库。
完整的实现了分库分表、读写分离和分布式主键功能，并初步实现了柔性事务，治理正在功能开发中。
无需解析SQL的场景：仅分库的单分片查询；仅分库的跨分片的无聚合、排序、分组查询。
需要解析SQL的场景：包含分表的查询；跨分片的聚合、排序、分组查询；复杂查询，如OR、UNION、子查询等。
读写分离有仅读写分离、仅分库分表和分库分表+读写分离三种。
仅读写分离无论多复杂的SQL都可以支持。
分库分表+读写分离就是例如数据已经分成了十片，每一片都有“一主两从”这种方式。
Inline表达式可以通过写一段脚本去配置它分片的策略。
分布式自增序列通过无中心化的方式生成在分布式下比较有序而且不会重复的分布式的主键。
还有一个功能就是柔性事务。
今天的分享就到这里，谢谢大家！
相关推荐
推荐文章
近期活动