zoukankan      html  css  js  c++  java
  • 大型网站技术演进的思考(转)

    http://www.cnblogs.com/sharpxiajun/p/4237704.html

    (一)摘要

                                                         session不断的传递和复制,如tomcat

                                                    缓存服务器(可用一台,可分布式,如memcached)

    网站访问量非常大,并发数也非常高->部署多台服务器->不同物理部署服务器之间的session同步问题->   session的信息直接存储到浏览器的cookie里,如早期的淘宝

                                                    实现session粘滞的负载均衡的硬件或者软件

    =>session实际上就是数据存储问题->

          这里我先讲讲自己独立使用服务器部署网站的问题,如果我们要把网站服务应用使用多台服务器部署,这么做的目的一般有两个:

    1. 保证网站的可用性,多台服务器部署应用,那么其中一些服务器挂掉了,只要网站还有服务器能正常运转,那么网站对外任然可以正常提供服务。
    2. 提高网站的并发量,服务器越多那么网站能够服务的用户,单位时间内能承载的请求数也就越大。

      不过要做到以上两点,并不是我们简单将网站分开部署就可以满足的,因为大多数网站在用户使用时候都是要保持用户的状态,具体点就是网站要记住请求是归属到那一个客户端,而这个状态在网站开发里就是通过会话session来体现的

    (三)

    能用简单的方案解决问题,就一定要毫不犹豫的舍弃复杂的方案,当系统需要使用高难度技术的时候,我们一定要让自己感受到这是迫不得已的

    数据库的表之间都没有外键,数据库不准写触发器,可以写写存储过程,但是存储过程决不能用于处理生产业务逻辑,而只能是一些辅助工作,例如导入导出写数据啊,后面听说就算是数据库做到了读写分离,数据之间同步也最好是用java程序做,也不要使用存储过程,除非迫不得已。开始我还不太理解这些做法,这种不理解不是指我质疑了公司的做法,而是我在想如果一个数据库我们就用了这么一点功能,那还不如让数据库公司为咋们定制个阉割版算了,不过在我学习了hadoop之后我有点理解这个背后的深意了,其实作为存储数据的数据库,它和我们开发出的程序的本质是一样的那就是:存储和计算,那么当数据库作为一个业务系统的存储介质时候,那么它的存储对业务系统的重要性要远远大于它所能承担的计算功能,当数据库作为互联网系统的存储介质时候,如果这个互联网系统成长迅速,那么这个时候我们对数据库存储的要求就会越来越高,最后估计我们都想把数据库的计算特性给阉割掉,当然数据库基本的增删改查我们是不能舍弃的,因为它们是数据库和外界沟通的入口,我们如果接触过具有海量数据的数据库,我们会发现让数据库运行的单个sql语句都会变得异常简洁和简单,因为这个时候我们知道数据库已经在存储这块承担了太多的负担,那么我们能帮助数据库的手段只能是尽量降低它运算的压力

      1. 大型网站解决存储瓶颈的问题,我们要找准存储这个关键点,因为数据库其实是存储和运算的组合体,但是在我们这个场景下,存储是第一位的,当存储是瓶颈时候我们要狠下心来尽量多的抛弃数据的计算特点,所以上文中我提出我们数据库就不要滥用计算功能了例如触发器、存储过程等等。

      2. 数据库剥离计算功能不代表不要数据的计算功能,因为没有数据的计算功能数据库也就没价值了,那么我们要将数据库的计算功能进行迁移,迁移到程序里面,一般大型系统程序和数据库都是分开部署到不同服务器上,因此程序里处理数据计算就不会影响到数据库所在服务器的性能,就可以让安装数据库的服务器专心服务于存储。

      3. 我们要尽一切可能的把数据库的变化对服务层的影响降到最低,最好是数据库做拆分后,现有业务不要任何的更改,那么我们就得设计一个全新的数据访问层,这个数据访问层将数据库和服务层进行解耦,任何数据库的变化都由数据访问层消化,数据访问层对外接口要高度统一,不要轻易改变。

      4. 如果我们设计了数据访问层来解决数据库拆分的问题,数据访问层加上数据库其实就组合出了一个分布式数据库的解决方案,由此可见拆分数据库的难度是很高的,因为数据库将拥有分布式的特性,而分布式开发就意味开发难度的增加。

      5. 对于分布式事务的处理,我们尽量要从具体问题具体分析,不要一感觉这个事务操作本质是分布式事务就去寻找通用的分布式事务技术手段,这样的想法其实是回避困难的思想,结果可能会是把问题搞得更加复杂。

    (四)

    被水平拆分的表的主键设计最好使用一个字段表示

    (五)

    DB2当数据量超过了1亿多,mysql单表超过了100万条后那么全表查询这些表的记录都会存在很大的效率问题

      启迪一:数据库的读写分离不是简单的把主库数据导入到读库里就能解决问题,读数据库和写数据的分离的目的是为了让读和写操作不能相互影响效率。

      启迪二:解决读的瓶颈问题的本质是减少数据的检索范围,数据检索的范围越小,读的效率也就越高;

      启迪三:数据库的垂直拆分和水平拆分首先不应该从技术角度进行,而是通过业务角度进行,如果数据库进行业务角度的水平拆分,那么拆分的维度往往是要根据该表的某个字段进行的,这个字段选择要有一定原则,这个原则主要是该字段的维度的粒度不能过细,该字段的维度范围不能经常的动态发生变化,最后就是该维度不能让数据分布严重失衡。

  • 相关阅读:
    阿米巴
    linux系统和依赖包常用下载地址
    chm格式文件能打开,但看不到内容问题
    云计算的三层SPI模型
    云计算相关的一些概念Baas、Saas、Iaas、Paas
    IOS 开发环境,证书和授权文件等详解
    Android MDM参考
    理解RESTful架构
    联想小新Air2020锐龙版在Ubuntu下添加指纹识别
    避免踩坑,这才是为知笔记导入印象笔记数据的正确姿势
  • 原文地址:https://www.cnblogs.com/SamuelSun/p/4288923.html
Copyright © 2011-2022 走看看