一起看看高并发解决方案

今天我们得空看看高流量服务的系统架构应该如何设计，才能扛得住突发事件带来的瞬间高峰流量。

 

在像微博这样的媒体平台中，采用缓存集群模式进行设计是最合适的，因为用户在微博上的诉求主要就是查看获取相关信息。缓存集群是什么呢？字面意思，承担缓存作用的服务按集群方式进行部署。一般来说，我们的数据是存储在数据库的，当用户访问服务时，用户通过后端请求数据库数据，最害怕的就是出现热Key、大Value情况。

 

所谓热Key就是某个值瞬间被上万甚至十万百万个用户请求，比如双11时，某个爆款商品就会出现上千上万人查看抢购，鹿晗关晓彤公布恋情时出现上十万百万个用户请求访问该条消息。所谓大Value就是某个Key对应的Value特别大，导致在获取Value值的时候很慢，甚至故障。

 

如果对于所有的数据我们都用数据库进行存储，当数据量大时，就需要采取读写分离+分库分表了，也就是说把读数据请求、写数据请求分别发向不同的数据库服务器，对于某个不断增加的数值，比如用户评论，拆分在不同的数据表里。这样做也能解决用户访问服务问题，但就是贵啊。热点事件是突发性质的，我们不知道明星什么时候就在一起了？什么时候又分手了？也不知道暴雨什么时候就来了？如果平时就按照突发情况的要求准备多台数据库服务器，太奢侈了。

 

不要慌，我们可以有缓存集群的方案呀。将一些平时变动不大的数据都放在缓存里，用户大量查询某个数据的时候就从这里面获取，就好了。对于缓存集群，我们使用redis、memcached数据库进行搭建即可。整体系统的架构就变成如下所示了，业务系统集群从缓存集群里读取数据，在数据库集群里写入数据，解决了突然而来的高并发和成本问题。

 

 

除了有缓存集群的兜底方案之外，我们还可以从技术上做一些预防。比如通过流式计算如storm、flink来进行实时数据访问次数的统计。如果在短时间内，某条数据的访问次数突然爆增，超过指定的阈值，那么就可以判定为是热点数据，然后把这条热点数据加入到缓存集群中，如果该数据的访问继续爆增，自然也不用担心扛不住的问题，因为都去访问缓存集群的数据了呀。

 

 

最后，针对高并发我们还可以增加熔断限流保护机制。每个系统上线时，我们都会去做压力测试，了解整个系统的瓶颈点是多少？假设通过压力测试发现集群部署模式下，系统最多承受10万个请求，总共有100台服务器进行部署，均摊下来每个服务器最多能接受的请求不超过1000次，如果有第1001个用户访问时，就直接返回报错信息，让用户进行重试。这种方式虽然用户体验不是特别友好，但是系统却不会出错，也保障了前面1000个用户的使用体验。当下的淘宝、天猫、京东等电商网站大部分采取的便是此类的熔断限流机制。

 

高并发解决方案，我们介绍了缓存集群模式、流式计算技术进行预防、熔断限流保护机制，具体在系统里采取哪种机制，可根据实际情况而定噢。