桥 网站建设,wordpress中文版和英文版,php 网站 项目,什么平台首届阿里巴巴中间件技术峰会上#xff0c;阿里巴巴数据库资深专家何登成带来“AliSQL 引领开源技术变革之路”的演讲#xff0c;本文从回顾AliSQL发展史开始谈起#xff0c;接着分析了X-KV接口的好处#xff0c;最后着重分享了X-Cluster——AliSQL集群解决方案。 视频回顾 … 首届阿里巴巴中间件技术峰会上阿里巴巴数据库资深专家何登成带来“AliSQL 引领开源技术变革之路”的演讲本文从回顾AliSQL发展史开始谈起接着分析了X-KV接口的好处最后着重分享了X-Cluster——AliSQL集群解决方案。 视频回顾 以下是精彩内容整理 AliSQL发展历史简要回顾 为了去IOE从2010年我们选择Alibaba的MySQL分支AliSQL。 我们为什么发展一个MySQL分支呢最主要的思考还是在于生态当我们去选择开源数据库时我们会发现MySQL的整个生态、社区对于其它数据库来说是庞大的。我们发展MySQL开源分支是因为开源数据库在Alibaba体量下还是会碰到许多问题比如性能、功能和可运维性我们都作了相应优化。 在20102016期间我们做了100 项的优化包括bug 修复、功能增强、性能突破和可运维性的增强目前为止ALiSQL很多的新功能都被吸收到了开源数据库中。 图为AliSQL精简架构。我们在各个核心模块都做了改进比如Binlog、Read View等等。 功能和可运维增强也有很多改进我们不仅仅是在使用而是真正做了很多创新这些创新我们也会回馈给社区。 X-KV高性能K-V接口 X-KV是AliSQL高性能K-V接口InnoDB Memcached Plugin的扩展。 为什么需要X-KV左图是比较经典的部署有前端的用户请求、数据库数据库扩展性能时会在数据库和应用层之间加cache访问频率比较高的放到缓存和内存中用缓存区域查询问题是目前通用的解决方案但它不一定是最好的。那么我们如何保证数据和缓存的数据一致性呢我们探索从KV接口直接访问存储引擎中的数据这样可以绕过MySQL Server层的很多复杂逻辑比如Parse、Optimize、Execute和数据的转换、投影等。 X-KV的具体优化如下 我们将Data Type支持能力丰富了不光支持Float/Double、Integer、Decimal还包括DateTime、Char/Varchar、Custom Format。 用KV访问数据支持的接口比较有限我们在功能上也做了增强比如Multi get from multi tablesNon-unique indexcomposite indexes prefix search能够覆盖更多的场景。 X-KV新协议。InnoDB Memcached Plugin存在一些问题通过指定delimiter来区分每一列delimiter如何选择NULL和空值无法区分NULL 空。 X-KV新协议将以上问题解决了我们将返回的FieldMeta Info Data,加Meta Info来描述返回数据Meta Info有Version|Count|Length1|Length2|Length3… 可运维性优化。官方设计不考虑太多运维性导致InnoDB Memcached Plugin存在一些问题比如表结构变更后如何使得KV接口能够无缝的切换到新的schema 原有的plugin uninstall -install 方式对业务有较大影响。X-KV通过扩充Container表支持了在线的KV配置变更通过版本号来控制新旧版本的schema配置并自动重新加载。 性能优化。 0 我们模拟阿里的交易数据库上的Query请求做了验证相对于走SQL我们提升了5倍左右的性能。 X-ClusterAliSQL集群解决方案 为什么做X-Cluster呢 1. 首先是数据一致性的问题。传统的数据库都是主备的异步复制异步复制带来的是数据质量问题官方为了解决问题提出半同步复制但半同步复制过段时间会降级。所以它们都很难百分百保证数据质量。 2. 持续高可用问题。当我们搭建完MySQL主备后主备本身不会做切换不会做高可用真正的高可用是在主备之外使用一个外部组件比如基于zookeeper的HA来提供高可用功能。 3. 区域化/全球化部署问题。过去几年我们分享最多的是异地双活和异地多活我们要做到真正多城市多活高可用需要集群能耗跨城市部署跨国际部署。 4. 上下游生态联动。我们的数据库不仅仅作数据存取下游还要给其他系统作消费。 能不能用一种技术尝试解决掉这些问题呢这是我们做X-Cluster的初衷。 我们的设计目标是 一体化架构运维友好 极致性能同城三副本相对于单机性能下降在10%以内 可异地部署异地部署延时增加但是保持高吞吐 稳定性网络抖动高容忍性 兼容性对原有生态100%兼容 我们交付出一个AliSQL集群化的解决方案将分布式一致性协议Paxos引入到AliSQL上我们可以去组件一个AliSQL真正的集群通过Paxos实现日志的强同步实现自动化选主。 X-Cluster核心组件X-PaxosX-Paxos就是高性能分布式一致性算法。 X-Cluster核心技术 Batching Pipelining 如何实现再有网络延时尤其有异地网络延时、长延时、短延时以及不同网络条件下怎么样去做高性能真正与单机性能几乎持平我们使用了BatchingPipelining。 Pipelining是当一批往follower发送时follower返回之前能不能把下一批在leader上已经完成的事务再发出去这样就会同时有多批事务从leader等待follower达成多数派这就是所谓的Pipelining。原来Batching时是一次只能发一批等应答后再发下一批每一批至少会有一个网络的RTTPipelining好处是在第一批没有应答前就可以发送第二批··· 引入Pipelining就会带来乱序导致日志空洞会出现乱序接收。Paxos可以作乱序确认乱序确认的好处是如果有日志空洞任意两个副本达成多数派都认为事务提交成功。每一个follower上都有空洞但是将两个follower拼在一起它是一个完整的日志流。 Locality Aware Content Distribution 有了Paxos之后多少副本都可以。为了解决Leader出口网络降低跨Region长传链路带宽我们在跨Region时使follower可以连在follower上用级联的方式去复制。 日志实现 还有我们做了一体化日志插件式X-Paxos的日志归一化的ConsensusLog代替Binlog和RelayLog全局统一的Log Index。 Asynchronously Commit 我们还将工作线程和提交线程异步化工作线程只负责处理事务提交之外的用户请求在用户发送提交请求后工作线程将事务推入提交等待队列后就继续处理下一个用户请求。而提交等待队列的中的事务由另外一批线程来负责处理这样能够充分解放工作线程减少线程的等待提高高延时下的吞吐性能。 X-Cluster: vs MySQL Group Replication 我们与MySQL Group Replication对比做了简单的性能测试。可以看出INSERT同城比官方好两倍性能延时要小很多30ms 网络延时的部署下我们仍旧能够达到五万多延时只有官方的三分之一性能是五倍。 X-Cluster生态 我们面临的问题很多比如备份、日志订阅、只读节点等所以我们要超越数据一致性和持续可用Paxos关联的东西有很多。 持续备份 原有MySQL备份逻辑是定期备份Binlog文件RPO一般比较大例如大于5分钟备份跟MySQL的数据一致性保障困难。 X-Cluster可以解决备份的一些不便之处备份节点作为X-Cluster的一个Learner节点实时推送X-Cluster上达成多数派的日志RPO 1秒由于备份的一定是达成多数派的日志因此无数据一致性问题。 自动化高可用 原有MySQL高可用方案外部组件依赖ADHA、ZK。而X-Cluster自动化高可用Client、Server一体化Client也是数据库一个learner节点它需要消费成员变更日志成员变更日志达成多数派后推给learner节点Driver就会知道主备发生切换可以直接连新leader没有外部组件依赖达到自动化高可用。 自动化增量日志消费 原有MySQL下游日志消费准实时消费MySQL产生的日志问题之一是数据一致性问题之二是数据库主备切换与下游消费端的联动。 X-Cluster自动化增量日志消费日志消费节点作为X-Cluster的Learner节点只消费达成多数派的日志保证数据一致性X-Cluster自动选主新Leader自动向日志消费节点推送新日志彻底解决联动问题。 区域化/全球化部署 按需增加Learner节点增加读能力但是不会带来强同步开销 按需增加Log节点Log节点只有日志没有数据Log节点可参与选主但是没有新增存储开销。低成本节点3节点X-Cluster 2节点MySQL主备。 权重化体系可以指定节点选主权重控制每个节点的选主优先级。 X-Cluster实战总结 一路走来我们并不是一帆风顺也踩过很多坑比如 异常处理硬件异常网络异常Leader Stickiness Batching Pipelining极大事务极小事务不同网络时延下的Batching/Pipelining策略网络异常情况下的Batching/Pipelining策略 全球化部署下的优化权重体系、热点带来的影响
