首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

快狗打车CTO沈剑:数据库架构一致性最佳实践

导语:大家好,很高兴你们可以在百忙之中点我的这篇文章,希望小编今天的文章能够给您带来惊喜和快乐、开心,如果文章您觉得还满意,请您关注小编多多转发文章分享一下吧!小编祝愿各位看官今天有个好心情哦,在此谢谢大家了。

本文根据沈剑在2018年10月18日【第十届中国系统架构师大会(SACC2018)】现场演讲内容整理而成。

讲师介绍:

沈剑,快狗打车CTO,互联网架构技术专家,“架构师之路”公众号作者。曾任百度高级工程师,58同城高级架构师,58同城技术委员会主席。2015年调至58到家任高级总监,技术委员会主席,负责基础架构,技术平台,运维安全,信息系统等后端技术体系搭建。现任快狗打车CTO,负责快狗打车技术体系的搭建,本质是技术人一枚。

本文摘要:

沈剑分享了快狗打车数据库架构的一致性实践,在一致性实践的过程中,能够体现快狗打车数据库架构的演进历程。从单库到多库再到高可用等等,包括在研究的过程中,每个阶段可能会碰到不同的问题,快狗打车是采用一些什么样的技术手段去解决这些问题?以快狗打车的实践跟大家做一些分享。

分享大纲:

主从不一致,优化实践

缓存不一致,优化实践

数据冗余不一致,优化实践

多库事务不一致,优化实践

总结

演讲正文:

快狗打车(原58速运)是一个创业型公司,技术架构、技术体系、数据库架构的变迁,和在座很多公司是很相近的,今天和大家聊一聊,我们在快狗打车数据库架构一致性方面碰到一些问题。

不一致的优化历程,也是数据库架构演进的过程

主线是我们的数据库架构变化的过程,在这个过程中,我列出了四个跟一致性相关的节点,主从会不一致、缓存会不一致、冗余数据会不一致、多库多实例会不一致。不一致的优化历程,也是我们数据库架构演进的一个过程。从单库到现在,有哪些坑在等着我们呢?

先看一下,最初的数据库架构,最早是这个样子的。那个时候没有什么微服务分层, web通过DAO访问一个单库数据库,最早我这么玩的。单库,它不具备什么高可用,高并发特性,扩展性也比较差。我相信很多创业公司初期也是这样。

单库最早会遇到什么样的瓶颈呢?在创业的时候,数据量变大了,并发量大了,业务变复杂了,整个系统的瓶颈最先出现在哪里?我的经验是数据库。数据库的瓶颈又会在哪里?我的经验是读。因为绝大部分的业务是读多写少的业务,读,最容易称为系统的瓶颈。

最早在数据库读扛不住的时候,最先想到的优化方式是什么?互联网公司都讲快,今天出问题,能不能明天后天给我搞定?最先想到的方案是什么,如何能快速扩充数据库的读性能呢?

加两个实例,主从同步,读写分离,这是创业型公司,当数据库读成为瓶颈的时候,最先想到的方案,快速扩充读性能。主从同步碰到的问题是什么?这就是本主题要讲的第一个问题,主从一致性的问题。

当数据量越来越多,吞吐量越来越大的时候,写到了主库,主库同步到从库,主从同步存在延时,在延时窗口期内,读写分离去读从库,就有可能读到一个旧数据。这个问题,我相信大家也会碰到。

对于这个问题,不少接业务的解法方案是,忍,有些业务如果对一致性的要求没这么高。但有没有优化方案呢?

这两个图是我们的两个常见的实践。

第一个是中间件,我们的服务层或者站点层不直接调数据库,通过一个中间层,去调数据库。中间层它能够知道哪一个库,哪一个表,哪一个KEY发生了写操作,如果说接下来的这一段时间(假设主从同步一秒钟完成),有读请求落到从库上,就会读到旧数据。那么此时,中间件就要将读请求,路由到主库上去,读新数据。

第二个是强制读主。第二个图,双主同步,强制读主有什么好处?第一解决了高可用问题,双主使用同一个VIP,一个主库如果挂了,另一个主库能随时顶上,保障高可用。第二避免了主从之间的不一致。

强制读主它带来的新的问题是什么呢?解决了一致性问题,但读性能扩展的问题又来了,主库抗读写,还是没有解决读性的扩大的问题。

除了增加从库,互联网公司还有一种常见的提升系统读性能的方式,缓存加服务化。抽象出服务层,向调用方屏蔽底层数据库的复杂性,屏蔽数据库的高可用的复杂性,屏蔽缓存的复杂性,对业务层提供服务。

服务化加缓存确实是提升系统读容量的架构方案。通过缓存来提升读性,又会遇到什么新的问题呢?用主从架构,有主从不一致问题;用缓存架构,当然也有缓存不一致的问题。只要你把同一份数据放在了多个地方,多个地方的修改有时间差,这个时间差就会有数据访问不一致的问题。

当我们出现数据库与缓存中的数据不一致的时候,我们怎么来解决?

首先来看一下为什么会不一致。缓存的常用玩法是“Cache Aside Pattern”。Cache Aside Pattern,旁路缓存,一般是怎么玩的?淘汰缓存,而不是更新缓存,这是Cache Aside Pattern的结论。

读写时序是什么样的?对于读请求有缓存,毫无争议的,先读缓存,如果数据命中我就直接返回,如果数据没有命中,读从库读写分离,把这个数据从从库里拿出,放到缓存里,这是读请求的一个流程。

对于写请求,Cache Aside Pattern的做法是,先写数据库,再淘汰缓存。在什么情况下会出现不一致?当并发量相对会比较高时,对于同一个KEY做了一个写操作,马上又来了一个读操作,会出现什么样的情况?先发生一个写操作,先更新到数据库,淘汰了Cache,马上又来了一个读操作,这个时候主从同步还没同步完成,先读缓存,缓存被刚刚的写操作已经淘汰掉了,又去读从库,把从库的脏数据拿过来放到缓存里去,不一致就出现。

高并发状态下,写后立即读的场景,容易出现脏数据入Cache。

大家发现没有,这里的数据不一致,比主从的数据不一致的情况更严重。主从不一致,只有一个主动同步时间差不一致,同步之后,从库就能读到新数据了。但是缓存与数据库的不一致,它会导致后续一直不一致,一旦脏数据入了缓存,脏数据会延续到下一个写发生的时候才会被淘汰掉,所以它其实更严重。

如何来解决呢?缓存和数据库的数据不一致,我们的两个实践:异步淘汰缓存,确保从库已经同步成功;设定超时时间,极限情况下有机会修正。

第一个,等从库已经完全同步成功,再去异步淘汰缓存?只要监听从库的binlog,从库binlog完成,一定是写操作执行完毕,此时再淘汰缓存,就能避免时间差。

第二个,就是如果允许Cache miss,不要将缓存过期时间设为永久,如果你设置为无限长的过期时间,就没有一个机会去修正不一致了。

随着业务的发展,除了流量的增加,我们要提升系统的读性能,我们要提升系统的数据库高可用,还会面临一个什么问题?对了,数据量会增大。我们业务数据量越来越大了,通常采用什么样的方式去解决?创业型公司,这两个方案应该是大家用得最多的。

第一个,分库。降低每个库,降低每个实例的数据量,这样就能够承载更多的数据。分库又带来什么新的问题?举了个例子,订单一个库,它有多个维度的查询,有订单ID的查询,有用户ID的查询,有司机ID的查询,一个库没有任何问题。

但分库以后,变成多个库以后,一旦用了一个维度分库,你会发现其他的维度的查询就要变成多个库了,是不是?

一般来说是通过用户的ID去分库,在订单ID里去放上分库因子,这样通过用户ID以及订单ID都能够定位到相关数据。但是对于司机ID就不同了,司机ID和用户ID是一个多对多的关系。一个用户他可能下了多个司机的单,一个司机接了多个用户的单,通过司机ID去查询,并不能一次性查询到所有的数据,同一个司机的订单一定是分布在多个库里。怎么办呢?此时最常用解决方案是,数据冗余。

我用一个存储元数据,用一个存储关系数据,元数据通过用户ID来分库,保证同一个用户的所有订单在一个库里。关系数据用司机ID来分库,保证同一个司机的所有订单在一个库里。同一份数据,由于它存在两个维度的查询,这两个维度查询都可以不夸库,而通过数据冗余来实现,这个在业内属于很常见的方案。

数据冗余,又会出现什么问题?一起来看一下。上面是应用,中间是服务,一个数据存在两个库里,一个库是通过用户ID分库,一个库是通过司机ID去分库,调用方来了一个请求,先要往第一份数据里写一个数据,再往另外一个库里写一个冗余数据。能保证冗余数据的一致性么?是不能够保证,这两个库同时写成功的,那怎么办呢?

这就是冗余数据的一致性问题。数据冗余数据的不一致优化,今天介绍三种方法,其实本质的方法论都是最终一致性。

第一个方案是扫全量。怎么发现冗余数据不一致?写个脚本,每天晚上跑,理论上A库里有的B库里面也有,一旦扫库发现怎么A库有B库里没有,就是出现不一致了,就要根据业务特性来做补偿。到底是将后一半补进去,还是把前一半删掉,跟业务特性相关,不过思路大致是这样的,一个异步的方式,最终来保证一致性。

第二个方案是扫增量。通过服务操作两个库,写成功第一个库写一条日志,写成功第二个库再写一条日志。这些日志里的就是每天改变的数据,每天不用扫描全量,只要扫描每天改变的数据就行了。如果扫描日志不匹配,就通过异步的方式修复,保证最终一致性。

第三个方式,比前两种方式更加实时。不写日志了,而是发消息。用一个消息组件,数据库正向表操作成功了,发一个消息,冗余表操作成功了,发另一个消息。用一个异步的服务去监听这两个消息,如果只有一条消息到达,就去数据库检测一致性,并用异步的方式来补偿。

最后是多实例多库,这也是解决数据量大的一个常见方案。它会带来什么样的不一致呢?这里有一个案例,下单的一个操作,可能有三个数据要修改,一个是余额的数据,我可能要扣减一些余额;一个是订单的数据,要新增一条订单;一个是流水的数据,要新增一条流水。原来是单库事务来保证一致性,现在数据量大了,变成多个库,余额是一个单独的实例,订单是一个单独的实例,流水是一个单独的实例,所以原来的一个事务,在多库状态下,就变成三个事务。

多实例,多库事务,不一致,怎么办?这一块我们有两个优化实践。

第一个是补偿事务,业内应该也经常用到补偿事务。

余额操作,正向的操作是扣减余额,补偿事务就是把余额加回来。

订单操作,正向的操作是新增订单,补偿事务就是把订单删除掉。

流水操作,正向的操作是新增流水,补偿事务就是把流水删除。

总之,补偿事务就是当你发现前面的事务执行失败的时候,要执行一个应用层的事务,回滚一个动作。

先细化的看一下三个事务是怎么执行的?第一个事务先执行再提交,第二个事务执行再提交,第三个事务执行再提交。事务的执行过程很慢,事务的提交过程很快。上图这个例子,可能执行时间200毫秒,提交时间几毫秒,什么时候会出现不一致呢?第一个事务提交成功之后,最后一个事务提交成功之前的中间,任何一个地方出现异常都会导致不一致。

优化其实也很简单,后置提交。第一个事务执行,第二个事务执行,第三个事务执行;第一个事务提交,第二个事务提交,第三个事务提交。什么时候会出现不一致呢?仍然是第一个事务提交成功之后,第三个事务提交成功之前的时间间隔,如果出现了,网络异常,服务器挂了,就会不一致。但是这个间隔就只有后面的两毫秒,所以整个不一致的概率是降低了百倍左右。

最后做一个简单的总结。根据我的经验,40分钟50分钟的一个技术分享,第二天能够记住的只有10%。如果只记住10%,那我希望大家能够记住这一页的内容,并希望自己的逻辑是清晰的。

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20181113A0Q8T700?refer=cp_1026
  • 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码

添加站长 进交流群

领取专属 10元无门槛券

私享最新 技术干货

扫码加入开发者社群
领券