一个事件驱动的订单系统使用 Amazon SQS 标准队列。在测试期间，处理停止了，因为一条订单消息导致后端错误并阻塞了后续消息。队列的可见性超时为 30 秒，而后端处理在 10 秒后超时。解决方案架构师必须允许调查错误消息并确保后续消息继续得到处理。解决方案架构师应该怎么做？

正确答案是创建一个新的 SQS 标准队列，并将其配置为死信队列以隔离错误消息。当消息导致处理错误时，死信队列（DLQ）允许系统将这些消息隔离起来，以便稍后进行调查，同时不阻塞主队列中后续消息的处理。这符合题目中“允许调查错误消息并确保后续消息继续得到处理”的要求。 将后端处理超时增加到 30 秒，以匹配队列可见性超时，并不能解决错误消息阻塞后续消息的问题，因为错误消息仍然会停留在队列中并导致处理失败。减少 SQS 可见性超时，会导致错误消息更快地重新回到主队列，从而可能加剧阻塞问题，而不是解决它。创建一个新的 SQS FIFO 队列作为死信队列是不必要的，因为标准队列的死信队列功能足以满足隔离错误消息的需求，并且 FIFO 队列会引入额外的顺序处理限制，这对于死信队列来说通常是不需要的。