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

如何应对并发(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秒后自动进入帖子页。（对这个场景很多人都熟悉吧），就这么一个特简单甚至有点不是很友好的设计，主从同步延迟的问题就基本解决了。

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

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

最后，留一个思考题

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