本地消息表简介 本地消息表是分布式事务的一种实现方式，解决了分布式场景下数据最终一致性问题，是分布式事务相对简单可靠的解决方案，有一定的数据延迟性 实现思路 例：如在支付场景中，当用户支付完订单后， 订单服务会向本地消息表插入一条消息，消息内容为订单支付成功 订单服务会向支付服务发送一条消息，消息内容为订单支付成功 订单支付的业务逻辑和本地消息表的写入，生成订单相关业务逻辑和数据，订单的异步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.

水塘采样算法解决随机抽样需求 需求场景： 如果我们现在有200万用户数据，需要从200万用户数据中以较好的随机性,随机抽取200个用户做案例分析或灰度发布; 尝试了多种算法，发现水塘采样算法是性能较好、随机性较好、算法空间复杂度平衡、比较适合泛用性需求场景; class ReservoirSampler { private $pdo; private $batchSize = 10000; public function __construct(PDO $pdo) { $this->pdo = $pdo; } public function sample($tableName, $k) { $reservoir = []; // 水塘，存储 k 个随机样本 $offset = 0; // 分页偏移量 $count = 0; // 已处理的元素总数 while (true) { // 分批读取数据，避免一次性加载所有数据 $sql = “SELECT * FROM {$tableName}

服务器性能优化 在日常开发中如果需要进行服务器性能优化大概有哪些切入点，例客户端请求服务器一个业务接口，可以优化的对象有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核心数