我应该如何设计 PHP 上传和调整图像大小脚本才能最好地捕获和报告错误
我正在编写一个 PHP 脚本，该脚本将位于在 Amazon EC2 中运行的服务器上。它将接收上传的文件，在数据库中创建记录，重命名文件以匹配数据库 ID，调整文件大小，将文件移动到服务器上的新位置，并将图像文件放入 Amazon S3 上。
在每个阶段都有失败的可能性，这将导致脚本中断，如果用户正在上传许多文件，则等待的下一个文件将不会被上传。
因此，在每项活动中，我知道我需要捕获任何错误，记录它们以供稍后处理，然后继续处理下一个图像，或者报告已发生的问题。
我想我想在我的数据库中记录失败的上传，以便我可以获得上传失败的报告，并记录文件名、上传者的用户名以及任何其他信息，以便我可以联系用户或是否在发生错误的调整大小阶段，例如，调整图像大小并将其放在 Amazon S3 上。
我不是一个非常有经验的 PHP 程序员，Try Catch 块是否适合上述所有情况。我应该使用 Try Catch 进行 rename() 吗？
干杯
I am writing a PHP script that will sit on a server running in Amazon EC2. It will receive uploaded files, create a record in the database, rename the file to match database id, resize the file, move the file to a new location on server and also PUT the image file on Amazon S3.
At each of these stages there is the possibility of failure which will cause the script to interrupt and if the user is uploading many files the next file will waiting will not be uploaded.
So at each of these activities I know I need to catch any errors, record them to be dealt with later and move on to the next image, or report back that a problem has occurred.
I think I want to record failed uploads in my database so that i can get a report of when uploads failed, and record the filename, the username of the uploader and any other info that will allow me to contact the user or if it was at the resize stage that the error occurred for example, resize the image and put it on Amazon S3.
I am not a very experienced PHP coder, are Try Catch blocks suitable for all the above situations. Should I use Try Catch for rename()?
cheers
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
因此，我认为该解决方案最重要的部分可能是存储有关失败事件的详细信息，以便您可以稍后重试、调试问题，或者至少在必要时联系用户。
S3 可能是理想的选择 - 我基本上会编写一个错误处理函数，当调用该函数时，它会捆绑请求周围的所有详细信息（可能是所有 HTTP POST 变量、HTTP 请求标头等）和图像，并将它们存储在S3 以供将来检索。由于您的服务在 EC2 上运行，因此无法写入 S3 的几率非常低，因此这可能是一个有效的包罗万象的方法。
对于 S3 写入失败，我会进行少量重试，但不会详尽无遗，因为这种情况不太可能发生。如果您想记录存储在 S3 上的事实，您甚至可以循环使用 SimpleDB 日志记录机制，但这并不是绝对必要的，因为您只需列出“错误存储桶”中的文件即可查看是否有任何错误错误。通过请求每个对象，您还可以了解问题所在。
完成后，您可能只想将 try/catch 包裹在其他故障点和故障事件上，调用您的 store-on-S3 函数并继续进行下一个上传。
如果您的服务取得了成功，您可以通过将错误处理部分纳入不可避免的存储和队列方法来上传和处理这些上传，从而进一步改进这一点。该方法可能涉及始终将上传的文件存储在 S3 上，然后在 SQS 上对处理请求进行排队，因此您的错误处理函数可以简单地引用已存储的 S3 文件，而不必捆绑和存储。
希望有帮助！
So I think the most important part of this solution is likely storing the details around the failure event so you can either retry later, debug the problem, or at the very least, contact the user if necessary.
S3 is probably ideal for this - I'd basically write an error handling function which, when called, bundles up all the details around the request (probably all the HTTP POST variables, HTTP request headers, etc) and the image and stores them on S3 for future retrieval. Since your service is running on EC2, the odds of failing to write to S3 is quite low, so this is probably an effective catch-all.
On S3 write failures, I'd do a low # of retries, but not exhaustive since it's so unlikely. You can even loop in a SimpleDB logging mechanism if you'd like to log the fact that you stored on S3, but that's not strictly necessary since you can just list the files in your "error bucket" to see if you've had any errors. By requesting each object, you can also likely see what the problem was.
After that's done, you probably just want to have try/catch wrapped around your other failure points and on failure events, call your store-on-S3 function and move on to the next upload.
If your service takes off, you can further improve on this by making the error handling bit part of your inevitable store-and-queue approach to uploading and processing those uploads. That approach will likely involve always storing the uploaded file on S3 anyway, then queuing the processing requests on SQS, so your error handling function can simply reference the S3 file that's already been stored, rather than having to bundle and store.
Hope that helps!