系统设计篇(三) -- 怎么设计高并发的服务(一)

高并发，高可用是服务端开发经常听到的词汇，在互联网应用中，随着用户的增加，后台服务需满足承载正常使用系统功能的用户数量。但是单机承载能力是有限的，因此通过多服务去支撑业务是必然的。但是不是所有业务都能通过简单的多服务扩展去解决，中间转换的过程会有很多问题，很多高并发服务的诞生并不是一蹴而就的，都是随着业务的扩展慢慢提高的，不同的场景遇到的问题也不一样，因此，在设计系统时需要因地制宜，根据当前业务场景去设计合适的架构。

水平扩展 OR 垂直扩展

网上听的最多的就是这两个词，垂直扩展好理解，就是提升单体服务的性能，即可以从机器硬件方面提升，也可以从程序优化方面来提升。而至于水平扩展，对于无状态的服务来说确实是解决高并发的利器，有人会觉得水平扩展可以解决所有高并发的问题，这貌似不怎么确切。后台大部分业务处理最终都要落实到数据上，而数据库IO瓶颈又限制了服务扩展的规模。

有人会说，可以将数据库也进行水平扩展，通过一致性哈希等负载均衡方式来对数据集访问，但是数据库水平扩展又会引入很多问题，比如跨库查询数据，跨表聚合操作，数据库扩容，怎么容灾备份等，如果采用多个副本集，又会引来数据一致性的问题。多个副本集，以哪个副本集为准呢，如果副本集数据不一致，又以谁为准呢。如果要保证强一致，采取多阶段提交的方案，又会引来分布式事务问题，分布式事务对业务影响很大，因为在高并发场景中对延迟十分敏感，两阶段提交在一般场景可能不会出现问题，但是在高并发场景中，超时问题会经常出现，在得不到所有节点确认时会阻塞当前业务，这样会造成服务雪崩。

一个很经典的方案是采用异步写的方式，在高并发场景一个很常见的场景就是某个时刻流量异常高，比如双11秒杀活动，又或者在交易系统中某波行情，或者微博服务某个热点事件，这个时刻并发量异常高，这样造成后台服务大量请求超时，影响用户体验。对于这些场景，服务端的任何请求都不能做同步等待，都由异步操作去代替，上游服务处理完请求后抛到mq中，下游服务按照服务本身的任务处理能力进行消费，这样可以将某个时刻大量的请求进行削峰，保证服务的可用性。

缓存不是真正的银弹

很多高并发教程中都有提到过通过缓存去减少对数据库读写的压力，这句话是没有错的，但是换句话来说，缓存或许是数据库性能不佳的遮羞布。为什么这么说，缓存本质上是由于对数据库访问开销比较大而引入的。缓存并不是每个场景都能利用，如果引入缓存，那么也就引入了缓存和数据库怎么保证一致的问题。对于读请求，都好说，如果存在写请求，那么怎么保证缓存和数据库都双写一致呢，可能很多博客都有说到最佳方案是写DB，然后重新刷新缓存，那么如果写的频率很频繁呢，那么引入缓存就没有什么意义了。所以说，缓存并不是适合所有场景，比较适合一些读多写少的场景，或者不需要保证数据强一致的场景。

负载均衡

负载均衡是一种把流量均摊到各个服务的方式，通过负载均衡可以解决单服务或者单数据库负载过重的问题。一般来说，负载均衡有随机，轮询，加权轮询，哈希等方式。这些方式各有特点，比如随机，轮询和加权轮询，适合无状态的请求，任何服务处理这个请求都不影响结果。而哈希的方式对于无状态的请求也可以使用这种方式，但是也常用在有状态的请求中，比如对于数据库请求，不同的key散列在不同的数据库内。哈希方式有个特点就是会把数据打散，比如有多个redis节点，不同的key散在不同的redis上，但是如果我们有访问某个范围的key的需求，那么需要从多个节点获取，这样也很大伤脑筋。

所以在做数据库负载均衡的场景，不一定通过一致性哈希这种方式去做，需要根据业务的场景，比如时间，把某个时间范围的key散在一台服务；或者用户ID的范围等等，这样有个好处就是在增删节点时，不用做数据迁移，比如增加一个节点，如果通过一致性哈希，数据需要重新散列到新增的节点，但是如果通过类似range的方式，只需要把新的range分配到新的节点上就行了，不需要数据迁移造成节点暂时的不可用。

更多干货请关注微信号: 黑客的成长秘籍