为什么我的nodejs服务器会崩溃，即使我正在处理可能发生的错误？ - 腾讯云开发者社区 - 腾讯云

开发者社区

文档建议反馈控制台

文章/答案/技术大牛

发布

NodeJS错误处理最佳实践

原文这篇文章会回答NodeJS初学者的若干问题：我写的函数里什么时候该抛出异常，什么时候该传给callback,什么时候触发EventEmitter等等。我的函数对参数该做出怎样的假设？...包括为什么出错，错误背后的原因。之后会提及，但是关键在于错误处理的粒度要细，因为哪里出错和为什么出错决定了影响大小和对策。你可能会发现在栈的某几层不断地处理相同的错误。...如果你不知道怎么处理这个异常，最简单的方式就是放弃你正在执行的操作，清理所有开始的，然后把错误传递给客户端。（怎么传递异常是另外一回事了，接下来会讨论）。这种方式适合错误短时间内无法解决的情形。...即使不覆盖这个超时时间，客户端会挂两分钟直到 “hang-up” 错误的发生。这两分钟的延迟会让问题难于处理和调试。很多内存引用会被遗留。...即使没有配置 code dumps，你也可以用堆栈信息和日志来开始处理问题。最后，记住程序员在服务器端的失误会造成客户端的操作失败，还有客户端必须处理好服务器端的奔溃和网络中断。

2.1K4 1

浅谈Kotlin的Checked Exception机制

由于Checked Exception机制的存在，对于一些可能发生潜在异常的代码，我们必须要对其进行处理才行。...你有在close的异常捕获中进行过什么有意义的逻辑处理吗？而Checked Exception机制的存在强制要求我们对这些未捕获的异常进行处理，即使我们明确不想对它进行处理都不可以。...恰恰相反，Kotlin程序反倒是减少了很多异常，因为Kotlin增加了编译期处理空指针异常的功能（空指针在各类语言的崩溃率排行榜中都一直排在第一位）。...比如我正在编写网络请求代码，由于网络存在不稳定性，请求失败是极有可能发生的事情，所以即使没有Checked Exception，大多数程序员也都知道应该在这里加上一个try catch，防止因为网络请求失败导致程序崩溃...Java拥有Checked Exception机制并不是错误的，Kotlin中取消Checked Exception机制也不是错误的。我想这大概就是你阅读完本文之后能够得出的结论吧。

1.8K4 3

您找到你想要的搜索结果了吗？

是的

没有找到

【软件架构】支持大规模系统的设计模式和原则

今天，即使是小型初创公司也可能不得不处理数 TB 的数据或构建支持每分钟（甚至一秒钟！）数十万个事件的服务。所谓“规模”，通常是指系统应在短时间内处理的大量请求/数据/事件。...一个展示异步如何提供良好效率/性能的示例是 Nodejs，它具有单线程事件循环，但它正在与许多其他并发语言和框架进行斗争。...指标、监控和警报在运行大规模系统时，不是系统是否会失败的问题，而是系统何时会失败的问题：由于规模大，即使是百万分之一的罕见事件也会发生。最终发生。...一个示例可以是在我们正在运行的 A/B 测试中发布的指标，以提供有关分配到实验不同单元的用户的见解小轶事：在我为 Netflix 工作的日子里，我和我的团队所做的一件事是开发 Watson，使团队能够通过创建程序化运行手册从已知场景中自动修复他们的服务...节流有 3 种类型：用户限速（客户端）服务器限速和地理限速背压背压是一种用于处理来自上游服务的请求负载高于处理能力的情况的技术。

8962 0

你是一个成熟的程序员了，是时候学习面向故障编程了

作为程序员，最大的噩梦，可能就是下班时间，当我正在开心的浪着，突然传来一阵急促的铃声，运维的同事说系统不行了，我必须马上上线帮忙抢救.........在生产环境中，有可能发生故障的地方，早晚都会发生故障。作为开发人员，我们能做的，就是利用各种设计模式和技巧，主动积极地去正视故障，处理故障，修复故障，将故障杀死于襁褓之中。...客户端发送SYN到服务器监听端口以发起连接请求，如果此时没有进程正在监听这个端口，服务器就会返回TCP reset以中止此次连接请求。...大家的第一个反应一定是重试，也许刚刚应答方太忙，所以才不能及时处理我们的请求。我再试一次，也许应答方就可以答复了呢。但是我劝你谨慎。因为作为开发人员，我们无法猜测导致请求Timeout的原因。...那就是在大流量压力下所造成的节点崩溃。如果我们在服务进程的实现中有个缺陷，会造成内存泄漏。

6972 0

Linux：信号的预备和产生

结论2：即使信号没有产生，我们的进程也要具备处理信号的能力！！信号的处理能力是属于进程内置功能的一部分！！问题4：信号产生了，为什么有时候并不会被立即处理？？...——>当你妈喊你吃饭的时候，此时常规的理解应该下去吃饭（默认动作），但是你也有可能正在跟妈妈吵架正在赌气，所以你假装没听到（忽略），也有可能你会一边看电视一边吃饭（自定义动作）结论4：进程处理信号的方式有三种...——>cpu在处理该进程的时候，他的一些信息都是隶属于该进程的上下文，而除0会让cpu上的状态寄存器中的一个溢出标记bit位变为1 ，因此OS就可以检测到异常！！然后发送信号让进程崩溃。...问题2：为什么进程出现异常了OS不崩溃？？...——>首先不谈你是否有这个权限，问题是由你进程引发的，即使你修正了硬件错误往下执行了，但是因为你中间出错过，无论如何我都不会相信你的运行结果了，所以你执行下去是没有任何意义的！！

4101 0

服务器宕机了，Kafka 消息会丢失吗？

我想大多数同学的应用可靠性，可能都只需要考虑到服务器宕机级别，因此后续的考虑也仅限于这个级别。...与此同时，Kafka 服务器也会进行副本的复制，该 Partition 的 Follower 会从 Leader 节点拉取数据进行保存。...因此，对于 Kafka 服务端来说，即使你设置了每次刷 1 条消息，也是有可能发生消息丢失的，只是消息丢失的概率大大降低了。...在我们在业务处理完提交 ack 这种情况下，有可能发生消息重复处理的情况，即业务逻辑处理完了，但在提交 ack 的时候发生异常。...使用手动提交 acks 的方式，避免丢失消息，同时需要做好幂等处理，避免重复处理。本文的思维导图如下所示。好了，这就是今天的分享了。如果你喜欢今天的分享，记得一键三连支持我！

3.1K3 1

十一问MongoDB CTO，谈NoSQL人气王的扩展、事务及运维

此外，动态、灵活的模式更可以让用户在商用服务器上轻松的进行横向扩展。然而还是有很多潜在用户抱有这样的担心——MongoDB的成功是否建立在过度的炒作之下。...Eric：即使发展至今，在使用NoSQL处理事务上仍然存在疑问，你是怎么处理这个问题的？ Eliot：为了更好的实现事务功能，MongoDB加入了越来越多的特性。...我们看到许多新的应用程序基于MongoDB建立，可以说每时每刻都在发生。同时，如果遗留系统崩溃，那么通常情况下它会被重构和重新建立。...但是，我认为这些都只是基础，重点在于使用它并喜欢它的人们，他们可能会对CIO上报：瞧，我正在使用这个产品，我认为它可以在更广泛的项目中投入使用，肯定会运行的很好。...使用关系型数据库的思维管理MongoDB，把MongoDB当做关系型数据库来使用，这样无疑会带来困境。 Eric：什么会让你夜不能寐？

86410 0

代码调试最佳实践

原文如下：我试着鼓励人们首先对这个bug有个全面的理解，比如说：什么正在发生？你期望会发生什么？什么时候会发生？什么时候不发生？然后运用他们对系统的心理模型来猜测可能发生的破坏，并进行实验。...我认为这里可能需要循环地重复以下步骤：猜测可能发生的错误的某一个方面（比如说，“这个变量被设置为X，它应该是Y”，或“发送到服务器的请求是错误的”，或“这段代码根本没有运行过”等等）。...（这是故意放在最后的一个错误，很少有人会认为编译器会出错）。...找出崩溃的原因是很容易的，但是有更好的错误处理方式（返回错误而不是崩溃）可以节省我一点时间，因为我不必去检查崩溃的原因，我只需阅读错误信息，知道发生了什么就可以了。...“Julia，你的服务器崩溃了！”

1.5K1 0

代码调试的最佳指南

原文如下：我试着鼓励人们首先对这个bug有个全面的理解，比如说：什么正在发生？你期望会发生什么？什么时候会发生？什么时候不发生？然后运用他们对系统的心理模型来猜测可能发生的破坏，并进行实验。...我认为这里可能需要循环地重复以下步骤：猜测可能发生的错误的某一个方面（比如说，“这个变量被设置为X，它应该是Y”，或“发送到服务器的请求是错误的”，或“这段代码根本没有运行过”等等）。...（这是故意放在最后的一个错误，很少有人会认为编译器会出错）。...找出崩溃的原因是很容易的，但是有更好的错误处理方式（返回错误而不是崩溃）可以节省我一点时间，因为我不必去检查崩溃的原因，我只需阅读错误信息，知道发生了什么就可以了。 ?...“Julia，你的服务器崩溃了！”

1.5K4 0

多进程单线程模型与单进程多线程模型之争

（异常情况下），会自动重新启动新的woker进程友情提示：nodejs属于这一种好不好，不是只能单核单进程多线程单进程多线程主线程负责监听客户端的连接请求，workers...副作用，副作用，单进程多线程肯定有其不利的一面我一直提过副作用。如果你仔细看多进程单线程的图，就应该明白，这种模型提供了一种保护机制。当其中一个进程内部读取错误，master可以让ta重启。...这使得你的服务器在表面上并没有感到“曾经崩溃”。对于master，完全不涉及服务器的业务，使得ta能被安全隔离。再来看单进程多线程。...(我个人只会用C)你见过哪个数据库服务器是java c#写的？...是编写者之一类似javascript的语法和编写体验而且我已经开始憧憬未来使用nodejs + Rust开发服务器体验的场景。

1.8K2 0

【分布式系统稳定性设计入门】如果不想总是半夜爬起来抢修生产事故……《发布！》第2版解读 v0.2

为什么？且听下面的故事。我以前很崇拜那些能修复各种软件缺陷的“救火”高手。很多年前，我曾经在一个维护遗留系统的团队做过开发。团队的每个开发，都轮流带一个7x24小时开机的手机，处理用户问题。...但在病情初起症状不十分明显的时候，二哥能够药到病除，所以村里人会觉得二哥还能治点小病。所以他的名气只能在本村，邻村的人都不知道他。” “我的动静就会比较大。...用户：用户流量的增长，是否会超过系统的容量？ 1. 超时、2. 断路器、6. 任其崩溃并替换、5. 快速失败、10. 卸下负载、9. 中间件解藕、8. 考验机系统的用户 6....同层连累反应：是否由于一台服务器停机，令其他服务器必须接过其负载而不堪重负？ 3. 舱壁、6. 任其崩溃并替换、10. 卸下负载、8. 考验机子系统之间 3....考验机能够用网络错误、协议错误或应用程序级错误等各种低层错误，来“考验”被测软件的测试服务器。因为每个系统最终都会偏离接口规范 9.

6051 0

Go: 并发编程中的错误恢复机制与代码持续执行分析

在现代软件开发领域，尤其是使用Go语言进行系统设计时，理解并发编程和错误处理是至关重要的。Go语言中的goroutine和recover机制提供了强大的并发控制和错误恢复功能。...关键点在于，每个goroutine中包含了recover机制，用于捕获并处理可能发生的panic。...代码分析根据前面的代码，当goroutine中发生panic时，recover会被触发，执行错误处理逻辑。这是一种优秀的错误处理模式，可以防止整个服务因为单个任务的失败而完全崩溃。...当recover捕获到panic后，goroutine内部的panic被处理掉，但这并不意味着goroutine会继续执行c.CmdRun(qid)。...即使使用了recover，goroutine也只是避免了崩溃，但无法从panic发生的点继续执行。

4411 0

如何实现分布式锁

如果加锁失败导致两个节点同时处理同一条数据，后果可能是文件损坏、数据丢失、永久性不一致、给患者服用的药物剂量错误或其他一些严重问题。...以上两者都是需要使用锁的原因，但您需要非常清楚您正在处理两者中的哪一个。...锁有一个超时（即它是一个租约），这总是一个好主意（否则崩溃的客户端最终可能会永远持有锁并且永远不会释放它）。...这意味着一个应用进程可能会发送一个写请求，当租约已经到期时，它可能会在一分钟后才到达存储服务器。即使在管理良好的网络中，这种事情也可能发生。...稍后，客户端1恢复正常后，将写入请求：内容和值为33的令牌发送到存储服务。但是，存储服务器记住它已经处理了具有更高令牌号 (34) 的写入，因此它拒绝带有令牌 33 的请求。

6932 0

又挂了！聊聊分布式系统级联故障

我们今天就来聊一聊，为什么会出现这种连锁反应，也就是级联故障，发生故障的时候如何处理，以及如何来避免这种故障的发生。...2、受影响的系统不会像处理更常见的问题那样恢复正常，而是会逐渐恶化，最终导致依赖于人为干预。 3、在最坏的情况下，级联故障可能会在没有警告的情况下突然发生，因为负载分布和故障会迅速发生。...如果内存/ RAM被过度使用，任务可能会崩溃，或者缓存命中率会降低。此外，线程饥饿可能直接导致错误或导致健康检查失败。在这种情况下进行故障排除通常很痛苦。...服务不可用当资源耗尽导致服务器崩溃时，流量会传播到其他服务器，从而增加这些服务器也崩溃的可能性。...但是这些问题仍然存在于系统中，因为某些机器仍然处于关闭状态或正在重新启动的过程中，而增加的流量会阻止它们完全恢复。一般来说，当我们将流量从不健康节点重新分配到健康节点时，总是存在级联故障的风险。

2K4 0

【韧性架构】让你的微服务容错的 5 种模式

采用错误预算——技术，当可重试错误率超过阈值时停止重试，例如如果与服务 D 的 20% 的交互导致错误，请停止重试并尝试优雅降级。在最后几秒内滚动窗口可能会跟踪错误数量。...您可能会争辩说，如果功能处于关键路径上，则启用断路器是没有意义的，但请记住，这种短暂且受控的“中断”可能会阻止一个大的且无法控制的中断。尽管断路器和错误预算具有相似的想法，但配置它们是有意义的。...）和并发，前者限制入站 RPS，后者限制任何时刻正在处理的请求数量。...拥有无限数量的工作人员意味着您将耗尽资源并崩溃，尤其是在工作人员以 1:1 映射到操作系统线程的环境中。1000 名工作人员的并发限制如何处理？...我希望你今天学到了一些新的和有用的东西。我想指出，这个列表并不详尽，您还希望获得良好的可观察性，因为可能会发生意想不到的事情，最好了解您的应用程序目前正在发生什么。

1.3K1 0

核心转储为什么必须限制？一次讲清 Core Dump 的原理、风险与安全处理步骤·卓伊凡

很多人做服务器安全的时候，会盯着端口、盯着弱密码、盯着防火墙、盯着漏洞修复，但却经常忽略一个非常关键的点：核心转储（CoreDump）没有做限制。...二、用一个比喻讲清楚核心转储到底是什么很多人第一次听这个概念会觉得很抽象，我给大家打个非常形象的比喻。假设一个程序正在运行，你可以把它理解成一个人在办公室里工作。...所以为什么核心转储要限制？因为你不能为了查一次故障，就把整个办公室的机密都一起公开。三、核心转储为什么会造成信息泄露？这一点是重中之重。...这就意味着，一旦程序崩溃并生成核心转储文件，这些敏感信息有概率被一起保存进去。所以很多人误以为核心转储只是个“报错文件”，这是错误的。...所以安全检查里看到“未对核心转储做限制，可能会出现信息泄露”，这个判断是完全合理的。六、安全上应该怎么处理？详细步骤讲清楚下面我给大家讲最重要的部分：如何安全处理核心转储。

1351 0

bihash并不是线程安全的

最近发生了看似相关的崩溃，当时在snat_main.flow_hash中的查找产生了一个value=-1，随后返回值作为目的索引在使用中产生了崩溃。...即使我们排除了抢占，也有微体系结构的怪癖（例如缓存、分支错误预测）可能会减慢查找到内存读取和更新将重叠的程度。查找的核心是以下循环。...概率很低，因为哈希应该将它映射到相同的桶。 3.旧键与新值匹配。概率很低，因为查找应该在特定的位置被抢占以使查找发生。尽管这些异常情况不太可能发生，但它们仍然是可能的并且可以被利用。...你好，感谢有见地的讨论！我明白高性能是 vpp 最重要的目标之一，因此某些解决方案可能不会成功。从我的 POV 来看，版本计数器会有所改进。它肯定会降低触发错误的可能性。...无论线程如何安排，我都希望拥有强大的功能。是否可以使用 vpp 基准测试实验室来评估所提议解决方案的性能影响？最后，我想重新讨论读者锁定提案。我们的想法是我们不会在读取器路径中引入任何原子操作。

1.3K5 0

AI 编码史诗级翻车现场！刚刚，Replit 一键删光客户整个生产数据库，官方连夜补锅

在访谈中 Masad 也解释了外界疑惑的 Replit 为什么不向用户展示底层模型。他表示：“我们的核心在于模型评估体系，团队会投入大量时间测试新模型并分析用户反馈。...更值得警惕的是，错误可能会导致系统进入更容易出错的恶性循环。在这方面，GPT 似乎表现得尤为明显。此外，我认为绝不能放任大语言模型自主编写和执行命令——这简直是灾难的源头。...但与此同时，我也必须投入大量精力学习如何正确使用 AI，因为我从不信任它的输出。我不会假设它给出的任何代码是正确的，而是会逐行检查，并深入学习相关概念，直到我能完全独立编写同样的功能。...“作为一个 20 年前曾尝试学习编程却失败的人，氛围编程彻底改变了我的学习轨迹。这种方式完美契合我的学习风格：通过不断构建、观察系统崩溃、重新组装的过程来获得真知。...在这个过程中，我常常花费数小时才意识到自己一直在错误的方向上解决问题——因为 LLM 只会机械地执行我的指令，而不会主动纠正我的思维误区。

5661 0

如何构建可扩展的应用程序

请求正在超时。该应用程序不断崩溃，数据库非常火爆。不是你想要的点亮。但你的测试是积极的。你曾计划好一切。出了什么问题？你的应用程序无法扩展！可扩展性（从技术角度来看）经常被忽略。...制作可扩展应用的提示传统的扩展需求是通过增加服务器资源来处理的。这种方法称为“扩展”。这种方法有许多局限性。在这篇文章中，我将专注于“扩展”。也就是说，添加新的服务器和资源以适应负载的增加。...特定资源（例如服务器，网络资源）的故障会导致整个应用程序崩溃吗？如果运行数据库或后端代码的服务器失败会发生什么？您的应用仍然可用吗？如果没有，那就是你的单点失败。所以你怎么避免这个？简单。...我几乎没有触及表面。但总而言之，横向扩展资源是关键。 3）将逻辑推送到客户端等等，什么？不是那样吗？并不是的。所以你在后端编写的PHP，.Net或Nodejs代码就是实际的逻辑。...这是有问题的，因为如果服务器出现故障，您将丢失该数据并且该客户端是孤立的。人们可能会建议您使用Redis来存储会话，但这也会带来缩放限制。最好的选择是使用JWT令牌。

1.9K2 0

Python 错误处理的终极指南（下）

为什么说捕获所有异常是一种不好的做法，又在什么情况下这样做是可以接受的？你准备好探索本文[1]Python中错误处理的奥秘了吗？...捕获所有异常你可能怀疑为什么类型4错误应该是你的应用程序中最常见的错误之一，因为如果让异常自由地冒泡，它们可能会一直冒泡到最顶层而没有在其他地方被捕获，导致应用程序崩溃。...应用程序可以简单地让错误继续冒泡，最终在这里被捕获，错误消息会被展示出来，然后应用程序会以错误代码退出。你可能还记得我之前提到过，捕获所有异常是一种不好的做法。然而，这里正是我所做的！...正如你之前看到的，Flask会捕获所有错误，因此你的应用程序不会因为漏捕错误而崩溃。...在其处理过程中，Flask会将错误消息和堆栈跟踪自动记录到Flask日志中，这正是我们所需要的，所以我们无需亲自动手。Flask还会向客户端返回一个500错误码，表示发生了意外的服务器错误。

7111 0

点击加载更多

相关资讯

热门标签

活动推荐

运营活动

活动名称

广告关闭