本文转载自微信公众号「虞大胆的叽叽喳喳」,作者虞大胆。转载本文请联系虞大胆的叽叽喳喳公众号。
最近我们直播可能要邀请一个明星,据说带来的在线人数比较高。
听到这个事情,我的第一反应不是直播系统本身的压力,反而是整个系统的压力,因为有人看直播,必须注册、登陆、进入直播间,这些流量带来的压力不是很好评估。
解决复杂问题的第一步就是分解问题,所以可以先专注直播系统本身,至少要让它健壮的运行。
对于直播,分为两部分,核心推拉流用的第三方的,暂时忽略;第二部分就是一些辅助API接口(比如进入房间,在线用户列表),这些是需要重点衡量的。
直播系统API本身相对容易做容量评估,为什么呢?你把它当作一个封闭的系统单元,比如开一场直播,调用了那些接口,接口调用量都可以直接grep统计出来,也能找到峰值,注意这个峰值可以是单接口的峰值,也可以是汇总接口的峰值,第二个指标更有意义,可以统计出峰值对应的在线用户数,资源消耗量(流量,redis,mysql),从而进行容量预估。
各个接口之间的调用比例是多少呢?可以取平均值(这是我这次学习到的),比如在线用户接口平均每秒是10次,进入房间接口平均每秒1次,通过这种关系,大概明确了什么接口对系统的影响更大,什么接口响应时间较慢。
这种接口调用比例实际上对真实的压测非常有意义。
那为什么现在没有统计出呢?核心原因在于资源使用目前是耦合的,所以暂且抛开系统压测和容量预估部署,解决复杂问题最好的方法就是隔离、隔离。
隔离的好处是什么?互不影响;更方便的统计;进一步衡量系统的健壮性。
首先考虑web服务器,就是阿里云ECS,直播系统的高峰是可控的,比如知道那个明显要来了,也许高峰期可能就2小时,所以采用按量付费的ECS非常合适,1小时不到2元。
乘着这次机会重新安装了一台web服务器(包括所需要的软件),然后做了个镜像,再申请ECS的时候就可以直接选择这个现成的镜像,非常方便,如果不考虑现在更流行的docker&k8s,这种云服务的可扩展性也是让人很惊叹的。
当然这种方式不是说秒级就能扩容,还是有很多细节的问题,比如预先并不知道新申请服务器的ip地址,挂载到slb的时候,也要手动配置。
虽然阿里云也有云服务API(不用登陆控制台),可以通过程序控制ECS的启动,配置,但目前至少我们可以不采用,毕竟前提是我们知道直播高峰期什么时候来,可以提前做准备。
其次考虑SLB,这次把直播SLB也剥离出来了,原来我倾向购买包年包月的实例,有两点原因。
官方说包年包月峰值带宽更有保障。2:如果一个业务平时访问毕竟均匀,使用包年包月成本更低。
但我们业务突飞猛进,动不动就能一个峰值,而为了这个峰值,需要购买更高流量包(包年包月),确实比较耗费成本。
最终选择直播SLB购买按量付费,成本可控,而且非高峰期也可以回收,使用原有SLB,这个过程能够自动化就更好了。
然后是数据库,直播系统本身使用的数据存储量并不高,所以暂时没有使用阿里云RDS,使用自建且独立的mysql 5.7,不知道其他公司是如何的,从成本角度考虑,自建mysql和阿里云RDS可以并行存在。
最后就是Redis,隔离Redis也很简单,如果直播业务是将redis当缓存使用,或者redis数据也会同步到mysql,那么购买按量付费的redis也是比较合适的。
选择何种规格的redis,建议关注连接数,只是目前还没有找到峰值和redis连接数之间的关系。
对于高峰,首先要做压测,其次要做容量评估,接着是隔离,最后是应用层优化。
对于应用层优化要持续做,原因很简单,优化一小步,成本就会减少很多,系统的支撑能力就会变大。
遇到一个问题,我的第一反映就是先优化,本质上是没有错误的,但是优化的成本要小于优化的效果,至少别影响业务开发,经验告诉我们,在初期,优化的效果是很明显的。
三板斧:减少接口调用,数据缓存化,策略优化(结合需求)。
后面还会再写两篇,理理思路。