16

新工作第四十八周

 3 years ago
source link: http://mp.weixin.qq.com/s?__biz=MzAwOTU4NzM5Ng%3D%3D&%3Bmid=2455771701&%3Bidx=1&%3Bsn=fbb75656a6d66e6256c1b3c5eece7800
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

1:SLB某个实例规格过小,峰值连接数超过了阈值导致限流,影响了用户访问;而这到是好的,如果峰值流量超过了购买的流量,则直接会中断服务。

流量非常昂贵,如果因为一些“非常态”峰值购买过高的带宽,那确实很浪费,为了解决这个问题,只有两个办法,CDN和减少接口请求。

2:CDN的好处就不用多说了,目前适合放入CDN的服务均已经部署完成了,虽然让系统的复杂度变高,但这是值得的。

如果动态接口也部署CDN,从理论上是可行的,但带来的开发、沟通、协调复杂度过高,轻易不建议使用。

3:减少流量的另外一个方法就是减少接口请求,这周对客户端开发有了一点体会。

大量的多线程并发,而且是瞬时的,这对服务器是一个考验。

另外客户端有时候做缓存并不是为了减少服务器端压力,而是为了体验,比如说显示用户文章数,首先从缓存中拿,但此时仍然会去请求接口,以便“纠正”文章数。

如果要真正减少接口请求数,又不影响用户体验,需要前后端紧密合作,这也会增加复杂度,对于大公司可能有一套标准,对于中小公司就只有不断的磨合,并没有银弹。

4:客户端大量的多线程请求让我思考两个问题。

第一个通过curl发现DNS解析时间有的时候挺长的,虽然客户端也有DNS缓存,但仍然要保障DNS的响应。

对于阿里云云解析服务来说,可以购买基础版或企业版服务,和免费的区别有几点,第一就是NS的域名不一致,说明可靠性更高;

第二就是线路解析更丰富,但前提取决于你确实部署了很多点;

第三就是DNS集群更多,通过dig看出NS也是一个域名,那么如何体现DNS集群节点呢?应该是local DNS智能选择的。

在DNS上能做的事情并不多,可以适当提高TTL时间,这样让DNS缓存时间更长,同时也体现了SLB的优势:DNS指向的SLB ip地址一般不会变。

5:HTTP/2

通过测试发现,三次握手和TLS交互占整个响应时间的70%,如果大量的多线程,网络消耗非常大的,客户端是否能够采用HTTP/2?一次连接多次并发请求?

6:容量规划

基于现有峰值流量做了一次容量规划。可以看出MySQL从库没有太大的压力;

主库已经很久没有启动过了,当时配置的pool size过低,总觉得是个隐患,可重启主库比重启从库相对危险的多,研究了一些文章,最后操作了,其实MySQL还是很稳定的。

Redis真的是大杀器,90%的公司可能要感谢它,qps支持能力太强劲了,唯一担心的就是容量,已经占用80%了,通过工具分析了下,发现有个prefix key非常大,优化后,瞬间可用容量30% 了。

PHP-FPM是另外一个需要评估的点,qps取决于程序响应能力,而相对于内存,CPU对于应用服务器更重要,以后可以购买8核/16G的服务器。

7:通过Prometheus观察服务,不过对于一些瞬时指标理解的还不透彻,未来要基于ELK做日志级别的分析。

8:发现有一台副库相对于其他服务器(同配置)慢查询较多,觉得很奇怪,做了下I/O测试,IOPS相对较低;而SSD盘IOPS则牛逼了好多,这说明磁盘IOPS和大内存对于MySQL非常重要。

为啥慢查询较多呢?并发更新没有太高,脏页比例并不高,调整了redo log大小,有所缓解,但这不是关键。

目前的感觉就是并发写多,持续并发读的情况下,从库慢查询可能会偏高,尤其第二点。

9:支撑能力评估

这一点和容量规划有点区别,容量规划是基于现有规模的评估,是对资源的评估。而支撑能力更多的要从业务角度去衡量。

真的很难做。一方面你要有更多的数据让你评估;另外要多角度评估,需要综合起来看,否则可能出现错误的判断;另外也要根据实际情况,不能想象。

但通过支撑能力评估,能发现一些问题,但如何通过20%的时间解决80%的问题?这是一门艺术。

10:如何理解负载和CPU利用率,如何找出CPU消耗过高的程序?大量的脚本运行是导致CPU过高的元凶,因为它一直在做事。

学习了很多。

11:Mysql怎么搞?隔离、隔离,还是隔离,基于MySQL5.7构建了一主多从,也尝试了GTID同步。

为核心服务购买了RDS,一切的一切基于重要级别和成本。

12:压力测试,基于单接口的压力测试很简单,但基于真实场景的压力测试很难,qps和并发我理解错了,持续的高并发可能会导致mysql慢查询变多,虽然其本身压力并不大。

13:数据库的备份、切换、集群架构、监控,最近有了一些新的收获。

14:微服务很流行,RPC和HTTP调用隔离了业务调用,但始终觉得业务层的代码复用应该先做好,网络调用还是很耗时的。

15:复杂度

隔离、隔离,基于域名的隔离,SLB可以多维度隔离,可惜SLB不能隔离不同业务的流量(对于单实例),是不是有点误入歧途了。系统应该是简单的,过于复杂会难于理解。

16:即使你不了解业务,也可以通过其他维度去衡量系统的支撑能力。另外欲速则不达,要有规划,坚持目标。

17:闺女今天算开学了,加油!!!我也要多关注,这才是大事。

18:看到大家做的直播服务,感觉不错,是一个比较成型的东西了,全民直播的时代就要来了。


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK