微软MVP分享 | 高并发架构演进，并发数、TPS、QPS多维升级
共 1773字，需浏览 4分钟
· 2020-09-22
年年岁岁跳槽季，回回必问高并发！原因很简单，因为高并发能牵扯出太多问题，接口响应超时、CPU负载升高、GC频繁、死锁、大数据量存储等，能考察求职者的真实情况。
而很多人在第一步就倒下了！因为对数据化的指标没有概念：不清楚选择什么样的指标来衡量高并发系统？分不清并发量和QPS，甚至不知道自己系统的总用户量、活跃用户量，平峰和高峰时的QPS和TPS等关键数据，谈优化只是隔靴搔痒。DotNet社区分享九月第三期，我们聚焦高并发！
公认的高并发场景：双11、春运抢票、微博大V热点新闻、秒杀系统、日均千万级订单系统、亿级日活信息流，然而这些高并发场景，并发量各不相同，那到底多大并发才算高并发呢？
不能脱离场景看数字，10W QPS的秒杀是高并发，1W QPS的信息流就不是高并发？信息流场景涉及复杂的推荐模型和各种人工策略，业务逻辑可能比秒杀场景复杂10倍不止。因此，不在同一个维度，没有任何比较意义。
业务都是从0到1做起来的，并发量和QPS只是参考指标，高并发最重要的是流量变成10倍、100倍的过程中，是否有恰当的方式去演进系统，能从架构设计、编码实现、甚至产品方案等多维度去预防和解决高并发引起的问题，而不是一味地升级硬件、加机器做水平扩展。
高并发就是高性能？其实不然，高并发系统设计的目标有三个：高性能、高可用，以及高可扩展。
性能体现了系统的并行处理能力，在有限的硬件投入下，提高性能意味着节省成本。优化用户的体验，响应时间分别是100毫秒、1秒、3秒，给用户的感受是完全不同的。
表示系统可以正常服务的时间。对于高并发系统，最基本的要求能做到3个9以上，像一些大公司每年动辄千亿以上的GMV，1%(2个9)不可服务就是10亿级别的业务影响。
表示系统的扩展能力，流量高峰时能否在短时间内完成扩容，更平稳地承接峰值流量，比如双11活动、明星离婚等热点事件。
这3个目标是需要综合考虑的，因为它们互相关联相互影响。比如说：为了系统的扩展能力，将服务设计成无状态的，这种集群设计保证了高扩展性，也间接提升了系统的性能和可用性；为了保证可用性，通常会对服务接口进行超时设置，以防大量线程阻塞在慢请求上造成系统雪崩，那超时时间设置成多少合理呢？也是参考服务的性能表现来设置的。
说起高并发方案，很多人都能滔滔不绝，大到垂直拆分、水平扩展、缓存、异步化架构设计，小到并发编程、请求合并、文件压缩等编程技术，然而没有实践落地经验，只能是纸上谈兵，全无落地细节。
本期.NET社区技术分享活动，重磅邀请了微软MVP为大家在线分享，基于真实项目案例解读从0到1的架构演进，从1w用户成长到1000w背后技术变迁。
特别提醒：
本次分享与Bilibili联合同步直播，根据对方要求，此次分享需提前预约，请大家扫描下文海报中的二维码及时预约哦。（工作人员会拉你进微软MVP分享交流群！）
【请大家及时扫码预约】
高并发是一个复杂且系统性的问题，为确保大家能更好地吸收此次分享会的硬核干货，作为主办方，现整理了一组学习资料，含Redis、RabbitMQ、Kafka、MongoDB等内容，可扫码文末二维码直接获取，提前准备下啦！
写在最后的话：
高并发设计秉承架构3原则：简单、合适和演进。“过早的优化是万恶之源”，不能脱离业务的实际情况，更不要过度设计，合适的方案就是最完美的。今晚八点，来跟MVP一起经历架构升级，于实战中成长！
本次邀约大佬分享前后协调数周，着实不易，免费公益性质，大家真心别错过！
（Redis、RabbitMQ、Kafka、MongoDB等自取）
DotNetdaily
资料包 扫码免费获取
高并发核心技术落地
社区分享会 09/21 20：00