大型网站技术架构：核心原理与案例分析

20131226-large-website-architecture.txt

大型网站技术架构：核心原理与案例分析
跳转至： 导航、 搜索

    p XI. 。。。但能在比较短的时间内解决这些技术问题，也说明了网站架构其实并不难，真正能解决问题的技术一定是简单的
    大内存服务器作为分布式缓存
        缓存预热、缓存穿透（请求不存在的数据？）
        JBoss Cache
        Memcached：TCP＋文本命令？
            基于Libevent 
    应用服务器集群＋负载均衡
        Session管理：复制 -> 根据源地址Hash映射、Cookie
            Session服务器（SOA？）＋ＳＳＯ 
        LB
            HTTP重定向
            DNS轮询
            反向代理
            IP：SNAT、或LB服务器作为内网物理服务器的网关
                问题：最大吞吐量受制于LB的网卡带宽；能不能使响应数据从真实物理服务器返回给用户呢？=> 
            数据链路层ＬＢ
                三角传输模式：不需要ＩＰ地址，只修改目标mac地址，并把物理服务器的虚拟ＩＰ配置为一样（？）“直接路由(DR)”
                => LVS 
    数据库读写分离
    反向代理＋ＣＤＮ
    分布式文件系统／分布式数据库
    NoSQL和搜索引擎
    业务拆分，分布式服务（ＳＯＡ？）
    12306业务架构修改：排队机制、分时段售票
    异步
        内存共享队列 -> 分布式消息队列？ 
    冗余
    自动化
    安全
        XSS攻击（其实就是往正常用户的页面注入了恶意ＪＳ脚本）
        注入攻击
        CSRF攻击（攻击者伪造一个正常用户到目标网站的请求，前提是用户已经在目标网站上记住了登陆）
            防御：表单请求附带安全Token、验证码、Referer检查 
        Web应用防火墙：ModSecurity 
    新浪微博
        MPSS -> 虚拟机（不同虚拟机上可使用相同端口号）
        同步推 -> 异步推拉（＋消息队列）
            p53 任何可以晚点做的事情都应该晚点做？ 
        多级缓存 
    核心架构要素
        性能
        可用性
        伸缩性
            对于缓存服务器集群，加入新服务器可能导致缓存路由失效，需改进算法以保证可访问性 
        扩展性
        安全性 
    性能测试指标：
        响应时间
        并发数
        吞吐量（TPS HPS QPS）
        性能计数器 
    B+树 VS LSM树
    RAID VS HDFS
    （优雅的）服务降级
    幂等（API）设计
    ＣＡＰ原理
        一致：强一致、用户一致、最终一致 
    代码管理
        主干（trunk）开发、分支（tag）发布（ＳＶＮ？需要大量自动测试集），分支上发现的bug需要merge回主线
        分支开发、主干发布（Ｇｉｔ？）
        网站火车发布模型（哈哈）
        渐进发布（若发现故障需回滚？） 
    一致性Hash + 虚拟节点（一台物理服务器映射多个key）
    分布式关系数据库
        Amoeba
        Cobar（ＳＱＬ路由）：不能处理跨库JOIN和分布式事务 
    HBase
        HRegion 
    高手定律：这个世界只有遇不到的问题，没有解决不了的问题
    朴素Bayes + 特征值的关联依赖 -> TAN + 关联规则的聚类挖掘 -> ARCS
    Wikipedia架构：GeoDNS + LVS + Squid + Lighttd + PHP + Memcached + Lucene + MySQL
        服务器端优化：APC + ImageMagicK + Tex + PHP strstr() ？ 
    Doris？
    网购秒杀
    大型网站故障案例分析
        写log引发故障 => log服务器存储应分离、抑制log生成数量
        高并发访问数据库 => 首页最好是静态的
        加锁导致的不定时超时 => 似乎是存在优先级反转的问题？
        应用启动不同步 => 后端应先于前端启动
        大文件读写导致磁盘被独占 => 不要共用存储服务器（原则：根据应用及数据特征设计）
        不规范的代码提交流程 => 加强提交时的diff检查及review 
    p198 新员工最不需要做的事情就是证明自己的能力 

我对LVS有了点兴趣：但是，对多个物理服务器配置相同的虚拟IP，不会有问题吗？
感觉TCP/IP协议栈的某些底层服务需要修改，以避免冲突