Django应用在发生异常后一直崩溃，直到重新启动
我正在使用Django + uWSGI + nginx服务应用程序。来自前端的所有请求均为发布请求。
行为： 在下面的代码片段中，函数convert_data连接到数据库并将请求转换为resp。
class ConvertDataView(View): def post(self, *args, **kwargs): request = json.loads(args[0].body.decode()) resp = api_utils.convert_data(request) if resp: return JsonResponse(resp, safe=False) return JsonResponse({}, status=404) 当输入中包含无效字符（例如\，'，“等）时，convert_data会引发异常。此异常因数据库而异，但形式为“查询无效”。
问题： 即使输入正确且其中不包含任何无效字符，对此核心/线程的所有后续查询也会继续失败。此行为导致应用程序不稳定，并在请求转到另一个核心/线程时提供信息，但在涉及到此“损坏的核心/线程”时失败。
该错误将继续存在，直到重新启动uwsgi服务器为止。uwsgi服务器重新启动后，该应用程序再次恢复正常。
似乎有效的方法： 如果我在ConvertDataView中执行异常处理，则似乎仍然存在此问题。但是，似乎如果我在convert_data中执行异常处理并始终发送回有效响应而不是引发错误，则不会发生此错误。
我尝试过的事情：
最初，我认为该错误可能是由于Teradata崩溃造成的。但是，我将convert_data连接到其他数据库仍然发生。 然后我想也许python正在重用相同的数据库驱动程序。但是查看驱动程序对象的存储位置将显示不同的存储位置。这意味着将创建一个新的数据库对象，这是预期的行为。 我尝试用Django的开发服务器替换uwsgi。但是在这种情况下，直到服务器重新启动，响应似乎总是被破坏。 我不知道是否会针对与数据库无关的错误（例如KeyError，IndexError等）发生这种现象。
版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
根据你的描述，问题似乎出在异常处理和uwsgi工作进程之间的交互上。当convert_data函数中发生异常且未被妥善处理时，可能导致了 uwsgi 工作进程处于某种不一致或损坏的状态，进而影响到后续的请求处理。
以下是一些建议，希望能帮助你解决这个问题：
-
改进异常处理： 你已经提到，在
convert_data内部进行异常处理可以避免问题出现。确保对所有可能抛出异常的操作都进行了捕获，并且在捕获后不仅返回一个有效的响应，还要确保资源（如数据库连接）得到正确关闭或释放。这可以通过使用try...except...finally结构来实现。 -
资源清理： 确保在异常路径中，任何打开的数据库连接、文件句柄等资源都被正确关闭。有时候，即使Python垃圾回收机制最终会清理这些资源，及时手动关闭它们能减少潜在的问题。
-
uwsgi配置优化：
- 考虑调整uwsgi的工作进程(
workers)数量和/或其重启策略。例如，你可以设置harakiri参数来限制请求处理时间，超时后自动重启工作进程。 - 使用
vacuum或touch-reload指令定期重启uwsgi，作为一种临时缓解措施，直到找到根本原因。 - 确认uwsgi的日志级别设置为
info或debug，以便于收集更多关于异常发生时的上下文信息。
- 考虑调整uwsgi的工作进程(
-
Django中间件： 利用Django的中间件来全局捕获并处理异常，确保任何未被捕获的异常都能被适当地记录和处理，同时向客户端返回一个友好的错误消息。
-
数据库驱动和版本检查： 确认你使用的数据库驱动是最新的，并且与你的数据库服务器兼容。有时候，驱动程序的bug也可能导致这类问题。
-
线程同步和并发控制： 检查是否有共享资源在多线程或多进程中没有正确同步。虽然Django默认使用同步模式运行，但如果你有自定义代码涉及并发，确保锁或其他同步机制正确实施。
-
监控和日志： 强化应用的监控和日志系统，特别是对于数据库操作相关的部分，这样可以在问题发生时快速定位。
如果以上建议都不能解决问题，可能需要更深入地分析 uwsgi 和 Django 应用的日志，甚至考虑使用调试器在生产环境中复现问题，以获取更详细的故障信息。
