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