Category: Javascript /Jquery / Bootstrap / Web

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

如果数据库需要进行水平拆分,这其实是一件很开心的事情,因为它代表公司的业务正在迅猛的增长,对于开发人员而言那就是有不尽的项目可以做,虽然会感觉很忙,但是人过的充实,心里也踏实。   数据库水平拆分简单说来就是先将原数据库里的一张表在做垂直拆分出来放置在单独的数据库和单独的表里后更进一步的把本来是一个整体的表进一步拆分成多张表,每一张表都用独立的数据库进行存储。 当表被水平拆分后,原数据表成为了一个逻辑的概念,而这个逻辑表的业务含义需要多张物理表协同完成,因此数据库的表被水平拆分后,那么我们对这张表的操作 已经超出了数据库本身提供给我们现有的手段,换句话说我们对表的操作会超出数据库本身所拥有的处理能力,这个时候我就需要设计相关的方案来弥补数据库缺失 的能力,这就是数据库水平拆分最大的技术难点所在。 数据库的 水平拆分是数据库垂直拆分的升级版,它和垂直拆分更像继承机制里的父子关系,因此水平拆分后,垂直拆分所遇到的join查询的问题以及分布式事务的问题任 然存在,由于表被物理拆解增加了逻辑表的维度,这也给垂直拆分里碰到的两个难题增加了更多的维度,因此水平拆分里join查询的问题和分布式事务会变得更 加复杂。水平拆分除了垂直拆分两个难题外,它还会产生新的技术难题,这些难题具体如下:   难题一:数据库的表被水平拆分后,该表的主键设计会变得十分困难;   难题二:原来单表的查询逻辑会面临挑战。 在准备本篇文章时候,我看到一些资料里还提到了一些难题,这些难题是:   难题三:水平拆分表后,外键的设计也会变得十分困难;   难题四:这个难题是针对数据的新增操作的,大致的意思是,我们到底按什么规则把需要存储的数据存储在拆分出的那个具体的物理数据表里。 难题三的 问题,我在上篇已经给出了解答,这里我进行一定的补充,其实外键问题在垂直拆分就已经存在,不过在讲垂直拆分时候我们没有讲到这个问题,这主要是我设定了 一个前提,就是数据表在最原始的数据建模阶段就要抛弃所有外键的设计,并将外键的逻辑抛给服务层去完成,我们要尽全力减轻数据库承担的运算压力,其实除了 减轻数据库运算压力外,我们还要将作为存储原子的表保持相对的独立性,互不关联,那么要做到这点最直接的办法就是去掉表与表之间关联的象征:外键,这样我… Read More

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

上文里我遗留了两个问题,一个问题是数据库做了水平拆分以后,如果我们对主键的设计采取一种均匀分布的策略,那么它对于被水平拆分出的表后续的查询操作 将有何种影响,第二个问题就是水平拆分的扩容问题。这两个问题在深入下去,本系列就越来越技术化了,可能最终很多朋友读完后还是没有找到解决实际问题的启 迪,而且我觉得这些问题都是像BAT这样巨型互联网公司才会认真思考的,因此本篇我打算换个角度来阐述本文的后续内容。   这里我们 首先要明确一个问题,到底是什么因素促使我们去做数据库的垂直拆分和水平拆分的呢?答案很简单就是业务发展的需求,前文里的水平拆分技术方案基本都是抛弃 千变万化的业务规则的限制,尽量将水平拆分的问题归为一个简单的技术实现方案,而纯技术手段时常是看起来很美,但是到了面对现实问题时候,常常会变得那么 苍白和无力。   水平拆分 的难题里我还有个难题没有讲述,就是水平拆分后对查询操作的影响,特别是对单表查询的影响,这点估计也是大伙最为关心的问题,今天我不在延着水平拆分的技 术手段演进是阐述上文的遗留问题,而是我要把前面提到的技术手段和一些典型场景结合起来探讨如何解决网站存储的瓶颈问题。   前文中我总结过一个解决存储瓶颈的脉络,具体如下:   单库数据库–>数据库读写分离–>缓存技术–>搜索技术–>数据的垂直拆分–>数据的水平拆分   这个脉络给一些朋友产生了误解,就是认为这个过程应该是个串行的过程,其实在实际的场景下这个过程往往是并行的,但是里面有一个元素应该是串行的或者说思考时候有个先后问题,那就是对数据库层的操作,具体如下:   单库数据库–>数据库读写分离–>数据的垂直拆分–>数据的水平拆分… Read More

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

在讲数据库水平拆分时候,我列出了水平拆分数据库需要解决的两个难题,它们分别是主键的设计问题和单表查询的问题,主键问题前文已经做了比较详细的讲述了,但是第二个问题我没有讲述,今天我将会讲讲如何解决数据表被垂直拆分后的单表查询问题。   要解决数据表被水平拆分后的单表查询问题,我们首先要回到问题的源头,我们为什么需要将数据库的表进行水平拆分。下面我们来推导下我们最终下定决心做水平拆分表的演进过程,具体如下:     第一个演进过程:进行了读写分离的表在数据增长后需要进行水平拆分吗?回答这个疑问我们首先要想想进行读写分离操作的表真的是因为数据量大吗?答案其实是否定的。最基本的读写分离的目的是为了解决数据库的某张表读写比率严重失衡的问题, 举个例子,有一张表每天会增加1万条数据,也就是说我们的系统每天会向这张表做1万次写的操作,当然也有可能我们还会更新或者删除这张表的某些已有的记 录,这些操作我们把它归并到写操作,那么这张表一天我们随意定义个估值吧2万5千次写操作,其实这种表的数据量并不大,一年下来也就新增的几百万条数据, 一个大型的商业级别的关系数据库,当我们为表建立好索引和分区后,查询几百万条数据它的效率并不低,这么说来查询的效率问题还不一定是读写分离的源头。其 实啊,这张表除了写操作每天还承受的读操作可能会是10万,20万甚至更高,这个时候问题来了,像oracle和mysql这样鼎鼎大名的关系数据库默认 的最大连接数是100,一般上了生产环境我们可能会设置为150或者200,这些连接数已经到了这些关系数据库的最大极限了,如果再加以提升,数据库性能 会严重下降,最终很有可能导致数据库由于压力过大而变成了一个巨锁,最终导致系统发生503的错误,如是我们就会想到采用读写分离方案,将数据库的读操作 迁移到专门的读库里,如果系统的负载指标和我列举的例子相仿,那么迁移的读库甚至不用做什么垂直拆分就能满足实际的业务需求,因为我们的目的只是为了减轻 数据库的连接压力。     第二个演进过程: 随着公司业务的不断增长,系统的运行的压力也越来越大了,我们已经了解了系统的第一个瓶颈是从存储开始了,如是我们开始谈论方案如何解决存储的问题,这时 我们发现我们已经做了读写分离,也使用了缓存,甚至连搜索技术也用上了,那么下个阶段就是垂直拆分了,垂直拆分很简单就是把表从数据库里拆出来,单独建库 建表,但是这种直截了当的方案想想就能感到这样的做法似乎没有打中系统的痛点,那么系统的痛点到底是什么呢?根据数据库本身的特性,我们会发现痛点主要是… Read More

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

本文开篇提个问题给大家,关系数据库的瓶颈有哪些?我想有些朋友看到这个问题肯定会说出自己平时开发中碰到了一个跟数据库有关的什么什么问题,然后如何 解决的等等,这样的答案没问题,但是却没有代表性,如果出现了一个新的存储瓶颈问题,你在那个场景的处理经验可以套用在这个新问题上吗?这个真的很难说。   其实不管什么样的问题场景最后解决它都要落实到数据库的话,那么这个问题场景一定是击中了数据库的某个痛点,那么我前面的六篇文章里那些手段到底是在解决数据库的那些痛点,下面我总结下,具体如下:      痛点一:数据库的连接数不够用了。换句话说就是在同一个时间内,要求和数据库建立连接的请求超出了数据库所允许的最大连接数,如果我们对超出的连接数没 有进行有效的控制让它们直接落到了数据库上,那么就有可能会让数据库不堪重负,那么我们就得要分散这些连接,或者让请求排队。      痛点二:对于数据库表的操作无非两种一种是写操作,一种是读操作,在现实场景下很难出现读写都成问题的事情,往往是其中一种表的操作出现了瓶颈问题所引 起的,由于读和写都是操作同一个介质,这就导致如果我们不对介质进行拆分去单独解决读的问题或者写的问题会让问题变的复杂化,最后很难从根本上解决问题。      痛点三:实时计算和海量数据的矛盾。本系列讲存储瓶颈问题其实有一个范畴的,那就是本系列讲到的手段都是在使用关系数据库来完成实时计算的业务场景,而 现实中,数据库里表的数据都会随着时间推移而不断增长,当表的数据超出了一定规模后,受制于计算机硬盘、内存以及CPU本身的能力,我们很难完成对这些数据的实时处理,因此我们就必须要采取新的手段解决这些问题。   我今天之所以总结下这三个痛点,主要是为了告诉大家当我们面对存储瓶颈问题时候,我们要把问题最终落实到这个问题到底是因为触碰到了数据库的那些痛点,这样回过头来再看我前面说到的技术手段,我就会知道该用什么手段来解决问题了。   好了,多余的话就说到这里,下面开始本篇的主要内容了。首先给大伙看一张有趣的漫画,如下图所示: 身为程序… Read More

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

在开始本篇主要内容前,我们一起看看下面的几张截图,首先是第一张图,如下图所示: 这是一家电商网站的首页,当我们第一次打开这个首页,网站会弹出一个强制性的对话框,让用户选择货物配送的地址,如果是淘宝和京东的话,那么这个选择配货地址的选项是在商品里,如下图是淘宝的选择配送地点: 下图是京东选择配货地点: 那么图一 跟京东和淘宝有什么区别呢?图一的电商强制用户选择地区后,那么我们在查询这个商品时候会因为地区不同,显示的查询结果会不一样,这个就和网站做国际化有 点像,不过网站国际化是切语言和语言相关的静态资源,但是电商这个地域的选择是和业务相关的,不同的地域查询结果是不相同的,这个选择地域的弹出框很像一 个路由器。相比之下,淘宝和京东把商品的配送和商品相关,那么我们在这些网站里查询商品时候,其实是按照全国查询的,全国不同的地方查询同一个条件所获得 到的结果是一致的。从业务角度而言,这说明第一个电商的业务没有全国铺开,就算是铺开了,地域的差异也影响到物流的问题,而淘宝和京东则正是一个全国意义 的大型电商网站了。   回到技术的角度,这两种不同的做法有没有可能还和技术问题有关了?今天我就来探讨下这个问题。   不管网站 大与小,一个网站肯定可以分为客户端、服务端和存储端,勾连这不同的组成部分是网络,网络是一种通讯设施,距离的远近会直接影响到网络传输的效率问题,如 是乎就出现了像CDN这样的技术,很多大型互联网公司还会在不同的城市建立机房,这些手段的目的就是在解决距离对网络传输效率的影响,但是当这种就近解决 问题的方案落到存储层的时候,问题就来了。上篇里我说道web服务的水平扩展问题,这种水平扩展是基于一种无状态性的原理设计的,但是到了存储层我们不管 怎么拆分它,它都很难消除状态的问题,也就是存储层有状态性是它的天然属性。特别是碰到一个竞争性的存储资源时候,这种状态性会变得非常顽固,例如商品的 库存问题,如果我们把库存数据对等的平移到不同地域的数据中心,那么如何保证不同地方的库存信息总是准确的,这就成为了难题。这种问题放在一个小国家不是… Read More

jQuery实现的测试答题功能

有时在网页中要加入一个在线测试功能,例如在线调查,在线测试各类知识等应用,这类应用需要用到很多前后端技能。今天我给大家分享一个基于jQuery的前端应用——测试答题功能。 查看演示 下载源码 HTML 首先载入jquery库文件和quiz.js以及所需的CSS样式文件styles.css。 <script src="jquery.js"></script> <script src="quiz.js"></script> <link rel="stylesheet" href="styles.css" /> 然后在需要放置测试题的位置加入div#quiz-container。 <div id="quiz-container"></div> jQuery 首先,我们定义题目和答案选项,question是题目,answers是答案选项,correctAnswer是正确答案。可以看出定义的init是一个json数据格式。… Read More

HTML5 Geolocation API : 实时跟踪应用

getCurrentPosition与watchPosition   watchPosition会监视你的移动,并在位置改变时向你报告位置。watchPPosition方法看上去确实与getCurrentPosition方法很像,不过行为稍有不同,每次位置比阿奴啊时会重复调用你的成功处理程序 watchPosition调用步骤: 你的应用watchPosition,传入一个成功处理函数 watchPosition在后台不断监视你的位置 你的位置改变时,watchPostion调用成功处理函数来报告你的新位置 watchPostion继续监视你的位置(并向成功处理程序报告),直至你调用clearWatch将它清除   HTML代码   我们已HTML5COL学院中级课程相关章节的课程为基础,再向HTML增加几个按钮,从而能开始和结束跟踪你的位置;我们设置开始按钮是因为用户不想一直被跟踪,他们通常希望对此有些控制;设置结束按钮,是考虑到对于移动设备来说,不停检查用户的位置是一个相当耗费电的操作,如果一直打开跟踪,会严重影响电池寿命: 注: 实时跟踪用户可能非常耗电。一定要为用户提供信息,指出日前正在跟踪,另外还要提供相应的一些控件 <!DOCTYPE html> <html> <head>… Read More

HTML5 Geolocation API应用:计算两地距离

找出HTML5COL学院的位置   在HTML5COL学院的前面几个章节中我们已经对HTML5 Geolocation API有了一定认识,接下来我们要对位置做些更有意思的处理;看看你与我们HTML5COL学院的办公室秘密位置相距多远。为此我们需要HTML5COL学院的坐标,而且需要知道如何计算两个坐标之间的距离。   增加一个<div>   首先,在HTML中增加一个 <div>: <!DOCTYPE html> <html> <head> <meta='keywords' content='HTML5COL学院,HTML5COL,CSS3,HTML5COL,编码社区'> </head> <body>… Read More

利用行动装置GPS定位寻找临近地点

早先已展示过,在网页内嵌Google地图、将地址转换为经纬度座标、在地图上显示自订地标图示等技巧,最后来个综合应用当作期末考。本次的练习题是”依使用者所在位置,找出距离最近的五个台北市消防分队”。 简单整理值得留意的技术细节: 在网页嵌入Google地图并放上自订标示点(Marker)的做法,可参考笔记-网页内嵌Google地图与地理位置模拟一文。 由市政府网站取得台北市消防分队地址,透过地理编码算出经纬度座标,可参考Google Maps API地址转换一文。而在本次范例中,我们预先将查到的经纬度数字一并写入CSV档中,不必每次重新查询。 要计算两个经纬度座标间的直线距离,Haversine公式是最常用的演算法,简单来说,就是把地球当成一个圆球,用球体表面任两点到圆心所形成的夹角,加上一堆Sin , Cos推算沿球体表面连接两点的弧线长度。依据英国学者研究指出,思考过度复杂数学公式可能会对中老年人的神经中枢有负面影响,为求养生保健,在此直接引用公式,对于数学细节就不再深究… HTML5世代的浏览器(IE要IE9+)多能支援地理资讯功能,可整合行动装置(手机、平版)的GPS取得使用者当时所在地理位置(存取前会弹出确认视窗征求使用者同意),如此我们便可依使用者所在位置提供不同资讯,例如:列出临近的商店、餐厅或服务据点…等等。要透过Javascript存取使用者的地理资讯,可使用Geolocation API。 使用者所在位置及各消防分队的经纬度都有了,便可利用Haversine公式算出各分队与目前位置的直线距离作为远近参考。(不考虑路线规划、交通状况等因素,那是导航软体或霹雳车RD该烦恼的事,为了好玩写程式没必要把自己逼上绝路XD至于有心挑战的朋友,Google Maps也有路线规划API,倒是可以参考) Javascript的Array.sort(compareFunction),提供了类似LINQ OrderBy(o => o.prop)的简便做法,让我惊喜了一下。原本以为要花点心思处理,没想到只用两行就搞定依距离远近排序的需求。 前篇文章介绍的动态文字图档权充Marker… Read More

纯CSS打造的Family tree(族谱)

Family tree(族谱),也称家谱,用来记录家族世系繁衍辈份关系。本文结合实例,不借助任何js脚本,使用纯CSS打造一个漂亮的Family tree(族谱),也可以应用的企业组织架构图中。 查看演示 下载源码 HTML 我们使用div#tree来包含整个族谱结构,内部以ul和li元素构建数据源。实际开发中这些族谱数据源可以从数据库中读取,就像得到一个无限级的分类列表,以下是主要的html结构。 <div class="tree"> <ul> <li> <a href="#">Parent</a> <ul>

jQuery实现的向下推送图文信息滚动效果

WEB页面需要展示网站最新信息,如微博动态、余票信息、路况监控等项目中常见的实时数据滚动效果,我们可以用jQuery来实现前端信息滚动效果。本文我们将结合实例为大家讲解如何使用jQuery来实现图文信息滚动效果。 查看演示 下载源码 HTML 我们以新浪微博信息滚动为背景,html中包含了多条微博图文信息,结构如下: <div id="con"> <ul> <li> <a href="#" class="face"><img src="http://tp3.sinaimg.cn/1197161814/ 50/1290146312/1" /></a> <h4><a href="#">李开复</a></h4> <p>【领导力的四个境界】境界一:员工因为你的职位而服从你;境界二:员工因为你的能力而服从你;…

大型网站系统架构的演化

前言 一个成熟的大型网站(如淘宝、京东等)的系统架构并不是开始设计就具备完整的高性能、高可用、安全等特性,它总是随着用户量的增加,业务功能的扩展 逐渐演变完善的,在这个过程中,开发模式、技术架构、设计思想也发生了很大的变化,就连技术人员也从几个人发展到一个部门甚至一条产品线。所以成熟的系统 架构是随业务扩展而完善出来的,并不是一蹴而就;不同业务特征的系统,会有各自的侧重点,例如淘宝,要解决海量的商品信息的搜索、下单、支付,例如腾讯, 要解决数亿的用户实时消息传输,百度它要处理海量的搜索请求,他们都有各自的业务特性,系统架构也有所不同。尽管如此我们也可以从这些不同的网站背景下, 找出其中共用的技术,这些技术和手段可以广泛运行在大型网站系统的架构中,下面就通过介绍大型网站系统的演化过程,来认识这些技术和手段。   一、最开始的网站架构 最初的架构,应用程序、数据库、文件都部署在一台服务器上,如图:   二、应用、数据、文件分离 随着业务的扩展,一台服务器已经不能满足性能需求,故将应用程序、数据库、文件各自部署在独立的服务器上,并且根据服务器的用途配置不同的硬件,达到最佳的性能效果。   三、利用缓存改善网站性能 在硬件优化性能的同时,同时也通过软件进行性能优化,在大部分的网站系统中,都会利用缓存技术改善系统的性能,使用缓存主要源于热点数据的存在,大 部分网站访问都遵循28原则(即80%的访问请求,最终落在20%的数据上),所以我们可以对热点数据进行缓存,减少这些数据的访问路径,提高用户体验。 缓存实现常见的方式是本地缓存、分布式缓存。当然还有CDN、反向代理等,这个后面再讲。本地缓存,顾名思义是将数据缓存在应用服务器本地,可以存 在内存中,也可以存在文件,OSCache就是常用的本地缓存组件。本地缓存的特点是速度快,但因为本地空间有限所以缓存数据量也有限。分布式缓存的特点… Read More