淘宝开放平台揭秘：高性能 API 网关、高可靠消息服务技术内幕

双11零点刚过，众多数百万商家一同开启促销。每秒近乎百万次的API请求，如潮水一般涌向阿里开放平台。每一个毫秒级的延迟，都极有可能造成数千万的交易损失。网关架构的每一处优化，都直接决定了这一波流量洪峰能不能平稳度过。

富客户端多级缓存

每一次请求时，传统网关都朝着远端缓存服务器前去读取数据，在双 11 期间，每秒百万次的 QPS 状况下，需要将近百台缓存服务器做支撑，这不但成本高昂，还会致使机房网络出现严重拥塞现象。架构团队于客户端本地增添了具备 LRU 规则的本地缓存，与远程分布式缓存一道构成多级缓存架构。

当本地缓存命中率超出95%之际，绝大多数的元数据读取请求都无需借助网络传输，单机处理能力自十万级攀升至千万级QPS。缓存过期的数据经由异步线程按照定时予以刷新，如此既确保了数据的最终一致性状态，同时又规避了大量线程同步等待所引致的资源浪费情况。

异步化彻底隔离

在同步调用模式当中，每一个API请求都得占有一个线程。一旦上游接口出现了5%的超时情况，整个的线程池就会被阻塞住。于是乎，所有调用的响应时间都会跟着升高起来。那网关，会把HSF和HTTP调用全部进行异步化处理，当请求发出之后，线程就会马上释放回到线程池里。

远程调用的响应借助事件驱动途径触发回调，经TOP工作线程池去完成后续的数据处理。在进行异步化改造后，就算某个API接口的响应延迟至5秒，那也不过是影响这一条请求的处理罢了，并不会去挤占其他请求的线程资源，整体的吞吐量提高了3倍有余。

多维度流量控制

双11期间，单个API的服务能力，或许仅有20万QPS，然而实际调用需求，却能够达到40万QPS，要是不对流量予以精细控制，核心API极易被暴涨的请求给击垮，网关达成了应用、IP、用户多维度限流，核心业务的流量，得以较高概率通过限流门槛。

在压测阶段，集群流控方案暴露出了问题，数据实时性依赖应用轮询间隔，若轮询间隔设置得太短，会造成机器资源的浪费，要是设置得太长，又会致使限流不够及时，最终运用分布式令牌桶算法去配合本地缓存令牌，这样不仅保证了限流的实时性，还把限流决策耗时控制在了1毫秒以内。

消息服务替代轮询

传统的ISV系统调用API的方式是进行定时轮询，每隔5秒就去查询一下数据是否存在更新，在双11期间，数万个ISV一同进行轮询，这造成了极大的网络消耗以及机器资源的浪费。开放平台所推出的消息服务，能让客户端只要启动SDK监听就行，当有数据更新的时候，服务器会主动进行推送。

对拉取模式进行了异步化改造，若客户端未产生新数据，服务器便不会返回任何内容，且连接保持挂起状态。95%的消息事务于内存中完成，仅有极少数消息会涉及磁盘读写活动，其中单台服务器所支撑的连接数由5000增大至5万的同时，网络流量降低了80%。

数据同步双重保障

商家于运用订单数据同步之际，常常原因在于经验欠缺或者代码存有缺陷从而引起发生漏单、延迟状况，逐日可见数百个工单来反馈体现数据不相符问题。数据同步服务运用消息实时同步以及对账任务予以双重保障，订单进行创建或者发生变更后以秒级往用户数据库推送送达。

对账任务每隔30秒就执行一回，从订单中心那儿拉取那种在过往5分钟内出现变更情况的订单列表，跟用户本地数据库逐个逐条去进行对比，一旦发现数据存在不一致的时候就马上触发更新这个动作，与此同时要记录下日志用来供排查使用，消息通道要确保具有实时性，对账任务需确保达成最终一致性状态，让漏单率从千分之三降低到十万分之一下限以下的水平，以此来实现相关目标。

集群容灾与平滑升级

组成数据同步集群的，是来自三个机房的500台机器，这些机器按照一种逻辑集群的方式进行划分，从而服务不同的用户群体，并且每个逻辑集群之中，最少得包含来自两个机房的机器才可以。一旦有单台机器出现宕机的状况，那么在心跳检测30秒之内，便能够发现具体的异常情况，随后调度程序会自动地把任务重新分配给仍然存活的机器。

当订单数据结构频繁发生变更之际，同步服务会把订单详情当作大字段来进行存储，在对比更新之时仅仅对变更时间戳予以比较，以此来避免对复杂的数据结构展开解析。每天夜里零点之后的交易低峰时段，系统会自动对逻辑删除的过期数据实施清理，从而确保数据库查询效率一直稳定于100毫秒以内。

双 11 当中，你的系统碰到过何种棘手的性能方面的问题，又是怎样去解决的呢，欢迎于评论区分享相关经验，点赞并展开转发以便让更多的开发者能够看到这些实战性质的干货。

上一篇： 孕妇做瑜伽球好处多，放松身心促循环还利于生产

下一篇： 孕妇练瑜伽的注意事项及适宜情况全解析，你知道吗？