Java百万高并发的技术方案.pdfVIP

Java百万高并发的技术方案--第1页 Java百万⾼并发的技术⽅案 前⾔：⾼并发，⼏乎是每个程序员都想拥有的经验。原因很简单：随着流量变⼤，会遇到各种各样的技术问题，⽐如接⼝响应超时、CPU load升⾼、GC频繁、死锁、⼤数据量存储等等，这些问题能推动我们在技术深度上不断精进。⾯对突发流量，不可能临时改造架构，最快 的⽅式就是增加机器来线性提⾼系统的处理能⼒。⾼扩展性需要考虑：服务集群、数据库、缓存和消息队列等中间件、负载均衡、带宽、依 赖的第三⽅等，当并发达到某⼀个量级后，上述每个因素都可能成为扩展的瓶颈点。 ⼀、什么是⾼并发 ⾼并发（High Concurrency）是互联⽹分布式系统架构设计中必须考虑的因素之⼀，它通常是指，通过设计保证系统能够同时并⾏处理很 多请求。 ⾼并发相关常⽤的⼀些指标有响应时间（Response Time），吞吐量（Throughput），每秒查询率QPS（Query Per Second），每秒 事务处理量TPS(Transaction Per Second)，并发⽤户数等。 响应时间：系统对请求做出响应的时间。 吞吐量：单位时间内处理的请求数量。 QPS：每秒响应查询请求数。 TPS：每秒响应事务请求数。 并发⽤户数：同时承载正常使⽤系统功能的⽤户数量。 1.1、如何理解⾼并发？ ⾼并发意味着⼤流量，需要运⽤技术⼿段抵抗流量的冲击，这些⼿段好⽐操作流量，能让流量更平稳地被系统所处理，带给⽤户更好的体 验。 我们常见的⾼并发场景有：淘宝的双11、春运时的抢票、微博⼤V的热点新闻等。除了这些典型事情，每秒⼏⼗万请求的秒杀系统、每天千 万级的订单系统、每天亿级⽇活的信息流系统等，都可以归为⾼并发。 很显然，上⾯谈到的⾼并发场景，并发量各不相同，那到底多⼤并发才算⾼并发呢？ (1)不能只看数字，要看具体的业务场景。不能说10W QPS的秒杀是⾼并发，⽽1W QPS的信息流就不是⾼并发。信息流场景涉及复杂的 推荐模型和各种⼈⼯策略，它的业务逻辑可能⽐秒杀场景复杂10倍不⽌。因此，不在同⼀个维度，没有任何⽐较意义。 (2)业务都是从0到1做起来的，并发量和QPS只是参考指标，最重要的是：在业务量逐渐变成原来的10倍、100倍的过程中，你是否⽤到 了⾼并发的处理⽅法去演进你的系统，从架构设计、编码实现、甚⾄产品⽅案等维度去预防和解决⾼并发引起的问题？⽽不是⼀味的升级硬 件、加机器做⽔平扩展。 此外，各个⾼并发场景的业务特点完全不同：有读多写少的信息流场景、有读多写多的交易场景，那是否有通⽤的技术⽅案解决不同场景的 ⾼并发问题呢？ 我觉得⼤的思路可以借鉴，别⼈的⽅案也可以参考，但是真正落地过程中，细节上还会有⽆数的坑。另外，由于软硬件环境、技术栈、以及 产品逻辑都没法做到完全⼀致，这些都会导致同样的业务场景，就算⽤相同的技术⽅案也会⾯临不同的问题，这些坑还得⼀个个趟。 因此，这篇⽂章会将重点放在基础知识和通⽤思路，希望让你对⾼并发有更深的理解。 1.2、 ⾼并发系统设计的⽬标是什么？ 先搞清楚⾼并发系统设计的⽬标，在此基础上再讨论设计⽅案和实践经验才有意义和针对性。 ⾼并发绝不意味着只追求⾼性能，这是很多⼈⽚⾯的理解。从宏观⾓度看，⾼并发系统设计的⽬标有三个：⾼性能、⾼可⽤，以及⾼可扩 展。 a、⾼性能：性能体现了系统的并⾏处理能⼒，在有限的硬件投⼊下，提⾼性能意味着节省成本。同时，性能也反映了⽤户体验，响应时间 分别是100毫秒和1秒，给⽤户的感受是完全不同的。 b、⾼可⽤：表⽰系统可以正常服务的时间。⼀个全年不停机、⽆故障；另⼀个隔三差五出线上事故、宕机，⽤户肯定选择前者。另外，如 果系统只能做到90%可⽤，也会⼤⼤拖累业务。 Java百万高并发的技术方案--第1页 Java百万高并发的技术方案--第2页 c、⾼扩展：表⽰系统的扩展能⼒，流量⾼峰时能否在短时间内完成扩容，更平稳地承接峰值流量，⽐如双11活动、明星离婚等热点事件。 这3个⽬标是需要通盘考虑的，因为它们互相关联、甚⾄也会相互影响。 ⽐如说：考虑系统的扩展能⼒，你会将服务设计成⽆状态的，这种集群设计保证了⾼扩展性，其实也间接提升了系统的性能和可⽤性。 再⽐如说：为了保证可⽤性，通常会对服务接⼝进⾏超时设置，以防⼤量线程阻塞在慢请求上造成系统雪崩，那超时时间设置成多少合理 呢？⼀般，我们会参考依赖服务的性能表现进⾏设置。 ⼆、提升系统的⾼并发能⼒ 互联⽹分布式架构设计，提⾼系统⾼并发能⼒的⽅式，⽅法论上主要有两种：垂直扩展（Scale Up）与⽔平扩展（Scale Out）。 （1）垂