高并发技巧-流量聚合和高并发写入处理技巧

这篇文章我将介绍对于写入流量高的处理技巧，并且介绍一款快手开源的很实用的用来做流量聚合的工具BufferTrigger。通过这篇文章的介绍，相信对于大多写流量（后面就称为写qps吧）高的业务场景都能找到解决方案。

读流量（qps）高的场景其实见的更多，比如常用的淘宝和抖音，大部分都是读场景，而写的流量相对读的流量整体要低不少。但是如果遇到做活动，比如电商促销秒杀；或者一些本身确实写流量高的场景，比如直播（点赞，收礼）等有什么好的解决方案呢，下面通过个人遇到的一些业务场景来介绍实际用到的解决方案以及使用的场景和局限性。

消息队列

使用消息队列进行流量削峰来解决写qps高的问题应该是最常见的解决方案，将每次的请求扔到消息队列，后续由消费者慢慢处理即可，使用消息队列能够自己控制qps和线程数，所以就能够缓解下游的压力了。

使用场景介绍

这里就举两个常见的例子

1. 电商秒杀：每次用户秒杀的结果虽然在页面展示了，实际上一般是把请求丢到了消息队列了，后续慢慢消费处理（db中库存的改动等）；
2. 直播间收礼：在一些大V开直播的时候，直播收礼的流量10W/s很正常，服务端需要对礼物进行归类和统计等处理，这显然也可以使用mq去异步处理；

注意事项

消息队列的处理异步处理的，所以对于需要及时响应处理结果的业务可能就不大适合了。当然，对于处理结果比较固定，比如就是返回成功（商城秒杀），然后交由消息队列处理并且保证处理成功的范畴，不在考虑范围。

设置mq的消费速度要评估好，保证不能打垮下游服务；同时对于不断产生消息的业务，也不能让消费速度赶不上生产速度，导致消息不断堆积，引爆队列，必要时要对下游进行适当的横向扩容。总之，要在性能和消费速度之间进行权衡，找到一个平衡点。

流量聚合-BufferTrigger

BufferTrigger引入

流量聚合简单来说就是把多次的请求整合为一个请求处理，显然只有在业务对单词的请求不敏感时并且能接受一定延迟时才能使用，比如直播间点赞，主播对单次点赞根本不敏感，直播间展示的赞数也不是实时的，完全可以对多次点赞进行聚合，最后再进行一些列判断再累计起来存放到db或缓存中，直播间从db或缓存中进行拉取。

那么这个聚合的工具需要