关于大型web服务器的设计思路

大型网站，好比门户网站，在海量用户访问、高并发请求方面，基本的解决方案是如下几点：
  一、高性能的数据库(oracle/db2/mysql...)
  二、高性能的Web容器(weblogic/apache...)
  三、高效率的编程语言(java/C#)
  四、使用高性能的服务器(小型机、PC服务器)
  五、集群分布式运行（好比上百台小型机器在线运行）

可是在在线用户上百万，日点击量超亿，而数据达几十T，甚至日数据量就达到T级别这种状况下仍是难以解决
大型网站面临的高负载和高并发问题。
   本人也常常关注这方面的解决方案，结合本身的经验。总结了一部分经常使用的设计，但愿各位多多指点。

1、设计上有足够弹性
  这是在前期架构设计师要足够考虑到的。最终目的是经过物理设备的线性投入来应付业务量的增加，而不止于受到技术框架应用部署的限制，甚至推到重来，这样的结构设计就是弹性的设计，固然这里还包括业务上的弹性设计（目前的开发模式、架构设计在很大程度上也是为了解决这个问题）。
  通常企业也是极力避免这种状况的发生，不然失去的不只是成本投入还包括了客户资源。

2、页面静态化
  即静态html格式，这样避免了对数据资源的访问，同时也大大下降了应用的CPU消耗。若是能静态页面的信息尽可能静态化。

三、无状态
  这里说的无状态是服务器尽可能设计成无状态的与客户端通信，避免了占用大量内存的状况，但这也不是绝对的。部分应用中的状态保留也能大大减小IO流量与数据库的访问压力。看具体状况而定。

4、数据库集群、横向/纵向切分
    数据库集群能缓解数据库的压力，但节点过多又会引发写入同步消耗过大。
    数据库横向切分也就是把一个业务数据按不一样属性（好比地域归属、用户名hashcode）来平均的分到各个数据库上。这样控制分库的粒度也就是控制了数据库的分布，能大大缓解单个数据压力过大访问受限的状况，不利的状况是常常要跨库访问，这样状况可能会变得比较复杂。
    数据库纵向切分也就是按业务内容来分不一样的数据库，好比客户资料是一个数据库保存，而商品订单资料又分一个数据库保存，这样也能把数据库压力分解一部分。
    经过数据库的切分也能大大减小单个故障点的影响范围。

5、异步批量处理
    对于非紧急数据，能够采用异步批量处理，安排在非高峰时刻也能提升应用的使用效率。同时批量自己在实现上效率也高于单笔业务处理。

6、表的分区分段分表设计
    这是针对一个数据库的状况下，防止单表数据过大，采用分段分区把一张表分解到不一样的物理设备上，提升查询速度，而能够按业务性质把一张表分红多张表，分区分表能够组合应用，这样在DB维护上也很是有益。同时分表也能有效下降I/O锁状况。

7、分历史数据库
    对于不少网站来讲海量的历史数据是不多用到的，能够按照业务性质，把不修改的数据迁移到专门的历史数据库上归档，好比三个月之前的交易订单、用户的资料修改记录等。对于须要查询历史数据的状况，能够单独提供这类应用来查询历史数据库。这样能避免不断增长的交易数据带来的性能压力。

8、分活动和非活跃用户
    这是按照用户的优先级别分别存储访问，对于少许的活跃用户提供高速的访问（好比经过缓存），这样实际上大大提升了大部分用户请求的处理速度，实际上也大幅度下降应用压力提升并发能力，而对于非活跃用户继续保留了完整的请求服务，客户基本不会产生使用上的差别。

9、分布式的应用
   包括前台服务器和中间件（其实包括前面描述的多个数据库），把压力尽量的均匀地分布到不少服务器上，而服务器能够是上百台的线性增长。

10、使用 Epoll/IOCP 来提升并发性能
    这些在游戏类网站上很是有用，能大大提升单台应用服务器的处理能力。结合多线程多进程多服务器处理能够解决高并发请求的状况。

11、创建专门的文档服务器
    包括的页面图片、软件、文档等数据，因为IO流量大，比较占用应用服务器，必要的时候单独创建服务器存放。这种对于有大量图片的应用好比淘宝商品应该是很是有效的。

12、分查询与更新业务数据库
   对于更新类关键业务提供强有力的高效保证（这类业务相对查询量应该比较少），而对于查询库则能够提供廉价的数据库服务。

十3、缓存
   其实全部的应用都或多或少的使用到了缓存，缓存包括 CPU /内存 /硬盘/网络/客户端的缓存，客户端能够缓存js/图片等信息，而不用频繁的访问应用，内存缓存是很是有效的方式，能够把静态的数据放到应用内存上，而不是频繁访问数据库查询，对于简单数据库其实还可使用专业的缓存应用，好比memcache。

十4、海量数据使用非关系数据库
   对于访问记录等数据结构简单可靠性要求不高的数据持久化，能够不用关系数据库，由于数据库提供的食物访问一致性、隔离性、关系维护消耗了绝大部分资源，而这些功能对不是应用的要点。因此能够考虑使用文件方式或者其余号称NOSQL的方式来存储使用。

    本人认为应用经过分布式并发负载均衡运行能够解决应用服务器的性能问题（经过良好的设计来保证当业务持续增长的时候经过服务器的线性增长就能解决），关键点是数据库的惟一一致性要求（一份数据只能保存在一个地方，更新查询都以它为基础）决定了数据库的成本是很是高的，甚至于没法用资金来解决（大型机也不见得能保证海量数据的访问处理），因此只要解决了数据库的存放问题也就能解决高性能网站的主要问题。
   上边说了这么多基本上仍是把数据对象分开存放、尽可能减小对于数据库的访问的原则提出解决方案的。
     对于系统的高可用性这里也总结出几条：
         A、良好成熟的框架设计（并不必定是很是先进），优秀的业务模型，高内聚低耦合的模块功能。
         B、优化部署配置，包括数据库的优化。
         C、预防为主，有专门的监控负责人，能按期分析系统健康负载状况。在问题爆发前能及时预警。
         D、有良好的单点控制与应急措施，好比当发帖很是耗性能的时候，单独关掉“发帖”，
               保证大部分的游览功能。 保证客户应用的最大化
         E、有效专业的开发管理团队与规范的制度