服务器A会通过 curl 将数据转发到服务器B 上，服务器A 每小时转发量在百万级。curl 请求的是服务器B上的 一个 0字节的文件 ， 只要把请求记录在服务器B的nginx日志里就可以了。
现在通过两边的数据比对， 发现数据一天会丢几千条，一小时会丢一两百条。
服务器A 用curl_errno()，甚至加了curl_getinfo()判断返回的是否是200 都没有记录到curl报错
这部分丢失的curl请求， 想请教大家有什么好的分析思路跟经验可以借鉴的。
补充： 服务器间用的内网dns解析，排除了 dns解析超时的故障
Copyright 2014-2026 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号
8
782
收藏
合并请求是个好的思路，并发处理过多的话，不仅是B服务器，A服务器也不见得能按照期望去处理。
或者也可以使用队列来处理，每秒并发可以控制一个量级下去请求B服务器。
以前做过实验，一次并发50个左右的请求，比较稳定。多了就开始丢失请求了。不知道为什么。
何不考虑先使用A服务器将B服务器需要的日志形式写入A服务器的磁盘某个角落，然后每分钟
curl一次B服务器，让B服务器抓A服务器这一分钟的数据记录，然后写入B服务器nginx日志集？这样每小时请求60次，甚至两边通信可做失败重传，大大减轻高并发下的网络丢包现象。具体通信时间间隔可根据每次通信传输的数据量来定，比如控制一次
curl只传输1MB的内容，以保证通信正常完成。仅提供一个思路，写这种脚本也是要花时间的，酌情考虑。
如果单纯只是记录请求的日志，建议使用UDP传输吧
为什么要curl去？如果仅仅是为了留下日志的话。那在a的nginx上开个location。proxy到b。页面script src到a的这个location
敢问题主，你们服务器之间这样打点之后的日志分析入库是如何实现的？另，我觉得丢失数据是一定会发生的，几百万条一条也不丢失几乎都是科研而不是工程了。我同题主一样需要这样的打点并写入mysql。题主能跟我讲下现有你们的架构吗？