您当前的位置:首页 > 在线订单

高并发和高性能系统中数据一致性问题和应对

  读过前面一篇文章《系统架构升级之道,关注关键服务依赖》就知道,我们的应用系统中的关键服务绝大部分都会是对数据库的依赖。

  可是,随着系统访问量、数据量的不断增长,数据库出现多个服务器,又出现缓存服务,又要拆分数据库,还要分拆到不同的子应用等等。

  2 应用服务器验证用户信息、订单信息、库存信息等等,然后将这个订单发送到订单消息队列——消息队列

  3 订单处理服务器从消息队列中拿到新订单,接下来的处理,可能做的数据操作有:

  上面的数据处理中,涉及到的数据有:订单数据、商品数据、商家数据、支付数据、用户数据。

  涉及到的应用和服务有:前端应用系统,消息队列,后端应用系统,数据库,缓存,甚至订单、商品、商家、支付、用户可能都是独立的子应用。

  这时候,只需要注意数据库更新的一致性就好了,比较容易想到的应对方法,就是用数据库事务来保证。

  如果这些数据不只是一份数据库,还有缓存中一份,又要考虑缓存数据的更新,所以问题还是复杂了。

  本来一个订单处理,如果不考虑数据一致性问题,数据库写入/更新5~10次,缓存写入/更新5~10次,整个过程应该在10ms内完成。

  但是加上数据库事务之后,会把这些操作中涉及到的几个表都加锁,意味着数据的读、写都串行化了,整个应用系统的并发能力急剧下降。

  当然,因为这里引入缓存,对数据库的依赖会减少很多,而且还有从库可以提供读的服务,应用系统的访问并发能力不至于下降太多。

  但这些代价在交易处理中是难以避免的,为了解决数据一致性问题,牺牲的是订单处理的并发能力。

  对于大部分商城、网站,订单并发量也不高,这类问题不太常发生,所以也就这么过去了。

  那么要在这么多的子应用、大量的数据库、缓存服务中保持数据一致性又要怎么做呢?

  2 每个子应用各自要保证自己的数据更新一致性(异常处理、重试、二次检查等方法同上)

  正因如此,大部分的分布式系统,大部分应用,是没有做到数据一致性,哪怕是弱一致性。

  比如:论坛里面发帖,要更新10份左右的数据,出现脏数据是常有的,这就是没有做到数据一致性。

  一个每秒钟上百万请求的应用系统能不能分拆为1000个每秒钟1000请求的独立集群呢?

  一个上百万的商家、商品、订单库,能不能分拆为1000个只有1000个商家、商品、订单的子库呢?

  上面的订单、库存、商家、支付、用户几个数据,核心数据只有订单,其他的几个数据完全可以从订单数据推导出来,减少订单处理中的一致性要求。

  解决数据一致性问题,现在还没有太好的方案,即经济实惠,又效果显著的方案,希望有大神可以造出来吧。

  在实战课程 《PHP秒杀系统 高并发高性能的极致挑战》中,也是针对这类高并发的业务场景做了特定的性能优化以及分布式方案,大家可以参考学习。

来顶一下
近回首页
返回首页
一周人气文章排行榜
  • 1
  • 2
  • 3
  • 4
  • 5
  • 1
  • 2
  • 3
  • 4
  • 5
  • 1
  • 2
  • 3
  • 4
  • 5
一周推荐文章排行榜
  • 1
  • 2
  • 3
  • 4
  • 5
  • 1
  • 2
  • 3
  • 4
  • 5
  • 1
  • 2
  • 3
  • 4
  • 5

网站简介版权所有