网站技术互联网,技术小知识

站内搜索

关于大型网站技术演进的思考(九)--网站静态化处理--总述(1)

在存储瓶颈的开篇我提到像hao123这样的导航网站只要它部署的web服务器数量足够,它可以承载超大规模的并发访问量,如果是一个动态的网站,特别是使用到了数据库的网站是很难做到通过增加web服务器数量的方式来有效的增加网站并发访问能力的。但是现实情况是像淘宝、京东这样的大型动态网站在承担高并发的情况下任然能保证快速的响应,这其中有什么样的技术手段可以达到动态网站支撑高并发的场景了,这也许是每个做web开发的朋友都很感兴趣的问题,今天我将写一个新的系列来探讨下这个问题,希望我的经验和研究能给大多数人以启迪。

阅读:24 时间:2015-03-24 Other

我设计的网站的分布式架构

互联网的网站和大部分企业管理软件一样都是使用B/S架构模型,但是大型的公共网站B/S架构会更加复杂,对架构人员的要求更高,今天我想在自己博客里聊聊我设计的网站的B/S技术架构。

阅读:33 时间:2015-03-24 Other

关于大型网站技术演进的思考(八)--存储的瓶颈终篇(8)

在开始本篇主要内容前,我们一起看看下面的几张截图,首先是第一张图,如下图所示:

阅读:27 时间:2015-03-24 数据库

关于大型网站技术演进的思考(七)--存储的瓶颈(7)

本文开篇提个问题给大家,关系数据库的瓶颈有哪些?我想有些朋友看到这个问题肯定会说出自己平时开发中碰到了一个跟数据库有关的什么什么问题,然后如何解决的等等,这样的答案没问题,但是却没有代表性,如果出现了一个新的存储瓶颈问题,你在那个场景的处理经验可以套用在这个新问题上吗?这个真的很难说。

阅读:28 时间:2015-03-24 数据库

关于大型网站技术演进的思考(六)--存储的瓶颈(6)

在讲数据库水平拆分时候,我列出了水平拆分数据库需要解决的两个难题,它们分别是主键的设计问题和单表查询的问题,主键问题前文已经做了比较详细的讲述了,但是第二个问题我没有讲述,今天我将会讲讲如何解决数据表被水平拆分后的单表查询问题。

阅读:23 时间:2015-03-24 数据库

关于大型网站技术演进的思考(五)--存储的瓶颈(5)

上文里我遗留了两个问题,一个问题是数据库做了水平拆分以后,如果我们对主键的设计采取一种均匀分布的策略,那么它对于被水平拆分出的表后续的查询操作将有何种影响,第二个问题就是水平拆分的扩容问题。这两个问题在深入下去,本系列就越来越技术化了,可能最终很多朋友读完后还是没有找到解决实际问题的启迪,而且我觉得这些问题都是像BAT这样巨型互联网公司才会认真思考的,因此本篇我打算换个角度来阐述本文的后续内容。

阅读:25 时间:2015-03-24 数据库

关于大型网站技术演进的思考(四)--存储的瓶颈(4)

如果数据库需要进行水平拆分,这其实是一件很开心的事情,因为它代表公司的业务正在迅猛的增长,对于开发人员而言那就是有不尽的项目可以做,虽然会感觉很忙,但是人过的充实,心里也踏实。

阅读:33 时间:2015-03-24 数据库

关于大型网站技术演进的思考(三)--存储的瓶颈(3)

存储的瓶颈写到现在就要进入到深水区了,如果我们所做的网站已经到了做数据库垂直拆分和水平拆分的阶段,那么此时我们所面临的技术难度的挑战也会大大增强。

阅读:27 时间:2015-03-24 数据库

关于大型网站技术演进的思考(二)--存储的瓶颈(2)

暂时无法提供服务的含义,503还表达了网站服务端现在有问题但是以后可能会提供正常的服务,对http协议熟悉的人都知道,5开头的响应码表达了服务端出现了问题,在我们开发测试时候最为常见的是500错误,500代表的含义是服务端程序出现了错误导致网站无法正常提供服务,500通常是服务端异常和错误所致,如果生产系统里发现了500错误,那么只能说明网站存在逻辑性的错误,这往往是系统上线前的测试做的不到位所致。

阅读:18 时间:2015-03-24 数据库

关于大型网站技术演进的思考(一)--存储的瓶颈(1)

前不久公司请来了位互联网界的技术大牛跟我们做了一次大型网站架构的培训,两天12个小时信息量非常大,知识的广度和难度也非常大,培训完后我很难完整理出全部听到的知识,今天我换了个思路是回味这次培训,这个思路就是通过本人目前的经验和技术水平来思考下大型网站技术演进的过程。

阅读:18 时间:2015-03-24 数据库