高并发网站架构设计笔记

所有的架构设计都离不开业务本身,所以在应用的时候需要有所取舍,为了不同阶段的发展,来研发升级不同的集群结构.但是,你的底层开发,是必须要在一开始就要想好你的架构的,以后的升级不必伤筋动骨.正所谓麻雀虽小,五脏俱全啦!

架构思想笔记

曾经有过几次架构的机会,一直都做的不是很理想,在前面写本博客的程序时就采用了一个很LOW的方法,但是又不得不接受它.现在的架构有所优化哈,这里把我一些优化的经历记录下来.

​ 首先,我是有学习过一些技术工程师的文章的,对于这篇文章提及到的关键字,都是有理论依据的,在写这篇文章的时候已经忘记是哪几篇了,这里只是顺便提及一下.

​ 对于一个可扩展性的系统来说,无论这个系统写的有多小,你都必须要注意以下几点:

  1. 分布式
  2. 稀缺资源的缓存
  3. 数据库优化
  4. 消息队列

一 分布式

​ 所有的操作都是围绕这一目标来展开的,我把承接用户访问的服务器理解为响应服务器.如果你的数据库,静态资源,缓存等都在响应服务器上的,你可能会出现什么情况呢?

  1. 用户访问速度慢
  2. 用户访问速度慢
  3. 用户访问速度慢

​ 当然你也可以怀疑是自己的应用代码写的太渣导致的慢,但你不可否认,用户访问的时候,是因为loading 你的css,js,图片等资源时耗费了大部分时间,如果能在开发工具里看到你的脚本确实够慢,你才回去看你的代码是否有问题.当然,你可能很肯定,你的代码没问题.对于代码问题,本文不想提及太多,因为代码问题是一个日积月累的过程.

​ 那么你需要考虑的就是怎么将你的应用的各种依赖给它鼓捣明白

二 静态的和耗费读写时间的稀缺资源

你应该明白,如果要实现分布式,一些静态资源是不能和响应服务器放在同一个地方的.例如:css,js,images,videos等.这些文件通常会被存放到一个单独的地方,如static.motkit.com,然后通过CDN缓存起来,这样,你的用户就可以以最快的速度拿到你的样式文件和特效文件以及图片资源等.

​ 同时,比较耗费性能的是你的数据库查询,解决数据库查询问题,永远是最重要的,目标就是不让你的用户接触你的数据库查询,除非他已经得到你的许可(客户需要下单并胜利在望的时候).其他的查询操作,你不应该让他进来查数据库.这里通常是用数据库缓存来搞定的,并且进一步通过Redis,memecach等来缓存起来.对于让用户胜利在望,我想应该要用到消息队列,这里不展开讲哈,我只想把这个事情说明白.

​ 你的用户的Session管理也会被从存储在缓存服务器中,你需要在分布式响应服务器里共用一套Session是吧,总不能让他每刷新一次,就极有可能让他重新登陆一次是吧.他通常用Redis解决,以后我再抽机会展开讲这块内容.

三 数据库优化

​ 数据库的性能很大程度上干扰了系统性能,主要是体现在读写操作上,一个嵌套查询就是几秒甚至几十秒.再有就是类似于查询10G以上的单表数据,你可以用分页来解决,但你不能减少数据库查询操作次数.

​ 这就有了数据库缓存,可以将一些数据对象缓存到专门的地方,来加快用户查询速度,与其说查询,还不如说是在缓存里直接获取.

​ 有了缓存,就必然会有数据不同步的问题,这个可以用计划任务(延迟任务)来解决这个问题哈,对于延迟任务/计划任务,这篇文章不会展开写,内容太多,再说我这技术能力也有限.

​ 读写分离在数据库性能优化当中是非常重要的手段之一,在流量稍微大点的网站就需要部署读写分离.

​ 数据库集群,在公司业务小的时候可以不集群,但是随之营业水平上升,必定会有集群产生.

四 消息队列

​ 在电商项目中,消息队列尤为重要,因为你要做秒杀功能的话,如果没有消息队列支撑,你的数据库可能会在几秒钟内崩溃.

​ 首先,你要模拟一遍用户行为,假设你的站点有一个商品正在秒杀,秒杀库存是1000个,你的活动力度又特别大,那么就会有超过1000个人来参与你的秒杀活动,2000个用户够不够?5000个用户够不够?10000个呢?

​ 好了,你应该明白我的意思了,只有1000个用户能顺利拿到订单并支付,其他人都是拿不到订单,付不了款的.那么剩下的人会怎么做呢?那就是重试,每一个重试都会查库存,这么多人查库存,你想象一下,需要多大一台机器才能搞定它呢?甚至这不是光靠堆机器就能解决问题的,你的硬盘读写瓶颈在这里.

​ 那么,消息队列就来了,如果没库存了,就查都不用查,直接就显示没货了,这样不更好?

这么说,可能不够形象,我特意画了一张图,这是我在拉钩APP的架构师课程里理解出来的一张图.它充分第体现了高性能网站的样子,蓝图,不管你用什么编程语言,最终呈现出来的都是长这个样子的.脱离了底层架构来讨论高并发,都是耍流氓.

终结:

​ 一个对用户友好,性能卓越的系统,一定不是某一个语言单独支撑起来的,他需要各种语言和软件共同支撑.例如静态资源就需要CDN来优化访问速度;数据库就需要数据库缓存和读写分离;响应服务器单台机器解决不了硬件并发性能,就需要用到nginx集群;因为集群,所以要用到分布式Redis来缓存Session.

​ 这上面的每一个部分都可以用一个集群来处理,如果业务量足够大的话.

​ 所有的架构设计都离不开业务本身,所以在应用的时候需要有所取舍,为了不同阶段的发展,来研发升级不同的集群结构.但是,你的底层开发,是必须要在一开始就要想好你的架构的,以后的升级不必伤筋动骨.正所谓麻雀虽小,五脏俱全啦!

本文参考了诸多高人的意见,如有不足之处,请自行加工整理.


参考文献

相关文章