架构设计

令牌桶的使用和场景 场景：需要在业务代码中拉取指定第三方平台的报表数据，但是第三方平台有qps限制，平台有实时报表数据需要定期同步到我们的服务器做数据报表和数据分析处理，除了拉取的场景，还有数据操作的场景，我方服务器可能需要频繁操作第三方服务器的某些对象和数据，两部分操作是共享第三方平台的qps限制的。 问：如何设计拉取系统和操作系统的拉取方式，保证所有请求在授权拉取第三方平台时不会超过qps限制，并且能最大程度的拉取最大体量的数据保证数据更新效率和操作时效性 方案1： 没有任何设计和优化的场景 项目最开始是在后端接口api中，直接调用第三方平台进行数据操作和修改，没有任何限制 在这个基础上新增了一个数据同步机制，新启动一个进程同步数据，写入数据库 这个方案没有任何设计，也是最原始的实现方案，比较简单没有任何限制和约束，如果在高峰期做集中数据操作，可能会出现问题，如果超过服务器支持的qps则本地数据同步或者对象操作会出现异常 方案2： queue 在方案1的基础上，将所有与第三方平台交互的操作提前设计publish到队列中，所有与第三方交互的逻辑全部在队列中处理， qps为10则创建10个queue，每个queue中以queue+id为加锁的key名称， 每一个queue中只要操作第三方服务器，都需要获取queue锁，抢到锁才能操作或者拉取数据 这个方案限制了并发数量为要求的并发数量，但是有致命缺点，每一秒的请求有可能请求多次，导致超出qps的请求会操作失败，queue 的方案没有完善的解决并发，并且qps的请求限制 方案3： 令牌桶 在方案1的基础上，将所有与第三方平台的交互操作都加上获取令牌的约束，获取到令牌才可以进行数据交互， 令牌桶做成一个独立的服务，每次请求令牌桶获取令牌时，令牌桶都以秒为单位发放令牌，这1秒只生成8个令牌，获取完了就没有了只能阻塞等待获取令牌桶。 这个方案在该场景下比较合理并且完善，在单位qps的条件下只能允许数量的请求发送，较为完善的实现了场景要求的效果

本地消息表简介 本地消息表是分布式事务的一种实现方式，解决了分布式场景下数据最终一致性问题，是分布式事务相对简单可靠的解决方案，有一定的数据延迟性 实现思路 例：如在支付场景中，当用户支付完订单后， 订单服务会向本地消息表插入一条消息，消息内容为订单支付成功 订单服务会向支付服务发送一条消息，消息内容为订单支付成功 订单支付的业务逻辑和本地消息表的写入，生成订单相关业务逻辑和数据，订单的异步MQ任务投递是在同一个事务中，其属性是原子的 订单的异步MQ任务会被需要的服务消费，消费后的结果会更新本地消息表的状态 本地消息表会定时扫描，将状态为未处理的消息重新投递到MQ中 其他服务在需要查询订单状态时，会先查询本地消息表，若状态为已处理，则直接返回结果，否则向订单服务查询 并且需要一个定时扫描程序定期扫描本地消息表，检查检索没有正确投递，或者下游服务没有正确应答的消息，将其重新投递到MQ中 需要注意的是重新投递的MQ任务也可能会投递、消费失败，则需要在本地消息表中记录重试次数，超过最大重试次数则需要人工处理，注意在所有下游服务拉去MQ时的消息记录和日志需要完整，并且记录下每次消费的结果（正确或异常），方便后续分析和处理 问题 MQ服务，和其他服务在交互环节中会有数据不一致，延迟，消息丢失，服务挂机的情况发生，有服务宕机，消息丢失，进程消费异常等情况是会经常发生出现的，如何解决该问题 需要通过生成全局消息表traceId的方式完善该问题的逻辑，全局消息表是全局唯一，并且幂等，如果有消息丢失进程挂起，假死等情况需要将全局的本地消息表记录中的mq数据重复投递， 在其他分布式服务中需要幂等该进程的traceId的幂等消费，多次投递多次消费的结果是一致的 本地消息表是和业务逻辑相对耦合的，如果业务逻辑发生变化，需要同步修改本地消息表的处理逻辑，否则会导致数据不一致的问题，所以该实现方式对业务侵入性较强，不适合处理通用性较强的场景，所以使用时需要注意代码的后期维护几率和成本，如果后期维护成本较高，并且业务逻辑频繁变更，建议使用其他分布式事务实现方式 https://www.ierchina.com

访问微信公众号的网址非常慢(分析与优化方案) 问题场景 从公司站点或落地页跳转到微信公众号文章链接（如 mp.weixin.qq.com）时，整体打开耗时明显偏高 可能伴随多次重定向、接口串行校验、图片与第三方脚本阻塞加载等现象 关键现象与指标 DNS 解析耗时高、TLS 握手时间长、TTFB 偏高 重定向次数多（>1 次常见会显著拉长总耗时） 首屏阻塞资源过多（JS 同步加载、未压缩的图片、第三方埋点） 后端接口响应慢（数据库查询无索引、N+1、分页不当） 根因分析维度 链路与不可控边界 微信域名与其网络出口不可控，跨运营商/跨地区链路质量差异大 ICMP 常被屏蔽，Ping 不一定可用，需用 HTTP 侧指标判定 跳转逻辑与认证 过多的 302/301 重定向链、签名校验串行执行、未缓存的配置接口 跳转页存在动态渲染与接口依赖，导致首屏耗时增加 前端资源与页面结构 大体积图片、同步第三方脚本、阻塞式 CSS/JS、未启用缓存与压缩 服务端与网关 未开启 HTTP/2、KeepAlive 配置不合理、TLS 会话复用与 OCSP Stapling 缺失 数据库与存储 查询缺索引、Scan 过重、N+1 查询、分页深页、大量无用字段加载 诊断与定位步骤 浏览器侧 Chrome DevTools 网络面板：查看 DNS、TLS、TTFB、重定向链、阻塞资源瀑布图 Performance/Coverage：识别长任务与未使用代码 Lighthouse/WebPageTest：获取实验室指标与真实网络行为 命令行与网络 使用 curl 统计时延：curl

在网页中 HTTP 访问一个网址发生了什么？ 简要流程 解析 URL 与安全预处理 DNS 解析（目标域名 IP） 建立连接（TCP/80 或 TCP/443；或 QUIC/UDP） TLS 握手（若为 HTTPS） 浏览器发起 HTTP 请求 服务器处理请求（反向代理/应用/数据库/缓存） 返回 HTTP 响应（状态码、响应头与内容） 浏览器解析与渲染页面 缓存与后续优化（前端/CDN/代理） 连接复用或关闭 环节 1. 地址栏输入与预处理 自动补全与安全检查：浏览器可能进行历史记录/书签匹配、恶意站点拦截、HTTPS 先行策略（HSTS）。 本地命中与拦截：Service Worker 有权拦截同源请求，命中离线缓存或走自定义网络策略。 2. 域名解析（DNS） 解析顺序：hosts 文件 浏览器/系统 DNS 缓存 本地域名解析器 递归/权威 DNS。 关键记录：A/AAAA（IPv4/IPv6）、CNAME（别名）。CDN 会返回最优边缘节点 IP（ECS/GeoDNS）。 安全与隐私：DoH/DoT（HTTPS/TLS 下的 DNS）、DNSSEC 验证。解析结果受 TTL 控制被缓存。 3.

服务器性能优化 在日常开发中如果需要进行服务器性能优化大概有哪些切入点，例客户端请求服务器一个业务接口，可以优化的对象有Linux,nginx,phpfpm,php,mysql,redis; linux 可以优化配置服务器可以连接的套接字文件进程数 /etc/sysctl.conf # 系统最大文件句柄数（所有进程可打开的文件总数上限） fs.file-max = 1000000 # 系统范围内已分配、未使用的文件句柄数（监控用，一般不直接设置） # fs.file-nr # 端口范围 net.ipv4.ip_local_port_range = 1024 65535 # TCP连接相关 net.core.somaxconn = 65535 net.ipv4.tcp_max_syn_backlog = 65536 net.core.netdev_max_backlog = 50000 # TIME-WAIT优化（高并发场景） net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_max_tw_buckets = 2000000 net.ipv4.tcp_fin_timeout = 30 nginx # ============ 全局配置部分 ============ user nginx; # 确保与系统用户一致 worker_processes auto; # 自动设置为CPU核心数