zoukankan      html  css  js  c++  java
  • 大型网站及架构演进过程

    大型网站及架构演进过程

    标签(空格分隔): 读书笔记


    *通过前面的介绍,我们已经了解了分布式系统的相关知识,下面看一下大型网站架构演化及怎么用这个集群的。

    大型网站的定义

    看这个的我想都是有些经验的人了,就不啰嗦了,大型网站就是访问量&数据量都很大,必须同时具备这两个条件才可以,你整一堆静态页面 每天1000000000000000000000个人访问也不能称之为大型网站。只有当以上两个条件都具备的情况下,你才会有高并发的问题,才需要一个集群来支撑你的业务。

    架构演进

    这方面的文章确实不少,给大家介绍几个比较不错的演进过程
    宜人贷:http://www.jianshu.com/p/410250e006cb
    精品博客(包含很多案例):http://www.hollischuang.com/archives/1036


    关于负载均衡session的解决方案

    关于负载均衡session问题的解决方案:
    1.使用无状态(cookie)的会话请求
    缺点是
    安全性:毕竟cookie是可见的。如果要实现安全的cookie就要在技术上改进,比如加密或每次生成一个token等方式来规避不安全问题。
    cookie长度限制:这个无解
    带宽消耗及性能影响:每次请求都带有session数据,还要解密及设置新token,相对来说肯定对性能有一定影响。
    如果对安全性要求不是很高,还是可以选用这种方式。
    2.ngxin使用ip轮询的方式(不稳定)
    缺点是当使用ip轮询方式式,假如某一ip访问的机器挂了。把这个ip定位到其他机器上,就没有session了。以及nginx会变成一个有状态的节点,内存消耗会更大(不过可以加内存嘛),但是容灾会更麻烦。
    3.session同步
    现在主流的容器都有session同步功能,比如tomcat。
    同步session造成网络带宽消耗,机器越多,消耗越大,相对来说性能也越差。
    每台机器都需要保存全部机器的session.这样session数据占用的内容会很严重。
    4.使用会话集中管理,如membercache来集中管理回话。
    这种是比较常见的实现方式。比以上3种方式都要好,但是也有一定的缺点,比如session存储需要远程读取,会有延时及不稳定性,不过一般我们集群都是部署在内网的,这点可以忽略。另一个问题就是要相应的做好session集中会话管理服务器的容灾工作。假如没有容灾,session会话管理服务器挂了。整个应用就会受到影响。

    读取性能的优化

    数据库优化

    分库/分表/分区:这里建议采用分区操作,对sql比较友好,对orm层也没有变化。分表分库应为最后的优化手段,毕竟对数据层代码有影响。而且会存在分布式事务这个大麻烦。
    读写分离:读库与写库分开,现在各种数据库都有这种技术,只不过相应的来说,会有一定的延时性。但是性能提升是比较大的。

    搜索

    对于站内搜索,如果数据量比较大,可以使用做一个搜索组件来代替like,毕竟like效率不是很高。

    缓存

    对于经常需要读很少改的数据,可以通过缓存来提高读取的性能。这部分就不用多说了,主要就是ehcache/redis等各种cache组件。
    另一个缓存的应用就是缓存页面,把经常访问的动态页面缓存起来,直接读取缓存,减小服务器的开销。比如ehcahce就可以缓存页面。
    缓存使用的好不好的一个指标就是:缓存命中率,如果命中率很低,需要调整代码结构。

    总结
    总的来说,所有的架构都是经历了从以下这个阶段
    1.webapp&database:应用与数据库在一台机器上(all in one)。
    2.webapp+database:分离数据库与应用,提高数据读写性能。
    3.nginx+nwebapp+database:负载均衡+多个应用服务器+数据库。
    4.nginx+n
    webapp+cache+database:基于第3次改变,增加缓存设置,提高读取性能。
    5.nginx+nwebapp+cache+ndatabase:添加多个数据库,实现读写分离,提高读取性能。
    6.基于5的基础上,对数据库进行改造,包括分表分库分区或使用第三方的软件(mycat等)来增强数据库性能。同时对webapp进行拆分,拆分出多个服务中心,每个服务中心负责专门的业务。期间涉及到的技术有(包括但不限于):redis/avtivemq(消息中间件)/mycat/zookeeper/nosql等

    其实对于大型网站来说,主要问题就是
    1.服务的管理:这个比较麻烦,如果服务多了以后各种接口的调用及服务状态的监控
    2.io:对于现在情况来看,我们服务的主要瓶颈还是集中在io层。主要是数据库的读写比较耗费时间,所以解决了这个问题,我想应用的速度是可以更上一层楼的。包括利用适合ssd的数据库,记得国外有个这样的数据库。还有好的中间件,现在的中间件都有较大的性能损耗(30%)。

  • 相关阅读:
    二分图最大匹配的König定理及其证明
    HDOJ 2389 Rain on your Parade
    HDOJ 1083 Courses
    HDOJ 2063 过山车
    POJ 1469 COURSES
    UESTC 1817 Complete Building the Houses
    POJ 3464 ACM Computer Factory
    POJ 1459 Power Network
    HDOJ 1532 Drainage Ditches
    HDU 1017 A Mathematical Curiosity
  • 原文地址:https://www.cnblogs.com/-10086/p/5179307.html
Copyright © 2011-2022 走看看