logo资料库

WEB高性能解决方案系列主题.doc

第1页 / 共85页
第2页 / 共85页
第3页 / 共85页
第4页 / 共85页
第5页 / 共85页
第6页 / 共85页
第7页 / 共85页
第8页 / 共85页
资料共85页,剩余部分请下载后查看
目录(思想,经验、干货,分享)
主题一:Web系统大规模并发——电商秒杀与抢购
一、大规模并发带来的挑战 
二、作弊的手段:进攻与防守
三、高并发下的数据安全
四、小结
主题二:大型网站的灵魂——性能
一、什么是性能
二、第一路径
三、第二路径
四、第三路径
五、性能的指标和测试
六、小结
主题三:谈Twitter的百TB级Redis缓存实践
一、为什么使用Redis?
二、集群管理
三、数据洞察
四、对Redis的希望清单
五、学到的知识
主题四:大规模网站架构的缓存机制和几何分形学
缓存机制和几何分形学
一、前端Cache机制
1. 域名转为IP地址(域名服务器DNS缓存)
2. 访问服务器,获取静态内容(地理位置分布式服务CDN)
3. 浏览器本地缓存(无网络交互类型)
4. 浏览器和web服务协议缓存(有网络交互类型)
5. 浏览器中间代理
6. 预加载缓存机制
二、Web系统和几何分形学
1. Web系统中的缓存机制
2. 接近硬件层面的“空间换时间”
3. 现实世界中的“缓存机制”
4. 现实世界和计算机“缓存机制”原理的关系,为什么遵循“几何分形”?
主题五:FastJSON实现详解
1. 序列化
序列化入口
序列化组合器
2. 反序列化
3. Why So Fast
4.测试
4.1 测试
4.2 总结
主题六、高并发Web服务的演变——节约系统内存和CPU
一、越来越多的并发连接数
二、Web前端优化,降低服务端压力
三、 节约Web服务端的内存
四、节约Web服务器的CPU
五、 小结
主题七:亿级Web系统搭建——单机到分布式集群
一、Web负载均衡 
1. HTTP重定向
2. 反向代理负载均衡
3. IP负载均衡
4. DNS负载均衡
5. DNS/GSLB负载均衡
二、Web系统的缓存机制的建立和优化
一、 MySQL数据库内部缓存使用
1. 建立恰当的索引
2. 数据库连接线程池缓存
3. Innodb缓存设置(innodb_buffer_pool_size)
二、 MySQL数据库多台服务搭建
1. 建立MySQL主从,从库作为备份
2. MySQL读写分离,主库写,从库读。
3. 主主互备。
三、 MySQL数据库机器之间的数据同步
1. MySQL自带多线程同步
2. 自己实现解析binlog,多线程写入。
四、 在Web服务器和数据库之间建立缓存
1. 页面静态化
2. 单台内存缓存
3. 内存缓存集群
4. 减少数据库“写”
5. NoSQL存储
6. 空节点查询问题
三、异地部署(地理分布式)
一、 核心集中与节点分散
 二、 节点容灾和过载保护
小结
WEB 高性能解决方案系列主题 目录(思想,经验、干货,分享) 目录(思想,经验、干货,分享)................................................................................................ 1 主题一:Web 系统大规模并发——电商秒杀与抢购 ......................................................... 3 一、大规模并发带来的挑战 ...........................................................................................3 二、作弊的手段:进攻与防守........................................................................................ 5 三、高并发下的数据安全................................................................................................ 9 四、小结 .......................................................................................................................... 12 主题二:大型网站的灵魂——性能 ..................................................................................... 13 一、什么是性能.............................................................................................................. 13 二、第一路径 .................................................................................................................. 13 三、第二路径 .................................................................................................................. 15 四、第三路径 .................................................................................................................. 17 五、性能的指标和测试 .................................................................................................. 19 六、小结 .......................................................................................................................... 20 主题三:谈 Twitter 的百 TB 级 Redis 缓存实践 ................................................................20 一、为什么使用 Redis?...............................................................................................21 二、集群管理 .................................................................................................................. 23 三、数据洞察 .................................................................................................................. 24 四、对 Redis 的希望清单..............................................................................................25 五、学到的知识.............................................................................................................. 25 主题四:大规模网站架构的缓存机制和几何分形学 ..........................................................26 缓存机制和几何分形学 .................................................................................................. 26 一、前端 Cache 机制.....................................................................................................27 1. 域名转为 IP 地址(域名服务器 DNS 缓存) ................................................ 27 2. 访问服务器,获取静态内容(地理位置分布式服务 CDN)...................... 27 3. 浏览器本地缓存(无网络交互类型)............................................................ 28 4. 浏览器和 web 服务协议缓存(有网络交互类型).......................................28 5. 浏览器中间代理.................................................................................................29 6. 预加载缓存机制.................................................................................................31 二、Web 系统和几何分形学 .........................................................................................33 1. Web 系统中的缓存机制 .................................................................................... 33 2. 接近硬件层面的“空间换时间”..........................................................................34 3. 现实世界中的“缓存机制”..................................................................................36 4. 现实世界和计算机“缓存机制”原理的关系,为什么遵循“几何分形”? .......38
主题五:FastJSON 实现详解 ............................................................................................... 38 1. 序列化.........................................................................................................................39 序列化入口.............................................................................................................. 41 序列化组合器 .......................................................................................................... 41 2. 反序列化.....................................................................................................................45 3. Why So Fast...............................................................................................................49 4.测试 ............................................................................................................................... 50 主题六、高并发 Web 服务的演变——节约系统内存和 CPU......................................... 52 一、越来越多的并发连接数 .......................................................................................... 53 二、Web 前端优化,降低服务端压力 .........................................................................54 三、 节约 Web 服务端的内存 .......................................................................................57 四、节约 Web 服务器的 CPU...................................................................................... 63 五、 小结 ......................................................................................................................... 67 主题七:亿级 Web 系统搭建——单机到分布式集群 ...................................................... 67 一、Web 负载均衡 ........................................................................................................68 1. HTTP 重定向 ...................................................................................................... 68 2. 反向代理负载均衡.............................................................................................69 3. IP 负载均衡.........................................................................................................70 4. DNS 负载均衡 .................................................................................................... 72 5. DNS/GSLB 负载均衡 ..........................................................................................72 二、Web 系统的缓存机制的建立和优化.....................................................................74 一、 MySQL 数据库内部缓存使用......................................................................74 二、 MySQL 数据库多台服务搭建......................................................................75 三、 MySQL 数据库机器之间的数据同步 ......................................................... 77 四、 在 Web 服务器和数据库之间建立缓存......................................................78 三、异地部署(地理分布式)......................................................................................82 一、 核心集中与节点分散....................................................................................82 二、 节点容灾和过载保护 ...................................................................................84 小结 .......................................................................................................................... 85
主题一:Web 系统大规模并发——电商秒杀与抢购 电商的秒杀和抢购,对我们来说,都不是一个陌生的东西。然而,从技术的角度来说,这对 于 Web 系统是一个巨大的考验。当一个 Web 系统,在一秒钟内收到数以万计甚至更多请 求时,系统的优化和稳定至关重要。这次我们会关注秒杀和抢购的技术实现和优化,同时, 从技术层面揭开,为什么我们总是不容易抢到火车票的原因? 一、大规模并发带来的挑战 在过去的工作中,我曾经面对过 5w 每秒的高并发秒杀功能,在这个过程中,整个 Web 系 统遇到了很多的问题和挑战。如果 Web 系统不做针对性的优化,会轻而易举地陷入到异常 状态。我们现在一起来讨论下,优化的思路和方法哈。 1. 请求接口的合理设计 一个秒杀或者抢购页面,通常分为 2 个部分,一个是静态的 HTML 等内容,另一个就是参 与秒杀的 Web 后台请求接口。 通常静态 HTML 等内容,是通过 CDN 的部署,一般压力不大,核心瓶颈实际上在后台请求 接口上。这个后端接口,必须能够支持高并发请求,同时,非常重要的一点,必须尽可能“快”, 在最短的时间里返回用户的请求结果。为了实现尽可能快这一点,接口的后端存储使用内存 级别的操作会更好一点。仍然直接面向 MySQL 之类的存储是不合适的,如果有这种复杂业 务的需求,都建议采用异步写入。
当然,也有一些秒杀和抢购采用“滞后反馈”,就是说秒杀当下不知道结果,一段时间后才可 以从页面中看到用户是否秒杀成功。但是,这种属于“偷懒”行为,同时给用户的体验也不好, 容易被用户认为是“暗箱操作”。 2. 高并发的挑战:一定要“快” 我们通常衡量一个 Web 系统的吞吐率的指标是 QPS(Query Per Second,每秒处理请求 数),解决每秒数万次的高并发场景,这个指标非常关键。举个例子,我们假设处理一个业 务请求平均响应时间为 100ms,同时,系统内有 20 台 Apache 的 Web 服务器,配置 MaxClients 为 500 个(表示 Apache 的最大连接数目)。 那么,我们的 Web 系统的理论峰值 QPS 为(理想化的计算方式): 20*500/0.1 = 100000 (10 万 QPS) 咦?我们的系统似乎很强大,1 秒钟可以处理完 10 万的请求,5w/s 的秒杀似乎是“纸老虎” 哈。实际情况,当然没有这么理想。在高并发的实际场景下,机器都处于高负载的状态,在 这个时候平均响应时间会被大大增加。 就 Web 服务器而言,Apache 打开了越多的连接进程,CPU 需要处理的上下文切换也越多, 额外增加了 CPU 的消耗,然后就直接导致平均响应时间增加。因此上述的 MaxClient 数目, 要根据 CPU、内存等硬件因素综合考虑,绝对不是越多越好。可以通过 Apache 自带的 abench 来测试一下,取一个合适的值。然后,我们选择内存操作级别的存储的 Redis,在 高并发的状态下,存储的响应时间至关重要。网络带宽虽然也是一个因素,不过,这种请求 数据包一般比较小,一般很少成为请求的瓶颈。负载均衡成为系统瓶颈的情况比较少,在这 里不做讨论哈。 那么问题来了,假设我们的系统,在 5w/s 的高并发状态下,平均响应时间从 100ms 变为 250ms(实际情况,甚至更多): 20*500/0.25 = 40000 (4 万 QPS) 于是,我们的系统剩下了 4w 的 QPS,面对 5w 每秒的请求,中间相差了 1w。 然后,这才是真正的恶梦开始。举个例子,高速路口,1 秒钟来 5 部车,每秒通过 5 部车, 高速路口运作正常。突然,这个路口 1 秒钟只能通过 4 部车,车流量仍然依旧,结果必定 出现大塞车。(5 条车道忽然变成 4 条车道的感觉) 同理,某一个秒内,20*500 个可用连接进程都在满负荷工作中,却仍然有 1 万个新来请求, 没有连接进程可用,系统陷入到异常状态也是预期之内。
其实在正常的非高并发的业务场景中,也有类似的情况出现,某个业务请求接口出现问题, 响应时间极慢,将整个 Web 请求响应时间拉得很长,逐渐将 Web 服务器的可用连接数占 满,其他正常的业务请求,无连接进程可用。 更可怕的问题是,是用户的行为特点,系统越是不可用,用户的点击越频繁,恶性循环最终 导致“雪崩”(其中一台 Web 机器挂了,导致流量分散到其他正常工作的机器上,再导致正 常的机器也挂,然后恶性循环),将整个 Web 系统拖垮。 3. 重启与过载保护 如果系统发生“雪崩”,贸然重启服务,是无法解决问题的。最常见的现象是,启动起来后, 立刻挂掉。这个时候,最好在入口层将流量拒绝,然后再将重启。如果是 redis/memcache 这种服务也挂了,重启的时候需要注意“预热”,并且很可能需要比较长的时间。 秒杀和抢购的场景,流量往往是超乎我们系统的准备和想象的。这个时候,过载保护是必要 的。如果检测到系统满负载状态,拒绝请求也是一种保护措施。在前端设置过滤是最简单的 方式,但是,这种做法是被用户“千夫所指”的行为。更合适一点的是,将过载保护设置在 CGI 入口层,快速将客户的直接请求返回。 二、作弊的手段:进攻与防守 秒杀和抢购收到了“海量”的请求,实际上里面的水分是很大的。不少用户,为了“抢“到商品, 会使用“刷票工具”等类型的辅助工具,帮助他们发送尽可能多的请求到服务器。还有一部分 高级用户,制作强大的自动请求脚本。这种做法的理由也很简单,就是在参与秒杀和抢购的 请求中,自己的请求数目占比越多,成功的概率越高。 这些都是属于“作弊的手段”,不过,有“进攻”就有“防守”,这是一场没有硝烟的战斗哈。 1. 同一个账号,一次性发出多个请求
部分用户通过浏览器的插件或者其他工具,在秒杀开始的时间里,以自己的账号,一次发送 上百甚至更多的请求。实际上,这样的用户破坏了秒杀和抢购的公平性。 这种请求在某些没有做数据安全处理的系统里,也可能造成另外一种破坏,导致某些判断条 件被绕过。例如一个简单的领取逻辑,先判断用户是否有参与记录,如果没有则领取成功, 最后写入到参与记录中。这是个非常简单的逻辑,但是,在高并发的场景下,存在深深的漏 洞。多个并发请求通过负载均衡服务器,分配到内网的多台 Web 服务器,它们首先向存储 发送查询请求,然后,在某个请求成功写入参与记录的时间差内,其他的请求获查询到的结 果都是“没有参与记录”。这里,就存在逻辑判断被绕过的风险。 应对方案: 在程序入口处,一个账号只允许接受 1 个请求,其他请求过滤。不仅解决了同一个账号, 发送 N 个请求的问题,还保证了后续的逻辑流程的安全。实现方案,可以通过 Redis 这种 内存缓存服务,写入一个标志位(只允许 1 个请求写成功,结合 watch 的乐观锁的特性), 成功写入的则可以继续参加。
或者,自己实现一个服务,将同一个账号的请求放入一个队列中,处理完一个,再处理下一 个。 2. 多个账号,一次性发送多个请求 很多公司的账号注册功能,在发展早期几乎是没有限制的,很容易就可以注册很多个账号。 因此,也导致了出现了一些特殊的工作室,通过编写自动注册脚本,积累了一大批“僵尸账 号”,数量庞大,几万甚至几十万的账号不等,专门做各种刷的行为(这就是微博中的“僵尸 粉“的来源)。举个例子,例如微博中有转发抽奖的活动,如果我们使用几万个“僵尸号”去混 进去转发,这样就可以大大提升我们中奖的概率。 这种账号,使用在秒杀和抢购里,也是同一个道理。例如,iPhone 官网的抢购,火车票黄 牛党。 应对方案: 这种场景,可以通过检测指定机器 IP 请求频率就可以解决,如果发现某个 IP 请求频率很高, 可以给它弹出一个验证码或者直接禁止它的请求: 1. 2. 弹出验证码,最核心的追求,就是分辨出真实用户。因此,大家可能经常发现,网 站弹出的验证码,有些是“鬼神乱舞”的样子,有时让我们根本无法看清。他们这样做的 原因,其实也是为了让验证码的图片不被轻易识别,因为强大的“自动脚本”可以通过图 片识别里面的字符,然后让脚本自动填写验证码。实际上,有一些非常创新的验证码, 效果会比较好,例如给你一个简单问题让你回答,或者让你完成某些简单操作(例如 百度贴吧的验证码)。 直接禁止 IP,实际上是有些粗暴的,因为有些真实用户的网络场景恰好是同一出口 IP 的,可能会有“误伤“。但是这一个做法简单高效,根据实际场景使用可以获得很好的 效果。
3. 多个账号,不同 IP 发送不同请求 所谓道高一尺,魔高一丈。有进攻,就会有防守,永不休止。这些“工作室”,发现你对单机 IP 请求频率有控制之后,他们也针对这种场景,想出了他们的“新进攻方案”,就是不断改变 IP。 有同学会好奇,这些随机 IP 服务怎么来的。有一些是某些机构自己占据一批独立 IP,然后 做成一个随机代理 IP 的服务,有偿提供给这些“工作室”使用。还有一些更为黑暗一点的, 就是通过木马黑掉普通用户的电脑,这个木马也不破坏用户电脑的正常运作,只做一件事情, 就是转发 IP 包,普通用户的电脑被变成了 IP 代理出口。通过这种做法,黑客就拿到了大量 的独立 IP,然后搭建为随机 IP 服务,就是为了挣钱。 应对方案: 说实话,这种场景下的请求,和真实用户的行为,已经基本相同了,想做分辨很困难。再做 进一步的限制很容易“误伤“真实用户,这个时候,通常只能通过设置业务门槛高来限制这种 请求了,或者通过账号行为的”数据挖掘“来提前清理掉它们。 僵尸账号也还是有一些共同特征的,例如账号很可能属于同一个号码段甚至是连号的,活跃 度不高,等级低,资料不全等等。根据这些特点,适当设置参与门槛,例如限制参与秒杀的 账号等级。通过这些业务手段,也是可以过滤掉一些僵尸号。 4. 火车票的抢购 看到这里,同学们是否明白你为什么抢不到火车票?如果你只是老老实实地去抢票,真的很 难。通过多账号的方式,火车票的黄牛将很多车票的名额占据,部分强大的黄牛,在处理验 证码方面,更是“技高一筹“。 高级的黄牛刷票时,在识别验证码的时候使用真实的人,中间搭建一个展示验证码图片的中 转软件服务,真人浏览图片并填写下真实验证码,返回给中转软件。对于这种方式,验证码 的保护限制作用被废除了,目前也没有很好的解决方案。
分享到:
收藏