一个迅速发展创业公司的 RDS 重塑之路
|
副标题[/!--empirenews.page--]
《一个迅速发展创业公司的 RDS 重塑之路》要点： RDS 是关系型数据库服务.有赞为什么重新打造 RDS 东西?这要从四个角度去分析：背景、问题、发展、实现. 有赞四个发展阶段的问题首先,背景来说的话有赞是一家创业公司,它从 0 到 50 人团队的时候,业务相对而言还是比较单一的.这个时候的业务发展没有那么快.而到了 50-200 人阶段的时候,业务线非常的多,比如说微小店、微商城,再比如说分销的业务,这些业务线起来之后,流量是慢慢的缓增到 200-300 人阶段的时候,大量工程师在快速的涌入公司,并且设计量这个时候也在增长.到 300 人的时候不仅仅是流量的缓增,而且这个时候流量也满满地增长,这个是比较重要的. 这样四个阶段的背景下面产生什么样的问题呢? 在 0-50 人的时候,人员相对比较能 Hold 住 MySQL. 50-200 人阶段对数据库压力是比较大的,所以产生了读写分离的需求,因为单机 MySQL 压力是蛮高的. 而到 200-300 人不仅仅是流量的增加,而且是数据量的增加.对单一的垂直业务线而言本身数据量在 MySQL 是 Hold 不住的. 等到 300 人 + 的时候全部业务线全面开花,包括业务人员,开发人员很多 DDL 产生,流程会变得很重,这都是很典型的创业公司的问题. 技术栈的发展针对这些问题我们跟互联网公司差不多是一样的,首先它的发展而言对 MySQL 而言是单接使用率,然后到很典型使用应用程序,主动的去读或者是写 Master. 到第三阶段读写分离,这里有一个背景是说我们的业务是基于 PSP 原始线.所以当流量上来的时候,在 MySQL 中间一层加像 360 的一个开源组件 Altas.后面一个阶段,引入阿里巴巴的一个开源的带 Sharding 功能的方案 Cobar. 介绍一下这两个组件的区别和方案的对比. 360 开源组件 Altas 满足了读写分离的需求,但是在电商领域或者更严格要求 ACID 的金融领域来说的话事务性要求很高的,这点是短板；不过它做了更好的运维上面的上线、下线 MySQL 的控制.而阿里巴巴的开源组件 Cobar 是简单的对 MySQL 做一些 Sharding.这两个架构本身而言对有赞来说的话是经历了比较长的一个时间,直到我后来加入之后,我把这些问题梳理了一下,这些问题主要会产生线上的故障非常多,即便是引入了 360 或者阿里巴巴的架构实现来说的话还是有很多的问题.所以我们进行了改造,变成了 RDS-Proxy. 重塑,剖析 RDS-Proxy本身 RDS 不是一开始就有的.这个是 Proxy 的一个雏形,为了去掉 RDS 和 kober,我们在 kober 上进行了改造,所以 Proxy 是一个中间基层,所以上下协议都是通过 MySQL 协议来访问的. 在 Proxy 上我们增加了很多的功能,比如读写分离,还增加了 MySQL 的权重,原先是没有的.而 ConnPool 也做了大量改造,主要是增强了它的连接数的复用性.原来 Kober 和那个的连接池用的是 IP+Pool 再加 MySQL 数据库的 Sgam.而我们改造后是共同承载非常多的 Sharding.这个 BIO 和 NIO 是比较大的改造,本身这个是非常重要的一点,无论是哪个方案,对于 MySQL 而言,它的 IO 是同步的协议在 IO 上很消耗性能.所以我们加前端的连接和后端的连接改成 NIO.这样的话就可以释放出 Proxy 上大量的内存.这个改造后我们就大量的提升了线上的性能,包括 Plos 的性能. 除了性能的改造之外我们还做了一些类似 FastFailed 的机制,对于 RDS-Proxy 改造后我们形成了这样的功能,就是前面所说的几点,ShardingFuction 增强,很重要的一点是 BIO 改造成了 NIO,无论是前置的连接和后置的连接都进行了改造,而 FastFailed 是增加了垄断的机制.通过这些改造后大家会不会有疑问,说增加了这么多功能它的性能会下降,其实不然.实际上我们通过改造代码量增加了,但是性能是提高了非常多的.首先我们在这样的测试场景下面,我们的背景使在 E5-2630 24CPU 上,千兆网卡打满了,Proxy 本身会气动 8×24 线程.而实际测的数据如屏幕上显示的,较以前的性能来说有 30% 的提高,140K QPS. 做了这么多性能对于稳定性有什么样的效果呢?我们由原来一个季度里会有 1-3 次的故障,而且是全站故障,改造后变成了 0 个.我们现在目前改造之后是没有全站故障的,因为 MySQL 的访问,Proxy 的访问所导致的. 说了这么多,我们做了哪些功能?我举个简单的例子讲一下如何实现的,下面可能会比较烧脑,因为有一些代码,不太适合在开场或者热身的阶段,所以举个比较简单的事情.读写分离,原来是没有读写分析的,所以对静态类,这块是新加的功能,我先讲一下总体的功能.MySQL Data Note 里会使用到 Channl,每个 Channl 是去执行 SQL 语句的.本身 MySQL 会使用到 Sleef,每个请求用一个连接,或者多个请求复用一个连接.原来没有 Sleef 要求,我进行了改造,并且进行了检测是否可用.对于前置的连接来说的话进行判断是否进行读写分离.而对于读写分离我们是不愿意让业务上层去做太多改造所以用了 MySQL Fent,然后再做路由,去拿到后端的路由之后,然后决定是选择 Master 还是最底下的哪个 Sleef.最终这样的改造之后够可以满足到读写分离功能. 即便是做了这么多性能跟稳定性改造之后,其实还是有很多的问题.尤其是在 300 人的团队以上,这个时候团队里的技能是参差不齐的,尤其是有多的业务线,有很多的研发,有很多的流量,而这些引发出每一天做 DDL 的变更会很多.而在 DDL 的变更,像在一个集群数量大的时候,每个分片都要做对接,引发的故障也会多一些.并且研发人员多跟 DBA 交流和交互时间效率也会变得很低.并且业务开发人员他的 SQL 技能是跟不上,比如说覆盖索引,组合索引,MySQL 紧密索引,都没有什么概念,在技能没有跟上的情况下面,对于生产系统是一个非常大的挑战.并且 MySQL 本身也会有 Feel,Master 要挂掉,在这个时候会频繁发生 MySQL HA.而对 MySQLHA 是灾难性事情,数据是很难保持一致.所以在退化数据的时候,在退化的过程中数据的一致性是非常难以保证.所以在这样的问题下面,我们单纯的 RDS 功能增加有如下的,对 Proxy 的改造,增加了 DDL 支持工作流,让每个研发人员能够在同一个平台提交 DDL,并且帮助 DBA 节省他熬夜的工作时间,能够提升他自己的工作效率,这个是比较重要的.第三,对 MySQLHA 的一些改造.
讲 RDS 结构之前先一下 RDS 模块.它的模块如图. （编辑：济源站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
