2016可以看做是“网络直播元年”，随着名人、品牌、网红的加入，一大批移动直播平台获得了长足的发展，其势头不亚于10年的“百团大战”，而红豆Live就在这个大背景下应运而生。它是微博子公司有信旗下的一款语音直播产品，旨在为微博大V和意见领袖提供一个知识分享和知识变现的平台。微博覆盖47个行业的230万垂直大V不仅仅给红豆Live的运营推广提供便利，也带来了对于创业团队巨大的峰值流量。在上线后20天，科普大V博物杂志红豆Live首播在线人数超2.5万，回放超15万;锤子M1发布会等直播同时在线人数8.2万，直播回放量更是接近30万;上线3个月后，两季问答挑战公益直播活动累计在线观看人数8000万，这些数据见证着红豆Live的成长，也给后台技术团队提出了更高的稳定性和性能要求，而彼时后台团队也只有区区3人。
我们目前后台技术团队的班底来自于微博，大多负责微博平台基础组件的研发。配置中心、分布式消息队列、分布式追踪系统、存储中间件等微博核心中间件的开发和维护大多由我们团队中的成员负责。相比于微博成熟的技术体系，创业团队由于人力资源紧缺、版本迭代快速等原因，在架构上通常具备以下特点：
1.架构基本以all-in-one方式开始，所有代码打包成一个大工程，减少开发和维护成本
2.使用成熟的第三方工具、框架和服务支撑业务的快速迭代，技术选型上激进但可控。
3.对于服务扩展性、柔性考虑不足，但会随着业务变化进行架构演进
这样的架构支撑下，且考虑服务器的成本，在系统性能上通常不会留有很大的buffer(比如会留1倍的buffer)，但当面对大型运营活动的大流量时，性能问题就会凸显了。
在2016年12月的两次问答挑战大型公益直播活动中，先后邀请姚晨、刘涛、欧阳娜娜、王丽坤等一众明星参与活动，带来了峰值单机接近4000qps的流量。活动中出现大量卡顿和接口访问失败的现象，让我们重新审视架构。
首先，我们分析了直播的业务特点：
1.峰值流量高，流量明星带来的峰值压力可能是平时的百倍
2.存在明显的热点。不仅个别直播间热点明显，个别接口热点也明显(比如获取直播间人数接口)
3.数据最终一致
在了解了业务特点之后，我们重新评估目前架构是否能支撑业务。在红豆Live开发之初即采用了服务化架构，如下图所示：
架构从monolithic architecture直接“跃进”到SOA architecture使我们在服务层面可以做到高扩展性，在架构层面理论上可以承担千万级的访问流量。于是我们从细节上深挖系统瓶颈，以期通过架构上的小修小补实现性能的提升。
监控
要做到了解系统瓶颈，首先需要搭建一套监控告警平台。我们采用成熟的解决方案：tcollector + opentsdb + graphana来解决接口请求监控的问题。
1.封装java、python的sdk在发送端合并并且打印监控日志到本机磁盘
2.tcollector收集本机日志并且发送到opentsdb存储
3.graphana做报表展示
在监控系统搭建过程中，我们需要做到以下四点：
1.埋点尽量透明，无侵入
2.编译期代码织入，减少性能损耗
3.可降级
4.日志收集与日志发送解耦
监控系统搭建起来之后，我们对于系统的运行情况和瓶颈有了更深刻的了解，并且在保证版本开发进度的同时，逐一确认解决方案并快速解决。
一、热点问题
从监控中我们首先看到的是接口的热点问题。在红豆Live中存在两个计数：在线人数和观看人数，这两个计数是多个计数的加和，存储在redis中。从访问接口分布来看主要有以下两个来源：
1.端上每个观看者进入后每隔3秒查询一次
2.定期查询所有直播间的观看数推送给微博，以在微博广场中展示
在运营活动中，此接口会产生5-6万qps对于redis的查询，几乎达到redis的性能上限。针对此，我们做了以下优化工作：
1.分拆读数服务，把它从资源、服务、负载均衡等各层面隔离出来，形成单独的服务池
2.增加读数的多级本地缓存，本地缓存基于Guava LoadingCache，监控本地缓存的命中率，并且实现缓存时间可配置。这样当面对更大的流量时，可以把流量挡在前面
3.只推送发生过人数变化的直播间人数给微博
经过优化后，redis访问量维持在6000-8000的水平线上，并且极大的提升了系统容错能力。
二、扩展性问题
从目前的架构来看，我们对于接入层、服务层、分布式队列、搜索服务和DB都可以做到横向扩展，但是缓存由于使用的是阿里云提供的服务，无法通过增加从库的方式进行横向扩展，因此只能做到scale up，而不能做到scale out。当大流量涌入时，我们无法对缓存做横向扩展，无疑只能看着系统性能衰减而无能为力。针对此，我们重新对缓存客户端进行了设计，增加了抗量缓存L1。之所以采用抗量缓存而不采用多缓存实例hash的方式，是因为缓存容量很小，多缓存实例会造成浪费，而抗量缓存则可以随时增减。
L1缓存的特点有以下几点：
1.可通过增加实例的方式无限扩展
2.异步回中L1，尽量和主缓存保持数据一致
3.过期时间短，以保证用户体验
重新设计后，缓存架构如下图所示，基本可以达到横向扩展的目的。
三、异步处理问题
红豆server在处理和订单支付相关的请求时多采用异步方式，例如当用户A给主播B送礼物时，会把送礼物作为一个消息发送到消息队列中，由消息处理程序来完成后续的支付、发货(送出礼物)逻辑。但是在异步处理逻辑中却存在着很大的性能问题。
原先的处理逻辑如下：
1.锁定A账户
2.对A账户进行减金币操作
3.锁定B账户
4.对B进行加金币操作
当礼物订单量增多时，会在消息队列中形成堆积;又由于不同的订单类型放在同一个队列中处理，就会形成交叉影响，严重影响用户体验。
针对此，我们采用以下两种方式优化：
1.根据订单类型拆分队列，避免交叉影响
2.减少对于账户处理中的锁操作，采用定期针对流水结算的方式计算收益，保证账户中收益的最终一致性
通过以上的优化，我们实现了当礼物订单增长几十倍时，系统的.99响应时间控制在200ms左右，礼物发送基本感觉不到延迟。虽然收益的计算存在一定的延迟，但从产品上增加提示后也基本可以满足业务需求。
小结
以上就是一个小的创业团队针对突发的峰值流量带来的系统架构上的优化总结。当然，当前系统架构肯定不是最好的，但是我们相信架构是改进来的，而不是设计出来的，随着系统流量的增涨，我们也会对架构做持续的优化和演进。
