1.透明化使用方无感知,或者尽量少感知。通过现有的接入端接入已有服务
2.增量服务不改变数据库本身功能的前提下,提供额外的功能与服务一个原则不破坏原有逻辑,并且让用户基于之前的经验可以快速上手
接入端协议的选择
1.编程语言接口(jdbc) 2.数据库协议(数据库本身的协议,不同的数据库有不同的协议,而且有的公开,有的还不公开)
数据库 任意 单一
异构语言 单一 任意
连接数 高(代理) 低
性能 损耗低 损耗略高
无中心化 是 否
静态入口 无 有(可独立部署)
确立目标
1.数据分片屏蔽数据库分片,使用无感知,应该和不分片的使用一样
2.分布式治理配置动态化,监控,调用链,熔断,失效转移(开着飞机换引擎),弹性伸缩
3.分布式事务跨片访问较大时,物理存储确实可能跨库访问两阶段事务,柔性事务
4.安全管控SQL审计(避免慢sql等),数据脱敏(脱敏和非脱敏自动转换),权限控制
数据库中间件和NewSQL的对比
1.数据库中间件 2.NewSQL
设计理念 稳定+增量 颠覆+兼容(架构颠覆,外形兼容)
存储引擎 沿用关系型数据库 自研(大部分K-V为主)
分布式能力 增量 原生
可信赖度 高 待验证(需要时间检测,数据库一般十年才能说稳定)
HTAP(混用) 较难 较易(数据库中间件可能会有重复的问题,比如数据库分片,需要解析sql,中间件才能知道去哪片执行,
但真正的数据库层,也会解析sql,才能知道怎么执行sql,所以解析sql会有重复,不可避免)
ShardingSphere简单介绍(本文也是听开源者张亮同学的视频的总结)
核心功能数据分片,分布式事务,数据库治理弹性伸缩,管控界面
接入端Sharding-JDBC,Sharding-Proxy,Sharding-Sidecar
核心功能+接入端=(HTAP,云原生,零侵入)
接入端技术储备
编程语言接口JDBC接口各种数据库连接池各种ORM框架和Spring相关知识(Spring自定义命名空间)
数据库协议MySQL & PostgreSQL协议IO Netty并发 & 多线程
数据分片技术储备
SQL解析(Lexer,Parser,AST)
SQL路由(去哪个片)
SQL改写(到了某个片)
SQL执行(多线程)
结果归并(排序算法)
分布式事务技术储备
两阶段事务ACID事务要素XA协议以及他的各种实现Percolator事务模型(时间戳+两阶段事务做成强一致,来自谷歌论文)
柔性事务BASE和CAP理论TCC和Saga自动补偿,反向SQL数据快照,版本控制
数据库治理技术储备
配置中心:注册中心相关,包括Zookeeper、Etcd等
服务治理:服务化相关知识可以复用,如服务发现,熔断,限流,负载均衡,失效转移等
追踪监控:分布式调用链追踪,OpenTracing协议等,数据库以及应用状态相关指标收集和暴露
基础技术储备
性能调优JVM GC调优内存泄露,资源泄露排查
质量保证单元测试,整合测试,压力测试,疲劳测试,性能测试体系的搭建
写中间件理念:随时准备面向开源
1.保持视野的敏锐了解技术社区现状,优先考虑复用和融入,而非颠覆保证能被人快速上手
2.保持设计解耦技术模块与业务模块和环境相关,在设计时即保证解耦
3.随时保持代码精炼面向意图编程,代码随时准备开放面向社区,并具备高可读性