抛开互联网圈子，这几年和公众相关的app最出名的应该算是12306，从一用就崩到顺滑的支持每次节假日出行订票洪峰，逆袭的非常成功。当前它的成功也离不开四方支援，据我了解，起码前端的交互优化应该有蚂蚁同学的影子。
然而，前两天另一个APP引起了我的注意：个税app。因为今天是3月1号申报入口开放了，抱着是否能薅点的想法，却被无情的限流了一整天！
为什么给我限流了
服务器扛不住了。为啥会扛不住？
就个人理解，我们的收入和缴税情况，都是在每个月之后就上报给了个税APP，所以访问的的都是本地数据，而个税申报的操作98%都属于读操作，就算是同一天需要接受所有安装了这个APP的人民的检阅，搞一套弹性架构，也应该比较好应对才对。
唯一可以解释的，我想可能就是数据比较敏感，不能随便使用第三方的云服务器，只能部署在小型机搭建的集群上，因此服务弹性能力被限制，无法应对第一天民众高涨的情绪。
举个例子，去香山的公路是3车道，平日历绰绰有余，但是到了10月金秋，就根本不够了，因为五湖四海的人们都跑来薅红叶。怎么办，难道为了这一个月畅通，就把3车道拓宽到10车道？显然是不合适的，太浪费资源了，一年中的其他11个月份完全用不着。所以，要是不嫌人多，那就多排排队；不然就晚上趁没人的时候偷偷来。
个税APP明显就是这个情况，3月1号设路卡把我卡了，我是理解的，大不了等过两天人少的时候再来。但是，有时候提示系统繁忙，有时候提示访问人数过多，那可就是路卡设置的不专业了。
为什么会提示不一样，我猜是有时候入口把我放过了，但是内部又提供不了服务，所以提示了系统繁忙。
怎么做好限流
从方式上分，可大致分为单机限流和分布式限流。
单机限流比较好实现，很多文章对限流算法进行了详细阐述，漏斗、令牌桶等等，但是单机限流是有问题的，因为在分布式部署下，即使单机作为均衡，但是打到底层存储上也有可能是超量的；反过来，由于流量分配不一定严格均衡，有可能出现有的机器承担更多的流量，在整体并发还没有到达峰值时就发生限流。所以，集群限流在很多场景下是必要的。
那集群限流应该怎么做，简单来说，就是让入口流量都统一打到一个地方，再进行统一分配。这么做的好处是可以精准的控制整体调用量，达到流量控制的目的。
常见的集群限流的方式，有redis lua 或依赖第三方限流中间件，如sentinel。
又到了知识总结的环节，请看下文。
什么是高并发
多大的QPS就算高并发了，1w ? 10w ? 其实不能一概而论，一个是支某宝国民级应用，一个是小公司商业广告，支某宝倒是用户量大，几百台机器一怼，平均下来也就几十个并发；小公司呢，4台机器抗整个小公司商业广告计费，那到底哪个算高，是不是，对不对。
所以，单论数值不足以衡量并发问题，之前看过一个观点说的很好，所谓高并发，是我们在业务发展过程中需要用到高并发的意识去架构我们的系统，用编码和设计去预防和解决并发引起的问题，而不是单纯的升级硬件和水平扩服务器。
从现象谈应对
常见的应对高并发问题的策略有哪些呢，见下图：
（内容整理自https://xie.infoq.cn/article/20c3ad1736d027615b12d6b20）
高并发的场景是各有不同的，离开业务场景的架构设计都是徒劳。好在理论是相通的，起码可以在遇到问题的时候给我们一个下手的方向。
