网站运营 | 站长学院 | 技术文档 | 成语 | 歇后语 | 桌面壁纸 | 帝国时代 | 代码收藏 | IP地址查询 | 生活百科 | 生日密码 | CSS压缩 | 用户评论

如何应对并发(3) - 需求裁剪

【 caoz的梦呓作者:caoz 更新时间:2015-11-21 | 字体:
[导读]应对并发,应对海量数据请求的一个关键策略,也是很多程序员的盲区,需求裁剪......即便是我们所熟知的巨头,面对性能负载问题,也会采取限定边界条件的方式来满足绝大部分用户的正常请求。

曹政(caoz)如何应对并发系列文章

如何应对并发(3) - 需求裁剪

如何应对并发(2) - 请求合并及异步处理

如何应对并发(1) - 关于数据索引

-------------------------------------------------------------------------------------------------

今天讲一下,应对并发,应对海量数据请求的一个关键策略,也是很多程序员的盲区<<<,需求裁剪。

这个<,很多公司<,技术人员会说<,产品经理提需求<,我们完成需求,怎么可能去裁剪需求<,而且<<,裁剪需求会不会显得很low<<,说明水平很差呢<。

其实,这是一个对需求理解的问题。


所谓需求<,并不仅仅是功能实现<,还包括性能指标<,以及所谓的边界条件。


实际上<,即便是我们所熟知的巨头,面对性能负载问题,也会采取限定边界条件的方式来满足绝大部分用户的正常请求<。


下面,案例说话


案例1:搜索大翻页问题<,还记得我提过的这个搜索翻页越多<<,负载越高的问题么<。


请问,

淘宝搜索一个关键词<,最多翻多少页<<?百度呢<?google呢?

你们自行测试一下<,这些巨头给出的搜索结果条目数,我跟你们实话说<,都是估算值<<,最大翻页数,基本不超过100页。

这就是设定了边界条件。


正好前几天一个做比价的创业公司问我技术问题,他们抓了很多商品定价数据<,虽然并发不高<,但是数据量很大<,要在每个搜索中给出结果数和精确翻页数<<,结果一个带搜索条件的 count(*)的问题出来了<,效率特别低<,执行开销特别大<,跑来问我怎么优化,我告诉他,连百度和谷歌都没法做这样的精确结果<,你让我怎么优化。这事就必须从需求出发<<,第一<<,不需要精确的返回结果数<,第二<,翻页做限定<。


案例2:雪崩效应的处理<。

前天讲的<,当缓存扛不住<,负载传递给数据库<,瞬间过载,怎么处理<<?你说我多加数据库行不行<?那要缓存干嘛用的呢<?你说我缓存做实时同步实时备份<?这缓存的存储效率多高啊,网速能跟的上<<?

这就涉及一个灾难应急机制,简单说就是 降级服务<,有损服务。

在出现类似问题的时候,系统自动降级<,将部分用户请求频次低<,价值低但是系统开销不低的功能或者数据临时阻断停止响应,确保整体系统的稳定性<。


比如说,大量用户会订阅热门内容<,而少数用户会订阅冷门内容,那么在缓存崩溃的情况下,系统优先恢复热门内容<,暂停冷门内容的请求的响应,可能可以在开销可控的情况下先满足了90%的访问请求,当数据库负载已经回落后再逐步恢复冷门内容的请求,从而使系统在开销可控的情况下自动完全恢复<,避免雪崩效应导致全局崩溃<。


那么,有人会问,这个降级会不会很low? 其实腾讯邮箱和新浪微博都有过类似的处理策略<<。



caoz谈能力成长 - 取舍之道 这篇其实提过一些类似案例,在早期我技术并不高明的时候<<<,实现CNZZ统计的功能,其实有非常多的数据是有损服务的<,但是实际上用户并不会感受到<<,因为你损失的那些边界条件外的数据是1000个用户也不会有1个去查询的内容<,而如果你要满足这些可能需要付出500%甚至更多的系统开销和研发工作量<<,这种对于很多早期创业公司来说,非常非常重要<。


我们说需求裁剪<,说有损服务<,并不是说不满足用户需求<,我知道很多人有技术洁癖或者说追求技术完美<<,某些文章会说中国的创业太山寨太草根<,美国人的创业都是以完美为导向。那么今天我就说一点<,如果不看这篇文章<<,有几个人知道<<,google原来搜索的结果是不能翻出超过100页的<?大家天天用淘宝吧,请问有谁知道淘宝搜索的最大翻页是100页? 除了写蜘蛛抓人家数据的人之外,who care ?

很多站长都用CNZZ,或其他第三方统计对吧,看数据的时候,看看自己网站的来源网页,请问谁会翻到第20页之后<?


这就是思路的关键<,用户对功能的需求<,你的满足度的边界在哪里?很多程序员没有这个概念,对于数据规模小<,请求并发少的应用来说,这个东西你不考虑也没什么大不了,但是如果面对数据规模大,请求并发大,你就应该有一个概念,如何设定需求的边界条件,既能满足用户的正常请求可以顺畅的响应,同时保证系统在开销可控的情况下稳定健壮的运营<;而当系统出现类似单点故障<,雪崩效应呈现的时候<<,如何设定新的边界条件,让用户在基本可用的情况下给系统一个恢复周期。这些问题都是需要提前思考,并且不断随着业务规模的增加而调整的。


案例3:关于主从分离同步的案例

这个案例很好玩<<<<<,我们刚开始做数据库主从读写分离的时候,经验也不是很丰富<,然后发现一个问题,主从同步经?<;嵊幸桓鍪毖?<,虽然时间很短,大部分在1秒以内<,但是在应用中<<,我们发现<,用户发一个帖子<,然后发完后就应该进入这个帖子的展示页吧,帖子发布到主数据库,而展示页调用的是从数据库<<,结果部分用户发完帖子,因为延迟,就看到了一个该帖子不存在的界面<<,这肯定是一个不好的情况么。当然<<<,技术上肯定有各种解决方法,比如对这种新内容选择从主数据库访问<<,做一些标定等等<,但是呢<,我们就做了一个特别偷懒取巧的方案<。什么方案呢?用户发完帖子后<,先进入一个中转页<,告诉用户您的帖子发布成功<,3秒后自动进入帖子页<。(对这个场景很多人都熟悉吧)<,就这么一个特简单甚至有点不是很友好的设计<,主从同步延迟的问题就基本解决了。

这不是一个完美方案,但是简单有效<,而且对用户来说<,虽然体验略有不好<,但其实也不会有非常大的困扰。 当然,今天<,我不推荐这样的方案<<,但是小团队,创业公司<,遇到一些比较头疼的技术问题,其实完全可以通过需求的一点点微调就绕开,我希望分享的是这个观点。


每次看到创业团队的技术把一个简单的项目做的又累又复杂的时候,我都想说一句,能不能简化一下,从需求到技术方案<。很多所谓的复杂根本没有任何实际意义,除了浪费时间和精力外<<<。


最后<,留一个思考题


还是大翻页问题,一些论坛系统确实有大翻页的实际需要,在这种情况下,我说,只要不允许任意指定页码的跳转翻页,而是只允许上翻页下翻页(或者可以加上上五页,下五页这样的快速翻页)那么就会有特别高的效率的实现方法,有兴趣的同学思考一下。 就是用索引的思路去思考<。

友荐云推荐
  • 转载请注明来源:网站运营 网址:http://www.chinawobo.com/ 向您的朋友推荐此文章
  • 特别声明: 本站除部分特别声明禁止转载的专稿外的其他文章可以自由转载,但请务必注明出处和原始作者<。文章版权归文章原始作者所有。对于被本站转载文章的个人和网站,我们表示深深的谢意。如果本站转载的文章有版权问题请联系我们<<,我们会尽快予以更正<。
RSS订阅
  • QQ邮箱
  • 填写您的邮件地址<,订阅我们的精彩内容:
更多
© 2014 网站运营 - T086.com(原itlearner.com)
微商货源 | 冠珠陶瓷 | 迪威乐云商devmsn | 易奇八字 | wwe美国职业摔角 | 八字算命 | 河南旅游景点大全 |
RunTime:6.16ms QueryTime:7