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

本文信息本文由方法SEO顾问发表于2016-05-27 08:30 星期五,共 2413字。转载请注明:如何应对并发(3) – 需求裁剪_【方法SEO顾问】,如果我网站的文章对你有所帮助的话,来百度口碑给个好评呗!

本文来自曹政大神的微信公众号【caoz的梦呓】,caoz的文章篇篇犀利,值得细读与收藏,特转载过来,分享给大家,如果你也喜欢,可以微信搜索“caoz的梦呓”来关注他。文章所有版权归原作者曹政所有!

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

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

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

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

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

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

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

下面,案例说话

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

请问,

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

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

这就是设定了边界条件。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

最后,留一个思考题

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

  • 版权声明:除非注明,本博客均为北京SEO方法的原创文章,转载或引用请以超链接形式标明本文地址,否则会在SEO圈内公开此种不尊重版权的行为,谢谢合作!本文地址:https://seofangfa.com/caoz/%e5%a6%82%e4%bd%95%e5%ba%94%e5%af%b9%e5%b9%b6%e5%8f%913-%e9%9c%80%e6%b1%82%e8%a3%81%e5%89%aa.html

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: